SNOMED CT Technical Reference Guide - January 2010

SNOMED CT® Technical Reference Guide January 2010 International Release (US English)

Contents

Copyright Notice...... 7 General Introduction...... 8 Inventory of Documentation...... 9 Document History ...... 10 Guiding Principles, Development Process, and Acknowledgements...... 11 SNOMED CT®: A Comprehensive Terminology for Health Care...... 11 Acknowledgements of Contributors to SNOMED CT®...... 13

Chapter 1: Introducing SNOMED CT...... 15 Overview ...... 16 SNOMED CT Data Structure – Summary...... 17 Getting Started with SNOMED CT...... 17

Chapter 2: Core Table Structure...... 20 Overview...... 21 Core Tables – Summary...... 21 Concepts Table – Summary ...... 21 Descriptions Table – Summary...... 22 Relationships Table - Summary...... 22

Chapter 3: Subset Mechanism...... 24 Overview ...... 25 Subset Tables – Summary...... 27 Released Subsets...... 29

Chapter 4: Cross-Mapping...... 31 Overview ...... 32 Cross Mapping Tables – Summary...... 33 Released Cross Mappings...... 36

Chapter 5: History...... 37 Overview ...... 38 History Mechanism...... 39 Component History Rules...... 40 Adding a Component ...... 40 Changing the status of a Component ...... 40 Making minor changes to Component ...... 41

Making significant changes to a Component ...... 41 Disambiguation of a Component ...... 42 Retiring, Inactivating, or removing a component ...... 42 Concept Status changes...... 42 Representation of material in the SNOMED CT First Release...... 49

Chapter 6: The Stated Relationships Table...... 52 Overview ...... 53 Stated Relationships Table Summary...... 53

Chapter 7: Index and Search Support Tables...... 55 Overview ...... 56 Word Search Tables – Summary...... 57 Word Equivalents...... 57 Word Equivalents Tables – Summary...... 58

Chapter 8: Extensions...... 59 Extension Requirements...... 60 Extension Tables – Structure...... 61 Specification for Namespace within the SCTID...... 62 Component Guidelines...... 63 Transfer of Responsibility between Organizations ...... 63 Released Extensions ...... 65

Appendix A: SNOMED CT Data Structures...... 66 SNOMED CT Data Structure Detail ...... 67 Core Tables Data Structure Detail ...... 68 Subset Mechanism Data Structure Detail...... 69 Cross Mapping Mechanism Data Structure Detail ...... 70 History Mechanism Data Structure Detail ...... 71 Developer Toolkit Structure Overview...... 72

Appendix B: Table Structure Details...... 73 Concepts Table...... 74 Key Fields...... 74 Data Fields...... 74 Descriptions Table ...... 77 Key Fields...... 77 Data Fields...... 78 Relationships Table...... 81 Key Fields...... 82

Data Fields...... 82 Subset Mechanism...... 85 Subset Table...... 85 Subset Members Table...... 88 Subset Definition File...... 98 Cross Maps...... 98 Cross Map Sets Table...... 98 History...... 115 Component History Table...... 115 References Table...... 118

Appendix C: The SNOMED Clinical Terms Identifier (SCTID)...... 120 Introduction ...... 121 SCTID Data Type ...... 121 SCTID Representation ...... 121 SCTIDs and Extensions ...... 122 SCTID Constraints ...... 122 Check-digit ...... 123 Partition-identifier ...... 123 Extension namespaces ...... 124 Item identifier digits ...... 124 Example SCTIDs ...... 124

Appendix D: Distribution Files ...... 126 Distribution Media ...... 127 File Formats ...... 127 Directory Structures and Naming Conventions ...... 128 Terminology version information ...... 128

Appendix E: Unicode UTF-8 encoding...... 129 Introduction ...... 130 Character encoding ...... 130 Single byte encoding ...... 130 Two byte encoding ...... 130 Three byte encoding ...... 130 Notes on encoding rules ...... 131 Example encoding ...... 131

Appendix F: Check-digit computation...... 132 Introduction ...... 133 Reasons for using a check-digit ...... 133 A brief comparison of check-digit effectiveness ...... 133

The IBM Check ...... 133 The ISBN Check (Modulus 11) ...... 134 Verhoeff’s Check ...... 134 Verhoeff’s Dihedral Group D5 Check ...... 134 Sample Java Script for computing Verhoeff’s Dihedral Check ...... 135 Sample Visual Basic for computing Verhoeff’s Dihedral Check ...... 137

Appendix G: Top Levels and Special Codes...... 139 The Root Concept Code and the Root Metadata Code...... 140 Top Level Concept Codes ...... 140 Qualifier value...... 141 Special Concept ...... 141 Linkage concept ...... 142 Top Level Metadata Codes...... 143 Core metadata concept...... 143 Foundation metadata concept...... 143

Appendix H: Cross Mappings Guide...... 144 Introduction ...... 145 SNOMED CT to ICD-9-CM Epidemiological and Statistical Map ...... 147 Mapping Categorization Methodology ...... 147 SNOMED CT to ICD-9-CM Cross Mapping – Examples ...... 147 SNOMED to ICD-O Cross Mapping ...... 151 SNOMED CT to ICD-O Cross Mapping – Example ...... 151 SNOMED CT – LOINC® ...... 153 Cross Mapping Rules...... 153 Introduction ...... 153 Nature of the Rules ...... 153 Representation ...... 153 Processing order ...... 154 Applying rules to Cross Map Targets ...... 156 Mapping Model ...... 157 Simple one-to-one mapping ...... 159 Simple one-to-many mapping ...... 159 Mapping with options ...... 159

Appendix I: Supplementary Text Descriptions...... 161 Supplementary Text Descriptions Table...... 162

Appendix J: SNOMED CT Allowed Attributes and Values...... 190 Defining Attributes by Hierarchy and Domain...... 191 Allowable Ranges...... 197

Appendix K: Glossary...... 202 A...... 203 B...... 203 C...... 203 D...... 206 E...... 208 F...... 209 H...... 209 I...... 209 K...... 210 L...... 210 M...... 211 N...... 212 O...... 213 P...... 213 Q...... 215 R...... 215 S...... 217 T...... 219 U...... 220 W...... 221

© 2002-2010 The International Health Terminology Standards Development Organisation (IHTSDO). All Rights Reserved. SNOMED CT® was originally created by The College of American Pathologists. "SNOMED" and "SNOMED CT" are registered trademarks of the IHTSDO. SNOMED CT has been created by combining SNOMED RT and a computer based nomenclature and classification known as Clinical Terms Version 3, formerly known as Read Codes Version 3, which was created on behalf of the UK Department of Health and is Crown copyright. This document forms part of the International Release of SNOMED CT distributed by the International Health Terminology Standards Development Organisation (IHTSDO), and is subject to the IHTSDO's SNOMED CT Affiliate Licence. Details of the SNOMED CT Affiliate Licence may be found at www.ihtsdo.org/our-standards/licensing/. No part of this document may be reproduced or transmitted in any form or by any means, or stored in any kind of retrieval system, except by an Affiliate of the IHTSDO in accordance with the SNOMED CT Affiliate Licence. Any modification of this document (including without limitation the removal or modification of this notice) is prohibited without the express written permission of the IHTSDO. Any copy of this document that is not obtained directly from the IHTSDO (or a Member of the IHTSDO) is not controlled by the IHTSDO, and may have been modified and may be out of date. Any recipient of this document who has received it by other means is encouraged to obtain a copy directly from the IHTSDO, or a Member of the IHTSDO. (Details of the Members of the IHTSDO may be found at www.ihtsdo.org/members/).

General Introduction

Purpose This document describes the existing file structure of SNOMED Clinical Terms® as accepted and released by the International Health Terminology Standards Development Organisation (IHTSDO).

Who should read this guide? The intended audience for this document is any individual or any organization that wishes to develop or use systems that will use SNOMED Clinical Terms. This document is to provide a reference about the SNOMED CT technical structure for: Software developers • Developers of fully integrated applications • Developers of terminology servers • Developers of applications that use terminology Health informatics specialists, analysts, purchasers, and integrators • Health informatics specialists analyzing the needs of users and organizations • Purchasers of healthcare information systems • Healthcare information systems implementers and integrators • Standards developers

Scope and format This document uses material from the SNOMED CT technical specifications that were used to create the work. Additional functions are added to this document as they are delivered in SNOMED CT. Any functions marked “For Future Use” are not implemented in the current release.

Feedback Further information about SNOMED CT is available on the Internet at:

www.ihtsdo.org

Please send feedback by email to:

[email protected]

or contact:

IHTSDO Rued Langgaards Vej 7, 5te DK-2300 Copenhagen S Denmark Tel: +45 3644 8736 Fax: +45 4444 8736

Inventory of Documentation

The following essential SNOMED CT documentation is currently available in both English and Spanish versions as part of the International Release of SNOMED CT from the International Health Terminology Standards Development Organisation (IHTSDO): SNOMED CT Technical Reference Guide (TRG) The TRG is intended for SNOMED CT implementers, such as software developers. The TRG assumes an information technology background. Clinical knowledge is not a prerequisite. The TRG contains reference material related to the current release of SNOMED CT and includes file layouts, field sizes, required values and their meanings, and high-level data diagrams. It can be used to install and use SNOMED. SNOMED CT Technical Implementation Guide (TIG) The TIG is intended for SNOMED CT implementers, such as software designers. The TIG assumes information technology and software development experience. Clinical knowledge is not required, although some background is helpful to understand the application context and needs. The TIG contains guidelines and advice about the design of applications using SNOMED CT, and covers topics such as terminology services, entering and storing information, and migration of legacy information. SNOMED CT User Guide The User Guide is intended for clinical personnel, business directors, software product managers, and project leaders; information technology experience, though not necessary, can be helpful. The User Guide is intended to explain SNOMED CT's capabilities and uses from a content perspective. It explains the content and the principles used to model the terminology.

Additional Documentation The following supplementary documentation is also included, in English only, as part of the International Release of SNOMED CT: • SNOMED CT Canonical Table Guide • SNOMED CT Developer Toolkit Guide • SNOMED CT Namespace Identifier Guide • SNOMED CT Namespace Registry • SNOMED CT Stated Relationships Guide: Tabular Format and OWL Transformations

Document History

Version Notes

January The SNOMED CT Technical Reference Guide was first made available with the January 2003 2003 Release and includes updates to the draft of July 2002. The Technical Reference Guide consolidates material from these SNOMED CT specification documents: • Technical Specification of the Core Structure • Subsets Tables and Mechanisms • History Tables and Mechanisms • Proposed Structures for Cross Mapping Tables • Glossary

July 2003 • Supplementary Text Descriptions (Appendix I) was added • Detailed material for the Word Search Tables and the Canonical Table moved to separate documentation for the Developer Toolkit and Canonical Table • Acknowledgements, previously in the separate memo “A Note from the Chair,” were added before Section 1 • A subsection for the new PNDS Mapping was added

January • References to the new Subset Kit and approval of the SNOMED core table structure as the 2004 ANSI standard for healthcare terminology added • A subsection for the new NOC Mapping added • New Appendix added for SNOMED CT Attributes and Values Allowed by Domain

July 2004 • A new Clinical Care Classification map was added • Subsections for CCC and Omaha mappings were added

January • Copyright date update 2005 • Contacts update • Merged Historical Relationships Table into Relationships Table • Updated Subset Definition File Overview

January • Copyright date update 2007 • Header and Footer changes • Removed reference to Modified Technical Reference Guide • Removed reference to the Technical Reference Guide • Removed cross maps from list of components for which component history is tracked • Updated domain and range for attributes section; this is covered in depth in the User Guide

July 2007 • Updates to reflect transfer of IP to the International Health Terminology Standards Development Organisation • Removal of references to College of American Pathologists (CAP) products

January Updated for the January 2008 International Release 2008

Version Notes

July 2008 Updated for the July 2008 International Release • Revisions to the explanation of and data structures for the References Table

January Updated for the SNOMED CT International Release 2009 • Appendix I (Supplementary Text Descriptions) removed – readers should refer to the Text Definitions table included in the International Release • Appendix J (SNOMED CT Allowed Attributes and Values) removed – readers should refer to the SNOMED CT User Guide for this information • Content of Section 7 (Introduction to Canonical Forms) removed – this information is distributed separately as the Canonical Table Guide – and replaced with documentation of the Stated Relationships Table

July 2009 Updated for the SNOMED CT International Release • Revisions to the explanation of and data structures for the References Table • Revisions to the allowable values for historical relationships

January • Changed method of generating document from MS Word to DITA, resulting in changes to 2010 document formatting and appearance • Changed rules related to Component History and Description statuses as a result of Limited (6) becoming an inactive ConceptStatus • Single-sourced and revised the Glossary • Added information about the metadata hierarchy and related changes, which are part of the January 2010 Technology Previews and will be incorporated into a future International Release

Guiding Principles, Development Process, and Acknowledgements

SNOMED CT®: A Comprehensive Terminology for Health Care

In 1999, the College of American Pathologists (CAP) and the U.K. formed a strategic alliance to create a convergence of SNOMED® Reference Terminology (SNOMED RT) and Clinical Terms Version 3 (CTV3). The resulting work, SNOMED Clinical Terms® (SNOMED CT®) combines the robust strength of SNOMED RT in the basic sciences, laboratory and specialty medicine with the highly granular primary care content of CTV3 (formerly known as the Read Codes). The result is a comprehensive and precise clinical reference terminology that provides unsurpassed clinical content and expressivity for clinical documentation and reporting. SNOMED terminology enables clinicians, researchers and patients to share comparable data worldwide, across medical specialties and sites of care. SNOMED CT was founded on four basic principles that have guided development activities related to the distribution table structure and clinical content, and will continue to guide the future directions of SNOMED.

These guiding principles are: 1. Development efforts must encompass broad, inclusive involvement of diverse clinical groups and medical informatics experts. 2. The clinical content must be quality focused and adhere to strict editorial policies. 3. The quality improvement process must be open to public scrutiny and vendor input, to ensure that the terminology is truly useful within healthcare applications. 4. There must be minimal barriers to adoption and use. The design of SNOMED CT has been driven by the expressed needs of software developers for features that improve their ability to develop useful applications. In response to these needs, the design adds unique numeric identifiers, includes links to legacy codes, supports a sustainable migration and maintenance strategy, permits adaptability for national purposes, and fosters alignment with other terminologies and standards such as HL7, LOINC, and DICOM. We believe SNOMED CT delivers on a promise of standardized quality clinical terminology that is required for effective collection of clinical data, its retrieval, aggregation and re-use as well as the sharing, linking and exchanging of medical information. The SNOMED CT distribution structure (Release Format 1 or RF1) has been balloted and approved as an ANSI standard.

SNOMED CT Quality Development Process The SNOMED CT development process incorporates the efforts of a team of internal and external modelers. A documented scientific process is followed which focuses on understandability, reproducibility and usefulness. Content is defined and reviewed by multiple clinician editors. Conflicts between editors are resolved through an iterative process, based on achieving agreement and consensus, before being entered into the terminology. As necessary, additional experts are consulted to review the scientific integrity of the content. The integration of SNOMED RT and Clinical Terms Version 3 to create the first release, was a three year process that involved several stages of review and quality assurance: • Description mapping: NHS editors evaluated each SNOMED concept and term and mapped it to the Clinical Terms Version 3 terminology; SNOMED editors performed the same task mapping primarily disorders and procedures from Clinical Terms Version 3 to SNOMED RT. • Description mapping conflict resolution: Mapping discrepancies that occurred between NHS and SNOMED editors underwent a conflict resolution process to definitively place each concept within the merged hierarchy. • Auto-classification: The merged database following description mapping conflict resolution underwent a series of quality control checks including auto-classification to identify and eliminate cycle errors (e.g. concept A “is-a” B and concept B “is-a” A) and equivalency errors (e.g. where two defined concepts have the exact same definition). • Hierarchy review: The reviewed database has undergone auto-classification and further review of inferred hierarchies. • Ongoing refinement: The quality control process is continuously supplemented by feedback from users involved in adoption of SNOMED Clinical Terms.

Extent of Review The quality processes used in the development of SNOMED CT were complemented with external review. • Technical review: The technical specifications for SNOMED CT were published for comment on both the SNOMED and NHS websites. • Alpha test review: Forty-two organizations in six countries tested the SNOMED CT alpha test file and completed a structured assessment instrument. • Alpha test feedback: Debriefing sessions were conducted in the U.S., in the U.K. and in Australia, at which time test sites shared their positive experiences and recommendations for improvement. • Peer review: The methods used in developing SNOMED CT were presented in 6 scientific papers at the 2001 American Medical Informatics Association (AMIA) meeting, the largest association of leaders in medical informatics in the world. SNOMED CT was also part of an additional three papers and six posters at the 2002 AMIA meeting and additional posters for AMIA 2003 and 2004. SNOMED CT was also the subject of papers in the American Health Information Management Association (AHIMA) Journal in 2001-2003, posters at 2001 and 2002 annual meetings and presentations at the 2003 and 2004 annual meetings. In addition, AHIMA introduced an education program “Introduction to Clinical Terminology” in 2004 with a SNOMED CT component. Early adopters of SNOMED RT (a structure that mirrored SNOMED CT core tables) were debriefed on their implementation experience in order to identify the key issues to be addressed in the SNOMED CT Technical Implementation Guide.

Continuous Quality Improvement Continuous improvement is our aim: Updating the breadth and scope of the content to reflect changes in clinical care and advances in medical science; refining the content to deliver greater precision for data collection, retrieval and aggregation; and enhancing the functionality to serve our users better.

Acknowledgements of Contributors to SNOMED CT®

SNOMED CT was originally created by the College of American Pathologists. SNOMED CT has been created by combining SNOMED RT and a computer based nomenclature and classification known as Clinical Terms Version 3, formerly known as the Read Codes Version 3, which was created on behalf of the U.K. Department of Health and is Crown copyright.

The IHTSDO also acknowledges the contributions of: • The American Academy of Ophthalmology, for the ophthalmology-related portions of this work. • SNODENT®: the Systematized Nomenclature of Dentistry, copyright 1998, American Dental Association. Used with permission. • SNOVET®: the Systematized Nomenclature of Veterinary Medicine, copyright 1982, 1993, American Veterinary Medical Association. Used with permission. • LOINC®: the Logical Observation Identifier Names and Codes, copyright 1995-2008, Regenstrief Institute LOINC Committee. All rights reserved. • NANDA®: North American Nursing Diagnosis Association Taxonomy II, copyright 2005- 2008, NANDA International. All rights reserved. • The Perioperative Nursing Data Set® (PNDS), copyright 2002, AORN, Inc. All rights reserved. • The Omaha System, copyright 1992, Martin and Associates. Used with permission. • The Clinical Care Classification, copyright 2004, V.K. Saba. Used with permission. • The Nursing Interventions Classification (NIC), copyright 2004, Mosby, Inc., and the Center for Nursing Classification and Clinical Effectiveness at the University of Iowa College of Nursing. Used with permission. • The Nursing Outcomes Classification (NOC), copyright 2004, Mosby, Inc., and the Center for Nursing Classification and Clinical Effectiveness at the University of Iowa College of Nursing. Used with permission. • This work contains material from the AJCC Cancer Staging Manual, Sixth Edition (2002) published by Springer-Verlag New York. Used with permission of the American Joint Committee on Cancer (AJCC), Chicago, Illinois. • The Anesthesia Patient Safety Foundation’s (APSF) Data Dictionary Task Force. Some material contributed. Copyright 2003, APSF, Inc. Used by permission of the APSF. • This work contains terms from the British Association of Dermatology (BAD), and is used by permission of BAD. Crown Copyright 2003 British Association of Dermatologists. • This work contains terms from The Royal College of Anaesthetists (RCoA), and is used by permission of RCoA. Crown Copyright 2003 The Royal College of Anaesthetists. • This work contains terms from the Authorized Osteopathic Thesaurus, and is used by permission of the American Association of Colleges of Osteopathic Medicine and the American Osteopathic Association.

Chapter 1

Introducing SNOMED CT

Topics:

• Overview • SNOMED CT Data Structure – Summary • Getting Started with SNOMED CT

Overview

The SNOMED CT structure is composed of several tables and mechanisms as shown below.

Figure 1: SNOMED CT Data Structure Overview

• Core – The Core Tables contain the Concepts, Descriptions, and Relationships of the SNOMED CT terminology. The other structural mechanisms support and enrich the core table structure for terminology implementers. Briefly, these other mechanisms include: • History – History files are typically useful for upgrading an implementation of SNOMED to a new SNOMED CT release. History files include a log of Concept and Description additions, inactivations and minor changes. History files also include information about what concepts can be used in place of inactivated (retired) concepts. • Subsets – Subsets define a smaller collection of SNOMED CT Concepts, Descriptions, or Relationships. • Cross Mappings – Cross Mappings relate SNOMED CT to a target classification or coding scheme such as ICD-9 or ICD-10, in order to allow SNOMED CT-encoded data to be expressed using the target scheme for a particular purpose or use case. • Extensions – Extensions consist of terminology content developed to supplement, but not replace, the content contained in the Core. Extension content may be used to meet requirements that are not sufficiently universal to justify the creation of Core content. An example would be a national drug extension, containing concepts for the proprietary drugs available within a particular country. Extensions may be developed and maintained by the IHTSDO, a National Release Center or an authorized organization. • Developer Toolkit – Tables in the Developer Toolkit can be helpful for software developers directly or as examples that can be customized by installation and include: • Indexes, Word Equivalents, and Duplicate Term files that are helpful for search applications • Sample navigational hierarchies that can be used to manage the display of SNOMED concepts and viewing sequences

• Canonical Table – The canonical table is useful for determining the logical equivalence of concepts that may be represented in multiple ways. This guide provides details about the SNOMED CT data structures. This section provides an overview of the structure and answers some of the frequently-asked questions which may be helpful if you are new to SNOMED CT.

SNOMED CT Data Structure – Summary

This diagram shows the SNOMED CT tables and how they are interrelated. See SNOMED CT Data Structures on page 66 for a full-page version of this diagram.

Figure 2: SNOMED CT Data Structure Summary

Getting Started with SNOMED CT

These questions and answers may be helpful if you are just getting started with SNOMED CT. What is SNOMED CT? What is included? SNOMED CT is a comprehensive clinical terminology that provides clinical content and expressivity for clinical documentation and reporting. It is a concept-based terminology, which means that each medical concept is uniquely identified and can have multiple descriptions. All descriptions for the same concepts are linked together. Concepts are related to each other by hierarchical relationships, and a concept can be in more than one hierarchy. Relationships are also defined to describe additional attributes of concepts. Relationships can then be used by applications to group and classify SNOMED-encoded data as needed.

The International Release of SNOMED CT is maintained by the International Health Terminology Standards Development Organisation (IHTSDO). Each IHTSDO Member country maintains and distributes a National Release of SNOMED CT for use within its territory. See the readme.txt file for a complete list of files included in the International Release. These files can be loaded into the specific file or database system used at your location, and are an ANSI standard format. SNOMED CT files are UTF-8 encoded to support character sets from around the world. Some database products, such as Oracle, require UTF-8 to be specified in advance; if UTF-8 is not specified, there may be some difficulty with using and displaying the special characters used in some of the terms. Note that these special characters are used occasionally in the SNOMED English language edition, as well as International Editions. Some English language medical terms include the name of an individual which may contain special characters. What is the structure of each file? Refer to the appendices for an explanation of each file, field, and enumerated value. The readme.txt file lists the size of each file for validation after downloading. There are quite a few files. Where should I start? The best place to start is with the “core tables”. These files are in the essential resources directory. The core tables consist of the Concepts, Descriptions, and Relationships tables. You will also need to use the language/dialect Subset tables to determine what descriptions are preferred and synonyms. SNOMED CT concepts are the heart of the terminology. Each concept is in the Concepts Table with a status value. Each concept has two or more descriptions that can be found in the Descriptions Table. Each concept is related to other concepts through relationships that are found in the Relationships Table. How can I actually see SNOMED CT? One way to see SNOMED CT is to use a terminology browser that supports SNOMED CT. Not all terminology browsers display SNOMED CT in its native format due to the fact that they support the display of other terminologies and classifications. What's next? Depending upon your implementation, you may want to review one or more of the sections of this Guide to better understand these capabilities: • Subset Mechanism – defines a smaller set of SNOMED CT concepts or descriptions. • Cross Mappings – maps SNOMED CT to coding schemes such as the ICD-9-CM classification. • History – this mechanism is typically useful for upgrading your implementation of SNOMED to a new SNOMED CT release. It includes a log of concept and description additions, inactivations and minor changes. You may also get more information from other documents provided by the IHTSDO: • SNOMED CT Technical Implementation Guide • SNOMED CT User Guide • Developer Toolkit – these tools can be helpful for software implementers directly or as models that can be customized for your site as: • Indexes, word equivalents, and duplicate term files that are helpful for search applications • Sample navigational hierarchies can help manage the display of SNOMED concepts and viewing sequences. • Canonical Table - the canonical table is helpful for determining the equivalence of concepts that may be expressed in multiple ways. How should I use SNOMED CT in my application? There are many ways to use SNOMED CT effectively. For design guidance, refer to the Technical Implementation Guide. How can I understand the SNOMED CT content, relationships, and terminology development principles? The IHTSDO website, www.ihtsdo.org , is a great place to start for an overview.

The SNOMED CT User Guide provides depth on the terminology development approach and the attributes used for the logical definitions (description logic) of concepts. This guide is derived from the guidelines used by the terminology authors themselves. Other key published materials include: • Desiderata for Controlled Medical Vocabularies in the Twenty-First Century, Cimino, J.J., Method Inf Med 1998 Nov; 37(4-5) 394-403. This article explains the goals for modern medical terminology and the supporting rationale. These principles provide the foundation of SNOMED CT's content and technical architectures. • Normal Forms for Description Logic Expressions of Clinical Concepts in SNOMED RT, Spackman, K.A., Proceedings/AMIA Annual Fall Symposium: 627-31 (2001) This article explains description logic, normal forms, and types of equivalence.

How can I contact the IHTSDO? IHTSDO's contact details are as follows:

[email protected]

IHTSDO Rued Langgaards Vej 7, 5te DK-2300 Copenhagen S Denmark Tel: +45 3644 8736 Fax: +45 4444 8736

While brief, we hope this section has helped you get started installing and working with SNOMED CT.

Chapter 2

Core Table Structure

Topics: This chapter focuses upon the three core components of SNOMED Clinical Terms: • Overview • Core Tables – Summary 1. clinical concepts 2. terms used to describe concepts, and 3. relationships between concepts. This section describes the logical structure of these elements and the physical structure of the files in which they are distributed. See Table Structure Details on page 73 for full details.

Overview

® The core structure of SNOMED Clinical Terms comprises the following three tables:

Concepts Table Each row in this table represents a clinical concept. Descriptions Table Each row in this table specifies a term that can be applied to describe a single clinical concept. Relationships Table Each row in this table specifies a relationship between two clinical concepts. The nature of each relationship is represented using a special kind of clinical concept. The figure below illustrates the relationships between these tables.

Figure 3: SNOMED CT Core Structure Overview

• A concept is described by the term in 2-n descriptions • Each description refers to one concept • A relationship refers to three concepts: a source, target, and relationship type • A concept is the source of 1-n relationships (except the root concept) • A concept is the target of 0-n relationships • A concept represents the type of relationship

Core Tables – Summary

Concepts Table – Summary

Each row in the Concepts Table represents a clinical concept. Each Concept has a unique identifier and a Fully Specified Name specifying the nature of the concept.

Key Fields ConceptId The unique SNOMED Clinical Terms Identifier for this Concept.

Data Fields ConceptStatus The status of a Concept indicates whether it is in active use and, if not, indicates the reason for withdrawal from current use.

Data Fields FullySpecifiedName A unique phrase that describes a Concept in a way that is intended to be unambiguous. The Fully Specified Name is also present in the Descriptions Table. It is not the same as the Preferred Term, which is also in the Descriptions Table. The Fully Specified Name explains the meaning of the concept more fully than the Preferred Term to remove or reduce ambiguity. CTV3ID The Read Code for this Concept. SNOMEDID The SNOMED identifier for this Concept. IsPrimitive Indicates whether a Concept is Primitive or Fully defined by its current set of Defining characteristics.

Descriptions Table – Summary

Key Fields DescriptionId The unique SNOMED CT Identifier for this Description.

Data Fields DescriptionStatus The status of a Description indicates whether it is in active use and, if not, indicates the reason for withdrawal from current use. ConceptId The unique SNOMED CT Identifier of the associated Concept. Term The text of a Term used to describe the associated Concept. InitialCapitalStatus An indication of whether the capitalization status of the first character of the Term is significant. DescriptionType An indication of whether the Term is the Fully Specified Name, Preferred Term or Synonym for the Concept to which this Description applies. LanguageCode An indication of a Language or Dialect in which this Description is valid. The language or dialect subset ultimately defines the descriptions for each concept.

To identify the descriptions for any language edition, the appropriate Language Subset must be used. Do not use the Descriptions Table alone. The descriptions for each language edition (including English) are designated in the Subset.

Relationships Table - Summary

Each row in the Relationships Table represents a Relationship between two Concepts. The type of relationship is identified by reference to another Concept.

Key Fields RelationshipId The unique SNOMED CT Identifier of this Relationship.

Data Fields ConceptId1 The unique SNOMED CT Identifier of the Concept which is the source of this Relationship.

Data Fields RelationshipType The unique SNOMED CT Identifier of the Concept which represents the type of relationship between the related Concepts. ConceptId2 The unique SNOMED CT Identifier of the Concept which is the target of this Relationship. CharacteristicType An indication of whether a Relationship specifies a defining characteristic of the source Concept or a possible qualifying characteristic of that Concept. Refinability An indication of whether it is possible to refine the target Concept when this relationship is used as a template for clinical data entry. RelationshipGroup An integer value that links together Relationships which are part of a logically associated Relationship group.

The Relationships Table is concerned with definitions, qualifiers and additional facts about a Concept. Although it can also be used to display a hierarchy of subtypes it does not have a specified or natural display order. Ordering is supported by use of a Navigation Subset (see Subset Mechanism on page 24. In 2003-2004, some relationship types were packaged into a separate file called the Historical Relationships Table. These relationship types were merged into the Relationships Table starting with the January 2005 release.

Chapter 3

Subset Mechanism

Topics:

• Overview • Subset Tables – Summary • Released Subsets

Overview

What is a Subset? A Subset refers to a set of Concepts, Descriptions, or Relationships that are appropriate to a particular language, dialect, country, specialty, organization, user or context. In its simplest form, the Subset Mechanism is a list of SNOMED identifiers (SCTIDs). Each SCTID refers to one component of SNOMED CT that is a member of the Subset (called a “Subset Member”). As an analogy, think of SNOMED CT as a book. A Subset is like an index entry pointing to a set of pages relevant to a particular topic. The Subset Mechanism may be used to derive tables that contain only part of SNOMED CT. In some cases, these derived tables may also be centrally distributed (e.g. a release table containing only Descriptions for a particular International Edition). Please refer to Released Subsets on page 29 for a list of subsets now available. SNOMED CT provides for the Subset Types listed below. Some of these types are not yet in use.

Subset Types

Subset Type Summary Language Subset The Descriptions that contain terms applicable to a Language or Dialect. • A language is a vocabulary that has been given an ISO 639 language code. • A dialect is a modification of a language for a particular geography or cultural environment. Each Description may contain the Preferred Term, Synonym or Fully Specified Name for the associated Concept in that language or dialect. The same description may serve different purposes from one language subset to another – it may be a preferred term in one dialect and a synonym in another. Realm Concept Subset The Concepts applicable for a particular Realm. • A Realm is an area of expertise, preference or authority. Examples of Realms include: a specialty, a professional discipline, an organization, a country, or a specialty within a country (e.g. US Dental). A realm concept subset refers specifically to concepts, but it also affects the availability of descriptions and relationships. Only descriptions and relationships associated with the included concepts are allowed. Descriptions and relationships not associated with concepts in the subset are not referenced. Realm Description Subset The Descriptions applicable for a particular Realm. Realm Relationship Subset The Relationships applicable for a particular Realm. This subset is planned for future use.

Subset Type Summary Context Concept Subset The Concepts applicable to a particular context domain. • A context is a specified part or field of a patient record, application, protocol, query message, or other communication specification. A context concept subset refers specifically to concepts, but it also affects the availability of descriptions and relationships. Only descriptions and relationships associated with the included concepts are allowed. Descriptions and relationships not associated with concepts in the subset are not referenced. Context Description Subset The Descriptions applicable to a particular Context Domain. A specified set of permitted descriptions implies that concepts associated with the permitted descriptions will also be included in the subset.

Navigation Subset A set of Navigation Links representing an ordered hierarchy appropriate for display and user Navigation. Navigation Links are specified by the ConceptIds of parent and children Concepts. The Navigation Hierarchy may include SNOMED CT concepts and special SNOMED CT navigation concepts, which exist solely for the purpose of navigation.

Duplicate Terms Subset A set of descriptions (Preferred Terms and synonyms) that have similar or duplicate terms with the definition of the priorities of the terms.

The format of the Subset Members Table appears quite simple, containing only 4 fields: SubsetId, MemberId, MemberStatus and LinkedId. There are some underlying subtleties to this table, however. • The field MemberId has a different significance depending on the type of subset specified in the Subset Table. • The field MemberStatus has a different significance depending on the type of subset specified in the Subset Table. • The LinkedId field is only valid for Navigation Subsets and Duplicate Terms Subsets and has a different significance in both subsets.

How are subsets related to SNOMED CT? A Subset is a value-added feature of SNOMED CT. Subsets provide important information for the use and implementation of SNOMED CT. The fact that a SNOMED CT Component belongs to a particular subset provides information above and beyond the Component itself.

How big is a Subset? The size of a Subset may range from a single Component to the entire set of Concepts, Descriptions or Relationships. The number of Components in a Subset depends entirely on its purpose. For example: • A Language Subset may contain at least one Description for each Concept (i.e. hundreds of thousands of members). • A Subset of Concepts commonly used in a particular specialty may contain thousands of members.

• A Subset of Concepts that covers the set of procedures used in a specialty or discipline may contain several hundred members. • A Subset of Concepts applicable to fields in a structured message may have less than a hundred members. • A Subset of Concepts or Descriptions applicable to a clinical protocol, template or data entry field may contain very few members. SNOMED CT is a large terminology and subsets can define portions of the terminology for use by specific audiences. For example, a UK dialect subset for English may direct the user to descriptions for UK terms rather than all descriptions for English. Note that it is up to the implementer to determine if a subset is used dynamically or statically, and whether the subset contents are given precedence or used exclusively. Refer to the SNOMED CT Technical Implementation Guide for more information. Note that Subsets are not necessarily mutually exclusive. The contents of Subsets may overlap.

Are all Subset Members equal? The simple view of a Subset as a list of SCTIDs assumes that all Subset Members are equal. However, note that members of a Subset may have different uses or statuses in a Subset. For example, some Descriptions are Preferred Terms in a particular language while others are Synonyms. So while all Subset Members are equally part of the Subset, some of the additional information provided in the Subset may indicate a priority that is not equal for all members. Please read any documentation regarding how a subset is intended to be used prior to implementation.

Why specify a common Subset structure? Previous experience with large terminologies suggests that their size and breadth of scope can pose a challenge for users and implementers. There are many situations in which it is useful to limit the set of Concepts and/or Descriptions for a given purpose. The multinational, multilingual nature of SNOMED CT increases the size of the terminology and adds further requirements for limiting access to sets of Descriptions and Concepts appropriate to a particular country. The Subset structure supports many different requirements and enables them to be distributed in a common format.

Who creates, maintains, and distributes subsets? The IHTSDO creates, maintains, and distributes Subsets of SNOMED CT using the technical structure described in this document (see Released Subsets on page 29). The National Release Center of each IHTSDO Member country may create, maintain and distribute Subsets as part of its National Release of SNOMED CT. Under the IHTSDO's Affiliate License terms, other organizations may also develop Subsets using the same Subset technical structure for extension content, or a combination of core and extension content. These Subsets would typically be maintained by the organization that creates them. The role of different organizations in the creation, maintenance, and distribution of Subsets is subject to editorial and management policy. The IHTSDO is responsible for determining and implementing these policies.

Subset Tables – Summary

Introduction Subsets provide a way for users and implementers to limit the set of SNOMED CT Concepts and Descriptions for a particular purpose. There are several types of subsets already defined for specific goals, and other types will be utilized in the future.

A common file structure is used for all Subsets. This approach simplifies the release structure and installation process for all SNOMED users. Subsets are released using two tables: Subsets Table: Each row in this table describes one release of a Subset. This table includes SNOMED CT Subsets that are packaged together in the Subset Members table.

Subset Members Table: Each row in this table represents one member of a Subset. The member may be a Concept or a Description. One or more Subsets may be packaged together in this table.

Subsets Table – Summary Each row in the Subsets Table describes a Subset and characteristics of that Subset.

Key Fields SubsetId The unique SNOMED CT Identifier for this Subset.

Data Fields SubsetOriginalId The unique SNOMED CT Identifier for the original Subset of which this Subset is a version. SubsetVersion An integer incremented for each revised release of a Subset. SubsetName A name that describes the purpose or usage of this Subset. SubsetType Indicates the nature of the Subset and the type of SNOMED CT Component that may be a member of the Subset. LanguageCode Identifies the Language and optionally the Dialect to which the Subset applies (only used for description-based subsets: Language, Realm Description, and Realm Concept). RealmId Identifies the Realm to which the Subset applies. ContextId May identify the Context Domain to which the Subset applies.

Subset Members Table – Summary Each row in the Subset Members Table sets the status of a member of an identified Subset.

Key Fields SubsetId The unique SNOMED CT Identifier for this Subset. MemberId The SNOMED CT Identifier of this Subset Member. This may be a ConceptId, DescriptionId or RelationshipId.

Data Fields MemberStatus An integer specifying the status, type or order of this member. LinkedId Valid for Navigation and Duplicate Terms Subsets only. For Navigation Subsets it is the SNOMED CT Identifier for a Concept that is a Navigation child of the Subset Member. For Duplicate Terms Subsets it is the SNOMED CT Identifier for the highest priority Description sharing the Duplicate Term.

Subset Definition File – Summary The Subset Definition File is an XML document that contains the definition of a subset. The definition consists of a set of “rules” that can be applied to SNOMED CT to determine the membership of the subset, rather than having each member identified separately. The rules are expressed as clauses that contain tests for each concept or description. There are three types of tests: • Hierarchical Selection This test identifies concepts that are subtypes (descendants) or supertypes (ancestors) of a specified concept. For example, create a subset that contains ‘infectious disease’ and all its subtypes. • Relationship Selection This test identifies concepts that have a specified attribute and value. For example, create a subset that contains all concepts where the Finding Site (attribute) = ‘heart structure’ (value). • Property Selection This test identifies concepts that match a property value in the SNOMED CT release tables. For example, create a subset that contains all concepts with a Status = 0 (current concepts) or concepts that contain the text string ‘K deficiency.’

The Subset Definition File allows multiple tests to be used to define a subset, and to use true/false conditions to be specified to determine which tests, and in which sequence, the tests should be used. The tests determine the membership of the subset and the value of the Member Status field. The Subset Definition File also contains metadata about the subset, such as the Subset Identifier, the Subset Version, the Language Code, and Realm Identifier. The Subset Definition File can be used to represent concept and description subsets. It cannot be used for navigation subsets, or for duplicate terms subsets. Future specifications for the Subset Definition File may enable multiple subsets to be specified in one file, and for one subset to be used as the basis for another subset so that only the differences between the subsets need to be specified.

Released Subsets

The following subsets are maintained and licensed by the IHTSDO. The date of first issue and, where appropriate, retirement are noted.

Subset Type of Subset Subset Contents US English Dialect Subset Language/ Dialect Identifies Descriptions that are appropriate for the US dialect of the English Language. This subset applies to the English Language Descriptions Table. This Subset was first available with the First Release US Edition. UK English Dialect Subset Language/ Dialect Identifies Descriptions that are appropriate for the British dialect of the English Language. This subset applies to the English Language Descriptions Table. This Subset was first available with the First Release UK Edition.

Subset Type of Subset Subset Contents Spanish Subset Language Identifies Descriptions that comprise the Spanish Edition of SNOMED CT. This Subset is required to determine the contents of the Spanish release, which includes descriptions both in English and Spanish. This subset applies to the Spanish Edition Descriptions Table. This Subset was first available with the SNOMED CT Spanish Edition April 2002 Release. German Subset Language Identifies Descriptions that comprise the German Edition of SNOMED CT. This Subset is required to determine the contents of the German release, which includes descriptions both in English and German. This subset applies to the German Edition Descriptions Table. This Subset was first available with the SNOMED CT German Edition April 2003 Release. It is not currently maintained or distributed. SNOMED CT Top Level Navigational Subset Provides an example of a Navigation hierarchy using Navigation Hierarchy SNOMED CT's Top Level Concepts. Please refer to the Technical Implementation Guide for more information about how to define and use Navigation Subsets. This Subset was first available with the First Release Developer Toolkit. CTV3 Navigation Navigational Subset Provides an example of a Navigation hierarchy using Hierarchy CTV3’s top level concepts. Please refer to the Technical Implementation Guide for more information about how to define and use Navigation Subsets. This Subset was first available with the First Release Developer Toolkit. Duplicate Terms Subset Duplicate Terms Identifies Duplicate Terms and the favored term. Refer to the Developer Toolkit in this guide for more information. This Subset was first available with the July 2002 Developer Toolkit. US Drug Extension Realm Concept and Identifies Concepts and Descriptions that are currently Subsets Realm Description members of the US Drug Extension. These Subsets Subsets were first available with the July 2002 Release. SNOMED CT Relationship Navigation Subset Identifies the allowable range for each SNOMED CT Range Subset RelationshipType concept. For example, the RelationshipType ‘Procedure site’ receives as values or alternatively has a range of concepts that are descended from Anatomical concepts. SNOMED CT Relationship Navigation Subset Identifies the allowable domain to which each Domain Subset SNOMED CT RelationshipType can be applied. For example, the RelationshipType concept ‘Procedure site’ can be applied concepts that are descended from ‘Procedure.’

Chapter 4

Cross-Mapping

Topics:

• Overview • Cross Mapping Tables – Summary • Released Cross Mappings

Overview

The Cross Mapping mechanism enables distribution of Cross Maps from SNOMED Clinical Terms in a common structure. Cross Mappings ensure that SNOMED CT can be used to effectively reference other terminologies and classifications. Each cross map matches SNOMED concepts with another coding scheme that is called the “target scheme". The cross mapping structure enables: • Automatic mapping from one SNOMED CT Concept to a single appropriate matching code in the Target Scheme. • Automatic mapping from one SNOMED CT Concept to a single collection of codes in a Target Scheme that together represent the same Concept. • Manual choice from a set of options for mapping a SNOMED CT Concept to a Target Scheme with several possible ways of representing the same or similar Concepts. The cross mapping structure does not enable: • Mapping from post-coordinated collections of SNOMED CT Concepts to a single Target Code or a specific collection of Target Codes (e.g. mapping a combination of a disorder qualified by severity or a procedure qualified by urgency). • Mapping from multiple fields in a patient record to a specific Target Code that represents a combination of characteristics (e.g. mapping a combination of a disorder, procedure and the age and sex of the patient to a single grouper code). This structure is based on the practical experience of the Cross Mapping tables of Clinical Terms Version 3 (CTV3), which is one of SNOMED CT’s source terminologies. The Cross Mapping Mechanism function is designed to be flexible in its support of: 1. The number of source concepts mapped • A Target Scheme may include codes for: • A single SNOMED CT Concept • Example: A disorder Concept may map directly to an ICD classification code.

• A single statement consisting of a post-coordinated set of Concepts • Example: A procedure Concept qualified by an urgency Concept may map to a target procedure code.

• Several separate statements each represented using SNOMED CT Concepts. • Example: A diagnosis Concept plus a procedure Concept may map to a grouper code.

• One or more statements represented using SNOMED CT Concepts combined with additional information that is not represented as a SNOMED CT Concept. • Example: A disorder Concept plus the age and sex of the person may map to an ICD classification code.

• Current support is for mapping from a single SNOMED CT Concept. Additional functions may be considered in the future.

2. The number of Target Codes • A Target Scheme may represent a mapped Concept as:

• a single code • as a combination of codes • a choice of several possible mappings consisting of one or more codes

• Current support is for a single Target Code, multiple Target Codes, and a choice of single or multiple Target Codes.

3. The accuracy of mapping • A target mapping may represent a Concept • precisely • imprecisely • target more specific than source • target less specific than source • imprecise but neither more nor less specific

• An indication of accuracy can be associated with each Cross Map.

Practical requirements for mapping from SNOMED CT to other terminologies or classifications (Target Schemes) are not limited to mapping single Concepts in SNOMED CT to single Target Codes. The more general problem is to map information in a patient record that has been encoded using SNOMED CT Concepts into an appropriate Target Code or set of Target Codes. It will be impossible to map some Concepts to any Target Codes in some Target Schemes. A SNOMED CT Concept may be unmappable for one of several reasons: • It expresses a concept that is outside the domain covered by the Target Scheme • It is insufficiently detailed to provide a meaningful cross mapping • In this case a mappable code may be found by refining the SNOMED CT Concept (i.e. selecting an IS A descendant).

• It is too detailed and information will be lost in the mapping • If this loss of detail is unimportant with respect to the purpose of the mapping, it is possible to map the most proximal more generalized Concept that is mappable, or to create the map but indicate that the match is not 1:1.

• It is inappropriate to map the concept • For example, disorders that do not apply to humans need not be mapped to an ICD-9 code.

Cross Mapping Tables – Summary

The SNOMED CT structure for supporting Cross Mapping includes three tables:

Cross Map Sets Table Each row in this table represents a Target Scheme for which Cross Maps are available. Cross Maps Table Each row in this table represents one option for mapping a SNOMED CT Concept to a target code or set of codes in the Target Scheme. Cross Map Targets Table Each row in this table represents a code or set of codes in the Target Scheme, which provides a mapping for one or more SNOMED CT Concepts.

The relationships of these tables to one another and to the core tables of SNOMED CT are described below. See Table Structure Details on page 73 for details about the tables and Cross Mappings Guide on page 144 for information about available mappings.

Cross Maps Sets Table – Summary Each row in the Cross Map Sets Table identifies a Target Scheme to which SNOMED CT is mapped and specifies characteristics of the associated mapping.

Key Fields MapSetId The unique SNOMED CT Identifier for this Cross Map Set.

Data Fields MapSetName A name that describes this Cross Map Set. MapSetType Indicates the nature of the Cross Maps associated with this scheme. CrossMapType is used to indicate the inclusion of one to one, one to many and choices of maps. MapSetSchemeId A standard identifier for the Target Scheme. MapSetSchemeName The full name of the Target Scheme. MapSetSchemeVersion The version number of the Target Scheme as published by the issuing organization. MapSetRealmId The identifier of the Realm within which this mapping table is applicable. This is only used in cases where Realm specific business rules or guidelines alter the acceptable mappings. MapSetSeparator The character used as a separator between the individual codes in the Target Codes field of the Cross Map Targets. MapSetRuleType An indication of the types of rules used in the Cross Maps and Cross Map Targets.

Cross Maps Table – Summary Each row in the Cross Maps Table represents one option for mapping a Concept to a Cross Map Target. There may be several Cross Map options for a Concept. If so, each option is represented by a row in the Cross Maps Table. Each row may include rules for choosing that option and these rules may be expressed in machine-readable form and/or as textual advice to support manual coding.

Key Fields MapSetId The unique SNOMED CT Identifier for the Cross Map Set of which this Cross Map is a member. MapConceptId The SNOMED CT Identifier of the mapped Concept. MapOption An integer that distinguishes between alternative mappings for a single Concept.

Data Fields MapPriority Indication of the suggested order in which to present a series of options for mapping a Concept for manual assessment. The first of these is the default option for mapping the Concept. MapTargetId The unique SNOMED CT Identifier for a CrossMapTarget to which this Concept can be mapped.

Data Fields MapRule A machine processable expression of rules that determine whether this is an appropriate Cross Map. MapAdvice Textual advice to support manual mapping decisions between this Cross Map and other options for mapping the same Concept.

Cross Map Targets Table – Summary Each row in this table represents a code or set of codes in the Target Scheme, which provides a mapping for one or more SNOMED CT Concepts. A Cross Map Target may include a rule indicating the conditions in which it applies; this feature is not used in any Cross Map currently released by the IHTSDO.

Key Fields TargetId The unique SNOMED CT Identifier for this Cross Map Target

Data Fields TargetSchemeId A standard identifier for the Target Scheme from which the MapTargetCodes are derived TargetCodes A code or list of codes in the Target Scheme that represent an appropriate mapping for one or more Concepts TargetRule A machine processable expression of rules that determine the combinations of conditions to which this Cross Map Target applies TargetAdvice Textual advice expressing the combinations of conditions to which this Cross Map Target applies

® SNOMED CT – LOINC Integration Table – Summary The Laboratory LOINC1 database provides a standardized set of names and codes for identifying laboratory test results. Created by the Regenstrief Institute, the purpose of LOINC is to facilitate the exchange and pooling of results for outcomes management and research. Each LOINC code represents a unique laboratory test distinguished by six main parts that include the analyte measured, the property observed, the time aspect involved, the sample or system type, the scale of measurement, and where relevant the method of measurement. Taken together, these six components define a single laboratory test result. Additional details about LOINC, including access to the LOINC database files, is available from www.regenstrief.org/loinc/loinc.htm. SNOMED CT is a clinical reference terminology. SNOMED CT concepts are explicitly represented in a multi-hierarchical structure. Each of the six distinguishing parts of a given LOINC test result are found in SNOMED CT and assigned in a hierarchy. The integration exists as a table containing 11 columns. The first nine columns of the table are taken directly from the Laboratory LOINC version 1l database. The last two columns contain concept identifiers from SNOMED CT that relate a specific component of the LOINC test to the SNOMED CT hierarchy. ® See SNOMED CT - LOINC® Integration Table on page 104 for details of the SNOMED CT – LOINC Integration Table.

Released Cross Mappings

The following cross mappings are currently included in the International Release available from the IHTSDO. • ICD-9-CM (Clinical Findings) • ICD-O • LOINC Integration Table

Chapter 5

History

Topics:

• Overview • History Mechanism • Component History Rules • Representation of material in the SNOMED CT First Release

Overview

The content of SNOMED CT evolves with each release. The types of changes may include new Concepts, new Descriptions, and new Relationships between Concepts, new Cross-maps, new Subsets, as well as updates and retirement of any of these Components. These changes are driven by changes in understanding of health and disease processes; introduction of new drugs, investigations, therapies and procedures; new threats to health; as well as proposals and work provided by SNOMED partners and licensees. To achieve the goals stated in the widely-accepted paper on the desiderata for clinical terminologies, 2 the evolution of SNOMED follows these principles: • Graceful evolution rather than radical change. • The meaning of a Concept does not change. If the Concept’s meaning changes because it is found to be ambiguous, redundant or otherwise incorrect, the Concept is made inactive. One or more new Concepts are usually added to better represent the meaning of the old Concept. • Concepts may become inactive but are never deleted. Concept identifiers are persistent over time and are never reused. • The link between a Description and a Concept is persistent. If a Description is no longer pertinent for a Concept, the Description is inactivated. A new corrected Description for the Concept may be added. • Recognition of redundancy. • The same information can be stated two or more different ways. SNOMED is designed with a recognition of this possibility and facilitates recognition of equivalent statements. • When a Concept is inactivated as a result of duplication, SNOMED provides a reference to the continuing, active representation of that Concept.

A SNOMED CT Component is a Concept, Description or Subset. Changes to these components are included in the Component History. “Significant” changes generally require the component to be retired and replacement component(s) are added. The retirement and addition are recorded in the history records. Some changes have been designated as minor and only require a history record to record the change. Why is this history important? These Components may have been used directly in healthcare applications, or to define the terms used. For example, an inactive Description or Concept may have been used in: • Patient records • Data entry templates • Decision support protocols • Reusable searches, queries or analyses A change in a Relationship may alter the interpretation of stored information by protocols, queries and Subsets that include clauses which propagate across these Relationships. The history of Relationship changes may be computed by comparing different releases of the Relationships File; the IHTSDO does not provide this type of history file. Note that the Relationships File contains data about the history of the evolution of Concepts and supporting information. Therefore, an SCT-enabled application may want to modify searches, software, or update data convention tables as the terminology evolves. The SNOMED CT History Mechanism provides not only a history of changes, but also references to the current components that may be used instead. These references may be used in different ways. • To map legacy data to a current equivalent Concept

2 Desiderata for Controlled Medical Vocabularies in the Twenty-First Century, J.J. Cimino, Methods of Information in Medicine 1998:37:394-403

• To enable a query or protocol to include information represented using Inactive Concepts The History Mechanism is also used to track when the maintenance responsibility for one or more concepts is transferred between organizations. This requires the concept to be transferred from the SNOMED CT Core to an Extension, from an Extension to the Core, or between Extensions. See Extensions on page 59 for more information.

History Mechanism

The history mechanism involves these tables: • Component History Table • Component History References Table All SNOMED CT Components have a unique SNOMED CT Identifier. The structure of these identifiers is discussed in detail in The SNOMED Clinical Terms Identifier (SCTID) on page 120. When a Component is first added, it is allocated an identifier, which is unique, permanent and cannot be changed. A Component that is no longer required can be inactivated, and its identifier will never be reused. A limited set of permitted minor changes may be made to a Component as specified by the Component History Rules. A Component may be replaced by another Component to allow more significant changes. “Replace” means the original Component is inactivated and one or more replacement Components are added.

Component History Table – Summary The Component History Table identifies each change in the status of a Component and the Release Version in which the change was made.

Key Fields ComponentId The unique SNOMED CT Identifier for the changed Component ReleaseVersion The version of SNOMED CT in which this change was made

Data Fields ChangeType An indication of the nature of the change Status The status of this Component after the change Reason An optional text Description of the reason for the change

Note that the Relationships file shows the Relationships between inactive concepts to other equivalent or related Concepts.

References Table – Summary The References Table contains References from inactive Components to other equivalent or related Components that were current in the Release Version in which that Component was inactivated. Each Reference indicates the nature of the relationship between the inactive and persistent component. The References Table was first distributed as part of the July 2008 International Release of SNOMED CT.

Key Fields ComponentId The unique SNOMED CT Identifier for the inactive Component

Key Fields ReferenceType An indication of the nature of the relationship between the inactive Component and the referenced Component ReferencedId The unique SNOMED CT Identifier for the referenced Component

With one exception, there are no References Table entries where ComponentId refers to a Concept; for most Concepts, this history tracking functionality is included in the Relationships Table. However, ComponentId may refer to an inactive Concept with ConceptStatus = 10 (Moved Elsewhere), in which case the value of ReferenceType must be "1" (Replaced By) or "4" (Alternative), and ReferencedId will refer to a Concept. In addition, the ReferencedId field may also refer to a Concept when ComponentId refers to an inactive Description and ReferenceType = 7 (Refers to Concept). This use of the References Table permits a Description to be made inactive without having to retire its Concept. In such a case, the References Table indicates a Concept which is correctly described by the Term of the inactive Description.

Component History Rules

These are the rules used to create the Component History Table when Components are added or changed. Components are never removed, but their status may change from active to inactive. Special considerations for the SNOMED CT First Release are described in the last subsection.

Adding a Component

A newly added Component is distributed as: 1. A row in the Component History Table with: a. ChangeType value Added; b. ComponentId referring to the new Component; c. Status value for the Component (usually Current).

2. A row in the appropriate distribution table for the new Component.

Changing the status of a Component

All SNOMED CT Components have an active or inactive Status. When the Status of a Component is changed, this is distributed as: 1. A row in the Component History Table with: a. ChangeType value Status Change; b. ComponentId referring to the changed Component; c. Status value of the Component (usually one of the non-current status values)

2. If the Component is a Concept or Description, a row in the appropriate distribution table for the Component with its updated Status (usually one of the non-current status values). Components other than Concepts and Descriptions are only distributed when they are “current”. Therefore, there is no status field in the distributed Relationships, Subsets, Cross Map Sets or Cross Map Targets Tables. Note that the Relationships table contains Relationship Types that describe Relationships between inactive and active Concepts.

Inactive Concepts and Descriptions are included in the distributed tables to support data recorded when these Components were active. Therefore, the status of these Components is represented explicitly in the ConceptStatus and DescriptionStatus fields of the distributed tables. The reason for inactivation of a Concept or Description may vary and is represented by a range of status values.

Making minor changes to Component

Most changes to a Component require it to be inactivated and replaced by a new Component with a new SNOMED CT identifier. However, a specified set of minor changes is permitted without inactivating the Component. A minor change to a Component is distributed as: 1. A row in the Component History Table with: a. ChangeType value Minor Change; b. ComponentId referring to the changed Component; c. Status value for the Component (usually Current).

2. A row in the appropriate distribution table for the changed Component. Minor changes to Components are tabulated below:

Table Field Permitted minor changes Concepts FullySpecifiedName Changes in presentation such as changed capitalization, punctuation, spelling or revision due to changes in agreed presentation style are permitted as long as they do not change the specified meaning of the Concept. Some changes to the semantic type shown in parentheses at the end of the FullySpecifiedName may also be considered minor changes if the change in hierarchy does not alter the Concept’s meaning. Descriptions Term If DescriptionType is FullySpecifiedName Changes as permitted for Fully Specified Name in Concepts Table. Descriptions Term If DescriptionType is not FullySpecifiedName Capitalization changes only. Descriptions DescriptionType If DescriptionType is not FullySpecifiedName Changes to any value except FullySpecifiedName. Relationships Refinability Any change permitted. Subsets SubsetName Changes that alter the presentation or more clearly indicate the purpose of a Subset are permitted. Cross Map Sets MapSetName Changes that alter the presentation or more clearly indicate the purpose of a Cross Map Set are permitted.

Making significant changes to a Component

All changes other than those explicitly listed in the table of minor changes are regarded as significant changes.

A significant change to a Component is distributed as: 1. The Component is inactivated. See Changing the status of a Component on page 40. 2. A new Component with the changed information is added. See Adding a Component on page 40. 3. If the Component is a Description, a Subset or a Cross Map Set, there will also be a row in the Component History References Table indicating the Relationship between the inactive and active Components (Future Use). 4. If the Component is a Concept, there will also be a row in the Relationships Table indicating the relationship between the Inactive Concept and its active replacement Concept.

Disambiguation of a Component

If a Concept is found to be ambiguous it may be replaced by one or more new Components. These replacements are distributed in the same way as other significant changes. However, one or more new, active Components are added to replace the Component that was ambiguous.

Retiring, Inactivating, or removing a component

A retired Concept or Description is given an inactive status. The inactive status may describe the reason for the inactivation, such as duplicate. See Changing the status of a Component on page 40. Inactive Concepts and Descriptions continue to be released with SNOMED CT. A Relationship that is no longer valid is archived and no longer provided in the next SNOMED CT release. The Relationship Identifier will never be reused. Some “IS A” relationships that are no longer valid may become “WAS A” relationships (Future Use).

Concept Status changes

This section is concerned with the way in which Relationships and Descriptions are affected by changes in the status of their associated Concepts. These changes are necessary because: • An Inactive Concept cannot have any active Descriptions. • There are constraints on the Relationships of an Inactive Concept. There are three distinct aspects: • Changes to Descriptions - These changes are reflected in the Descriptions Table. • Retirement, or replacement, of Relationships. • Addition of Relationships that link an Inactive Concept to one or more active Concepts – These entries are added to the Relationships Table.

Impact on Descriptions The table below shows the permitted DescriptionStatus values according to the ConceptStatus of the associated Concept.

Table 1: Permitted DescriptionStatus values for possible ConceptStatus values

Permitted DescriptionStatus values Permitted with Concept Status 0 – Current (default value) 0 – Current 6 – Limited (default value) 6 – Limited

Permitted DescriptionStatus values Permitted with Concept Status 8 – Concept inactive (default value) 1 – Retired without stated reason 2 – Duplicate 3 – Outdated 4 – Ambiguous 5 – Erroneous 10 – Moved elsewhere

Any value 1 – Retired without a stated reason 2 – Duplicate 3 – Outdated 5 – Erroneous 7 – Inappropriate

10 – Moved elsewhere (default value) 10 – Moved elsewhere 11 – Pending move (default value) 11 – Pending move

When the Status of a Concept changes, the DescriptionStatus of all associated Descriptions is checked: • If it is in the list of permitted values for the new ConceptStatus it is not changed. • If it is not in the list of permitted values for the new ConceptStatus, it is changed to the default value listed for that ConceptStatus. Note that Descriptions that are already inactive at the time that a Concept is inactivated are left unchanged, while active Descriptions are changed to the value “Concept inactivated”. Thus Descriptions that were current at the time a Concept is inactivated have DescriptionStatus = 8. However, valid Descriptions of a limited Concept remain are marked as limited (DescriptionStatus = 6).

Impact on Relationships – General issues When a Concept is inactivated its Relationships are reassessed to avoid anomalies in the structures of SNOMED CT. The required and permitted Relationships following a change in ConceptStatus of one of the Concepts involved in the Relationship are summarized below.

Table 2: Relationships depending on Concept Status

ConceptId1 Concept Relationship Type ConceptId2 Concept Constraints Status Status WAS A No constraints 1 – Retired without stated 0 – Current reason 1 – Retired without stated 3 – Outdated reason 5 – Erroneous 3 – Outdated 6 – Limited 4 – Ambiguous 5 – Erroneous

ConceptId1 Concept Relationship Type ConceptId2 Concept Constraints Status Status 2 – Duplicate SAME AS One and only one 0 – Current Relationship of this type 11 – Pending move is required.

6 – Limited SAME AS These may be reciprocal 6 – Limited relationships. 4 – Ambiguous MAY BE A One or more 0 – Current Relationships of this type 11 – Pending move are required.

5 – Erroneous REPLACED BY One and only one 0 – Current Relationship of this type 11 – Pending move is permitted (optional). Must have at least one WAS A or one REPLACED BY. REPLACED BY 0 – Current One and only one 1 – Retired without stated Relationship of this type reason is permitted (optional). 3 – Outdated

MOVED TO 0 – Current One or more 10 – Moved elsewhere Relationships of this type 11 – Pending move are required and must refer to a Namespace Concept. Any value MOVED FROM Any number of these 10 – Moved elsewhere Relationships may exist (it 11 – Pending move is possible identical Concepts from more than one source were moved to this Namespace). ConceptId2 must be in a different Namespace from ConceptId1.

Table 3: Defining and qualifying Relationships depending on Concept Status

ConceptId1 Concept Relationship Type ConceptId2 Concept Constraints Status Status IS A No constraints 0 – Current 0 – Current 11 – Pending move 11 – Pending move

ConceptId1 Concept Relationship Type ConceptId2 Concept Constraints Status Status IS A 0 – Current One and only one 1 – Retired without stated Relationship of this type reason is required and it must 2 – Duplicate refer to the appropriate subtype of “Inactive 3 – Outdated concept”. 4 – Ambiguous 5 – Erroneous 6 – Limited 10 – Moved elsewhere

Other defining Any value appropriate to 0 – Current 0 – Current Relationships the Relationship Type. 11 – Pending move 11 – Pending move

Qualifying Relationships Any value appropriate to 0 – Current 0 – Current the Relationship Type. 11 – Pending move 11 – Pending move

Other defining or NONE PERMITTED NONE PERMITTED 1 – Retired without stated qualifying Relationships reason 2 – Duplicate 3 – Outdated 4 – Ambiguous 5 – Erroneous 6 – Limited 10 – Moved elsewhere

Impact on Relationships – ConceptID1 status change When a Concept is changed from being active to inactive, all of its defining and qualifying Relationships are inactivated. The “IS A” subtype Relationships associated with Concepts that are inactivated without a stated reason or are stated to be outdated or erroneous may be converted to “WAS A” relationships to retain any significant semantics related to legacy data encoded using these Concepts. The effects of this type of change may be wide reaching and have a significant impact on data files as well as software. Please refer to the Technical Implementation Guide for more information. The full set of changes is summarized in the following table.

Table 4: Changes to Relationships when the status of ConceptId1 changes

ConceptStatus: ConceptStatus: Relationships in which this is ConceptId1 Before After IS A subtype Other Defining Qualifiers Relationships Added 0 1 Retire or change Retire Retire IS A “Retired to WAS A Concept” (1) REPLACED BY (0 or 1) 2 Retire Retire Retire IS A “Duplicate Concept” (1) SAME AS (1) 3 Retire or change Retire Retire IS A “Outdated to WAS A Concept” (1) REPLACED BY (0 or 1) 4 Retire Retire Retire IS A “Ambiguous Concept” (1) MAY BE A (1+) 5 Retire or change Retire Retire IS A “Erroneous to WAS A Concept” (1) REPLACED BY (0 or 1) 6 Retire or change Retire Retire IS A “Limited to WAS A Concept” (1) REPLACED BY (0 or 1) 0 10 Retire Retire Retire IS A “Moved elsewhere Concept” MOVED TO Namespace (1+) 0 11 No change No change No change IS A “Pending move Concept” MOVED TO Namespace (1+) 11 10 Retire Retire Retire IS A “Moved elsewhere Concept” MOVED TO Namespace (unchanged) 11 0 No change No change No change Retire: IS A “Pending move Concept” Retire: MOVED TO Namespace

Impact on Relationships –ConceptID2 changes When a Concept is changed from being active to inactive, all the Relationships for which it provides the value (ConceptId2) must also be inactivated or replaced. In the case of a duplicate Concept, the value is replaced by a new similar Relationship with the current Concept that has the same meaning. In the case of an ambiguous Concept, the value may be replaced by a new similar Relationship with one of the disambiguated Concepts referred to by the ambiguous Concept. All inactive concepts can be found under the “Special Concept” hierarchy. The effects of this type of change may be wide reaching and have a significant impact on data files as well as software. Please refer to the Technical Implementation Guide for more information. Changes in status from current (ConceptStatus = 0) to limited (ConceptStatus = 6) constitute inactivation (Note: this is a policy change as of January 2010). A limited Concept cannot be the defining or qualifying value for any Concept. Any such Relationships are inactivated. The full set of such changes is summarized in the following table.

Table 5: Changes to Relationships when the status of ConceptId2 changes

ConceptStatus: ConceptStatus: Status of Concept1 IS A Relationships Other Before After in which this Relationships for Concept is which this Concept ConceptId2 is ConceptId2 0 or 11 1 0 or 11 Retire Retire 1 to 6 or 10 Retire or change to Retire WAS A 2 Any Retire and replace Retire and replace with equivalent with equivalent relationship to the relationship to the duplicated Concept. duplicated Concept 3 0 or 11 Retire Retire 1 to 6 or 10 Retire or change to Retire WAS A 4 Any Retire and optionally Retire and optionally replace with one of replace with one of the disambiguated the disambiguated Concepts. Concepts. 5 Any Retire or change to Retire WAS A 6 Any Retire or change to Retire WAS A 10 Any Retire and optionally Retire and optionally replace by the replace by the Concept in the new Concept in the new target namespace. target namespace. 0 11 Any No change No change 11 0 Any No change No change

Changes to Relationships when status of the RelationshipType Concept changes If a Concept that provides the RelationshipType for any Relationships is inactivated, all Relationships that refer to that Concept are inactivated and replaced.

Impact on Data Retrieval – Inactivation due to duplication When a Concept is inactivated because it is found to be a duplicate of another Concept a new “SAME-AS” Relationship is created to link the Inactive Concept to the duplicate Concept. This Relationship can be: • Selectively included or excluded in data retrieval criteria to enable access to relevant information recorded using the inactive equivalent ConceptId. • Used to allow legacy data to be upgraded to include the retained equivalent ConceptId.

Impact on Data Retrieval – Inactivation due to error When a Concept is inactivated and replaced because it requires a significant change a new “REPLACED-BY” Relationship is created to link the Inactive Concept to the replacement Concept. This Relationship can be: • Selectively included or excluded in data retrieval criteria to enable access to relevant information recorded using the replaced version of the ConceptId. • Used to allow legacy data to be upgraded to include the replacement ConceptId.

Impact on Data Retrieval – Inactivation due to ambiguity When a Concept is inactivated and replaced because it was found to be ambiguous, new “MAYBE-A” Relationships are created to link the Inactive Concept to the Concepts that represent each of its possible meanings. This Relationship can be: • Selectively included or excluded in data retrieval criteria to enable access to relevant information recorded using the ambiguous ConceptId. • If these Relationships are included the ambiguous Concept can be included in the results of a search for either of the possible meanings. • Used to allow ambiguous data to be linked to the ConceptIds associated with either or both potential meanings.

Impact on Data Retrieval – Moves between namespaces When a Concept is moved to another Namespace, a new “MOVED TO” Relationship is created pointing from the original Concept to the target Namespace Concept. When a Concept is moved in from another Namespace, a new “MOVED FROM” Relationship is created pointing from the new Concept to the original Concept in the other Namespace. When a Concept is moved in from an Extension Namespace into the SNOMED CT Core Namespace, the “MOVED FROM” Relationship is stored in the Extension relationships table and not the SNOMED CT Core relationships table. These Relationships can be used to allow a check for the replacement Concept in the new target Namespace. • The “MOVED TO” Relationship identifies the target Namespace to be searched. • The “MOVED FROM” Relationship, in material distributed by the organization responsible for the target Namespace, allows identification of the replacement Concept.

The “MOVED TO” Relationships exist for Concepts with the ConceptStatus values Moved Elsewhere (10) and Pending Move (11). The difference between these Status values is significant. The original Concept can still be used, retrieved and processed pending the availability of a replacement in the other Namespace. In some cases, a Concept marked as Pending Move may be rejected for inclusion in the other Namespace and its Status in the original Namespace may revert to “Current”.

Moved Elsewhere The original organization is no longer supporting this as an Active Concept. • It has no Active Descriptions • The only Relationships that it has are: • “IS A” “Moved elsewhere Concept” • “MOVED TO” • Therefore, without the replacement from the other Namespace this Concept cannot be processed or retrieved in any meaningful way.

Pending Move The original organization is still supporting this as an Active Concept. • Its Descriptions remain active (also marked with the same Status value) • Its Relationships include: • Its pre-existing Relationships (or those deemed to be appropriate) • “IS A” “Pending move Concept” • “MOVED TO”

Representation of material in the SNOMED CT First Release

This section details the initial settings in the Component History Table for the SNOMED CT First Release. These settings apply to Components that were in SNOMED RT or Clinical Terms Version 3 prior to the merger of these two terminologies. They also apply to Components added to SNOMED CT prior to the First Release. All Concepts in the First Release were regarded as having been added to SNOMED CT on or before the first release date (31 January 2002). Thus each has row in the Component History Table with ChangeType=“Added” and ReleaseVersion determined as follows: • Concepts in releases of SNOMED RT (including those also present in CTV3): • ReleaseVersion= YYYYMMDD (ISO format of date previously recorded in RT release files).

• Concepts released in Clinical Terms Version 3 before 31 January 2002 (excluding those also present in RT): • ReleaseVersion= “20020129”

• New Concepts in SNOMED CT First Release but not in either SNOMED RT or Clinical Terms Version 3 before 31 January 2002: • ReleaseVersion= “20020131”

• New Concepts in any subsequent release of SNOMED CT (whether or not released in CTV3 between SNOMED CT releases)

• ReleaseVersion= YYYYMMDD (ISO date of the SNOMED CT release)

Some Concepts had a ConceptStatus other than current in the SNOMED CT First Release. This occurred if the Concept: • was non-current in the source terminology or • was rendered non-current during the merge of the two terminologies. In either case there will be a row in Component History Table with the values ChangeType=“Status change”, Status= ConceptStatus (with a status consistent with the First Release) and ReleaseVersion determined as follows: • Concepts released in Clinical Terms Version 3 before 31 January 2002 (excluding those also present in SNOMED RT) which were not current in Clinical Terms Version 3 and were thus released in a non-current state in SNOMED CT. • ReleaseVersion= “20020130”

• Concepts released in SNOMED RT before 31 January 2002 which were retired in SNOMED RT and are thus released in a non-current state in SNOMED CT. • ReleaseVersion= YYYYMMDD (ISO format of date of change recorded in the RT release files).

• Concepts released in CTV3 or SNOMED RT before 31 January 2002 that were rendered inactive prior to release of SNOMED CT. • ReleaseVersion= “20020131”

The consequences of these rules are shown below. New Concepts added in SNOMED CT with current status

ComponentId ReleaseVersion ChangeType Status ConceptId 20020131 0 (added) 0 (current)

New Concepts added in SNOMED CT with limited status

ComponentId ReleaseVersion ChangeType Status ConceptId 20020131 0 (added) 6 (limited)

SNOMED RT-sourced (or dual sourced) Concepts that were current in SNOMED CT First Release.

ComponentId ReleaseVersion ChangeType Status ConceptId RT-release-date 0 (added) 0 (current)

SNOMED RT-sourced (or dual sourced) Concepts that were current in RT prior to 31 January 2002 but were non-current in SNOMED CT First Release. The date 31 January 2002 indicates retirement occurred in First Release.

ComponentId ReleaseVersion ChangeType Status ConceptId RT-release-date 0 (added) 0 (current) ConceptId 20020131 1 (status change) ConceptStatus

SNOMED RT-sourced (or dual sourced) Concepts that were retired in RT prior to 31 January 2002 and were non-current in SNOMED CT First Release.

ComponentId ReleaseVersion ChangeType Status ConceptId RT-release-date 0 (added) 0 (current) ConceptId RT-retired-date 1 (status change) ConceptStatus

Clinical Terms Version 3-sourced Concepts that were current in SNOMED CT First Release.

ComponentId ReleaseVersion ChangeType Status ConceptId 20020129 0 (added) 0 (current)

Clinical Terms Version 3-sourced Concepts that were current in CTV3 prior to January 2002 but were non-current in SNOMED CT First Release. The date 31 January 2002 indicates retirement occurred in first release.

ComponentId ReleaseVersion ChangeType Status ConceptId 20020129 0 (added) 0 (current) ConceptId 20020131 1 (status change) ConceptStatus

Clinical Terms Version 3-sourced Concepts that were not current in CTV3 prior to January 2002 and were non-current in SNOMED CT First Release. The date 30 January 2002 indicates retirement prior to first release.

ComponentId ReleaseVersion ChangeType Status ConceptId 20020129 0 (added) 0 (current) ConceptId 20020130 1 (status change) ConceptStatus

Descriptions, Relationships, Cross Maps and Subsets in the First Release are treated as having been added as at 20020131 (31 January 2002). No history information is provided for these Components prior to the First Release. Note: The use of the dates 29, 30 and 31 of January 2002 is somewhat arbitrary. However, the chronological order of these dates is significant as it ensures that if Component History Table rows are applied in ReleaseVersion (i.e. date) order, the most recent change will be applied last. It also allows a distinction between items rendered inactive by the process of developing the SNOMED CT First Release and those that were already non-current in the source terminologies.

Chapter 6

The Stated Relationships Table

Topics:

• Overview • Stated Relationships Table Summary

Overview

The Stated Relationships Table contains the stated form of SNOMED CT. The stated form of a Concept is the logic definition that is directly edited by authors or editors. It consists of the stated IS A relationships plus the defining relationships that exist prior to running a classifier on the logic definitions. Therefore, the stated form of a Concept is represented by a collection of relationships: one or more IS A relationships and zero or more defining relationships. The Stated Relationships Table is in the same table format as the Relationships Table. The stated form enables implementers to test a classifier for consistency, by comparing the results of classification with the distributed Relationships Table, which is the inferred form.

Stated Relationships Table Summary

Each row in the Stated Relationships Table represents a Relationship between two Concepts. The Stated Relationships Table differs from the Relationships Table in that it only contains those Relationships that are directly asserted by authors or editors. The Stated Relationships Table structure differs from that of the Relationships Table in the following ways: • The RelationshipId field is empty. • Future versions of the Stated Relationships Table may include a valid value for each relationship, but the initial release(s) of this table have a blank RelationshipId

• ConceptId1, RelationshipType, ConceptId2 form the key for this table • A unique RelationshipId is not assigned

• There are no CharacteristicType or Refinability fields • Not relevant since all Relationships in this table are Defining characteristics

Key Fields RelationshipId Currently empty for the Stated Relationships Table

Data Fields ConceptId1 The unique SNOMED Clinical Terms identifier of the Concept which is the source of this Relationship. RelationshipType The unique SNOMED Clinical Terms identifier of the Concept which represents the type of relationship between the related Concepts. ConceptId2 The unique SNOMED Clinical Terms identifier of the Concept which is the target of this Relationship. CharacteristicType Always indicates that the Relationship specifies a defining characteristic of the source Concept. No non-defining relationships are allowed in the Stated Relationships Table. Refinability An indication of whether it is possible to refine the target Concept when this relationship is used as a template for clinical data entry.

Data Fields RelationshipGroup An integer value that links together Relationships which are part of a logically associated Relationship group.

Transforming into OWL or KRSS Stated relationships can be transformed into a Description Logic form that utilizes standard syntaxes such as OWL or KRSS. A Perl script to perform the transformation from the Stated Relationships Table into KRSS and OWL formats is provided as a separate file in the distribution.

Chapter 7

Index and Search Support Tables

Topics:

• Overview • Word Search Tables – Summary • Word Equivalents

Overview

Effective implementation of SNOMED CT depends on the ease and speed with which users can locate the terms and Concepts that they wish to use. An essential contribution to meeting this requirement is the ability to perform rapid and flexible text searches. A set of word search tables (indexes) are included in the Developer Toolkit. These tables are designed to facilitate development of effective search facilities while reducing duplication of effort. However, neither these tables, nor indices derived from them, are sufficient to meet the full range of search requirements. Meeting the needs of different users for appropriate methods for locating particular Concepts is an area in which competitive development is expected and welcomed. Developers may choose to use some or all of the word search tables distributed with SNOMED CT or may develop their own solutions independent of these tables. The intention of the word search tables is to identify candidate matches among the Descriptions (or Concepts) of SNOMED CT. An application or coding engine will apply further filtering to these candidate matches to identify the matches to be selected or displayed. A balance must be made between specificity and completeness of a search. The keyword algorithm is intended to maximize the likelihood that the required Concept will be included in the candidate matches rather than to achieve precision. Applications may filter candidate matches using techniques that are many and varied. Some may take account of non-textual characteristics (e.g. Subsets, subtype Relationships or Relationships) while others use more complex textual techniques (e.g. word order dependence, case dependence, complete phrase matching, regular pattern recognition, Soundex). These extended text search techniques are beyond the scope of the keyword generation algorithm. The algorithm for keyword generation is only applicable for English and other western European languages. It is not intended to apply to Russian, Greek, Slavic or to any non-European languages. Please refer to the Technical Implementation Guide for additional search implementation guidance.

Search Requirements Development of user-interfaces that facilitate rapid and appropriate access to SNOMED CT is a legitimate area for competition between application suppliers. However, user perceptions of the quality, usability and value of a terminology depend in a large measure upon the nature and performance of the user interface. Therefore, the IHTSDO has an interest in guiding and facilitating this development. Rapid and appropriate access to SNOMED CT is not simply a matter of providing indices of the type specified in this document. The following aspects of functionality also need to be addressed in ways that are appropriate to the anticipated users of a SNOMED CT enabled application: • Support for searches by keywords, phrases and patterns including: • Word-form and word-order variants • Abbreviations • Word equivalents • User acronyms for commonly used Terms.

• Integration of word and phrase searches with sub-type and part-of hierarchies: • Hierarchy navigation to narrow or broaden a Concept found by a search • Restricting searches to particular descendants of chosen Concepts • Limiting “double hits” caused by synonyms and multiple siblings with identical word matches

• Integration of word and phrase searches with Defining characteristic and Qualifying characteristics • Generating a post-coordinated SNOMED CT representation from a phrase. • Restricting searches to appropriate qualifiers of a selected Concept.

• Integration of word and phrase searches with Subsets: • Restricting searches to specified Subsets of Descriptions or Concepts used in: • A language or dialect; • A country, organization, specialty or user; • A particular context in a record or protocol.

• Prioritizing matches according to memberships of one or more Subsets.

The Technical Implementation Guide offers detailed advice on searching and related user-interface issues. The Developer Toolkit provides the details of the keyword generation algorithms.

Word Search Tables – Summary

The following five tables are included in the Developer Toolkit of SNOMED CT. These tables are derived from the SNOMED CT Descriptions Table. The LanguageCode of the Descriptions Table is used to choose only descriptions for a language.

Excluded Words Table Each row in this table is a word excluded from the list of possible keywords and dualkeys. Words are excluded if they are frequently used and are so limited in semantic specificity that they impair rather than enhance searches. DescWordKey Table Each row in this table is a word followed by a reference to a Description in which this word appears. ConcWordKey Table Each row in this table is a word followed by a reference to a Concept. A Concept is referenced if the word appears anywhere in the combination of the Fully Specified Name with the current valid Preferred Term and Synonyms. DescDualKey Table Each row in this table is a six-character string representing the first three letters of a pair of words followed by a reference to a Description in which these two words appear. ConcDualKey Table Each row in this table is a six-character string representing the first three letters of a pair of words followed by a reference to a Concept. A Concept is referenced if both words appear anywhere in the combination of the Fully Specified Name with the current valid Preferred Term and Synonyms.

All keywords are regarded as case independent and are presented in the word search tables in upper case. Case dependent searching can be applied by appropriately filtering the candidate matches.

Word Equivalents

The Word Equivalent Table is included in the Developer Toolkit of SNOMED CT. It supports enhanced searches that take into account semantically similar words such as KIDNEY and RENAL. It also provides commonly used abbreviations. This table can be used by implementers to offer additional search capability in applications without greatly increasing the volume of synonyms. It is not intended as a comprehensive dictionary of words. Many searches can be completed without using this table; like the other word search tables, it is completely optional and can be used as an example of a capability that may be customized and extended by SNOMED implementers.

Word Equivalents Tables – Summary

Key Fields WordBlockNumber A 32-bit integer shared by a set of equivalent words or phrases. The WordBlockNumber links together several rows that have an identical or similar meaning. WordText A word, phrase, acronym or abbreviation that is equivalent to the WordText of other rows that share the same WordBlockId.

Data Fields WordType An integer indicating the type of equivalence WordRole An integer indicating the usual role of this word. This should be considered if attempting to find a post-coordinated combination of Concepts that matches a phrase.

Chapter 8

Extensions

Topics: SNOMED CT is a deep and detailed clinical terminology with a broad scope. However, some groups of users will need additional Concepts, • Extension Requirements Descriptions or Subsets to support national, local or organizational needs. • Extension Tables – Structure This section explains the structures that enable IHTSDO Member National • Specification for Namespace Release Centers, and other authorized organizations, to add Concepts, within the SCTID Descriptions, Relationships and Subsets to complement the core content • Component Guidelines of SNOMED CT. • Transfer of Responsibility One possible example of the Extension mechanism is for extensibility of between Organizations SNOMED CT for the specialized terminology needs of an organization. • Released Extensions A goal is to provide a structure where these Extensions maintain unique identification across organizations for data transmission and sharing but share a common structure for ease in application development and so that subsets can be constructed over a combination of core and extension content. Another critical goal is to define a structure so that it is easy to submit, include, use, and migrate terminology developed as part of an extension into the core content. When content overlaps the scope of SNOMED CT, it should be submitted to your National Release Center for consideration, so that other SNOMED CT users can also take advantage of this work. Using the extension structure can also help organizations transfer responsibility for terminology to the IHTSDO or to another organization, subject to the terms of the Affiliate License.

Extension Requirements

An Extension mechanism offers many advantages to developers, vendors, terminologists, national bodies and users. Such a mechanism allows: • Users to access SNOMED CT core content and Extensions through a single user interface. • Developers to implement SNOMED Extensions without developing specialized software. • Vendors to develop and sell products to take advantage of both core content and Extensions. • Organizations to develop and share terminology that meet their business needs, without procuring software. • SNOMED CT Affiliates to develop terminology that can be shared with other organizations and considered for addition to the core content. • SNOMED CT Affiliates to use locally-developed terminology without potential overlap with the work of other organizations. This structure also enables specialized Concepts and Descriptions within an Extension to be related to Concepts and Descriptions distributed as part of SNOMED CT. Components in an Extension will be referred to with the prefix “Extra-”. • An Extra-Concept may be: • A national or organizational definition of a concept, which is more rigorous or specific than that generally applied to the SCT-Concept. • An experimental procedure that is not established sufficiently to merit the inclusion in the main body of SNOMED CT but which may be in a local controlled study.

• Extra-Descriptions may be colloquial synonyms for a SCT-Concept or descriptions for a Extra-Concept. • Extra-Relationships may be required to allow analysis packages or decision-support protocols to access additional information about a SCT-Concept or to describe relationships between Extra-Concepts. • Links between local procedures and relevant administrative actions. • Links between local procedures and SNOMED CT Procedures.

• Extra-Subsets may group SCT-Concepts in ways that are specific to data entry contexts of a particular application or communication specification. The Concepts, Descriptions, Relationship and Subsets that form an Extension must be: • Distinguishable from the main body of SNOMED CT, not only in the thesaurus, but also when stored in a patient record, query or decision support protocol. • Distinguishable from other Extensions, in the same way as they are distinguishable from the main body of SNOMED CT. • Able to be distributed and processed in the same way as equivalent components from the main body of SNOMED CT without requiring specific adaptations of SNOMED-enabled applications. The requirements for Extensions can be summarized as follows: • Support for extra terminology components including Concepts, Descriptions, Relationships and Subsets. • These extra Components should behave as though they were components of SNOMED CT but they should be distinguishable from the core of SNOMED CT.

• Globally unique identification of any terminology component that may be used outside the scope of a limited local environment.

• The mechanism must allow several organizations to issue mutually exclusive identifiers for components of their Extensions. • To avoid the risk of misinterpretation, this mechanism must be effective in various contexts including: • Within the thesaurus • In patient records • In queries, decision-support protocols or knowledge bases.

• Designation in the terminology when Concepts have moved or are moving between an Extension and the core, or from one Extension to another. • A shared understanding of the responsibility of an organization that creates an Extension and provides it for the use of other organizations. These responsibilities include: • Maintenance of the Concept, Descriptions, Relationships, and Subsets. • Inactivation of these Components as appropriate (duplication, ambiguous, outdated, etc.) • Submission to an IHTSDO Member’s National Release Center for consideration as an addition to core content.

Extension Tables – Structure

Extensions use the same table structure as the Concepts, Descriptions, Relationships, and Subsets Tables defined in those respective sections of this manual. These tables have the same structure or schema as the core tables but are in separate files.

Figure 4: Extensions Data Structure Summary

When packaged, extension file names should follow the conventions defined by the IHTSDO. For more information, refer to the document SNOMED CT File Naming Convention.

Specification for Namespace within the SCTID

In order for Extension components to be distinguished from the core components and from other Extensions, the SCTID for all rows in the extension tables should be defined using the convention specified for the SCTID which is Appendix A of this guide (SNOMED CT Data Structures on page 66). In summary, the SCTID is defined as follows:

Figure 5: SCTID for components in an Extension

All Extension components (rows) developed by an organization should use the organization's assigned Namespace Identifier. Namespace Identifiers are issued by the IHTSDO so that the Namespaces remain unique between organizations. The Namespaces are entered as Concepts under the “special concepts” hierarchy when they are issued to an organization. Namespaces serve three roles: • Preventing collision or reuse of SNOMED CT identifiers. • Indicating maintenance responsibility – avoiding potential risk of two organizations updating or changing the ConceptStatus of the same Concept. • Indicating the source for information about a concept – relevant for Extension Concepts that are not directly available in a particular system. All Extension components (rows) should use the appropriate partition identifiers for Extensions. This ensures that Components of the SNOMED CT core content can be distinguished from Components that are part of an Extension. Note: All Components from the “core namespace” do not have a namespace field and use the core partition IDs to distinguish these Components from Extension components.

Note: Each organization can assign the “Item Identifier” portion of the SCTID in any way for Extension Namespaces. If there is a need to sub-divide the SCTIDs for sub-organizations, this may be done using the Item Identifier portion of the SCTID.

Component Guidelines

Descriptions that are part of an Extension can refer to either a Concept that is part of that Extension, a Concept that is part of another Extension, or a SNOMED CT core Concept. Relationships that are part of an Extension can relate two Concepts in the Extension or two Concepts in different Extensions. The relationship can also relate the extension Concept to a core Concept -- that is, ConceptID1 is in the extension and ConceptID2 is in the core. If the extension Concept has been moved to the core, then the Moved From relationship will have a Conceptid1 that is in the core and a ConceptID2 that is in the extension. The SNOMED CT core release tables will not contain Descriptions or Relationships for Extension Concepts since all SNOMED licensees may not have access to all Extensions. If a core Component is moved to an Extension, it will use the conventions in the next subsection.

Transfer of Responsibility between Organizations

When the need arises to transfer Components (Concepts, Descriptions, Relationships, Subsets) from the core content to an Extension, from an Extension to the core, or from one Extension to another, conversation and coordination between the sending and receiving organizations is needed. In some cases, entire tables may be transferred – not just individual components. It should be noted that the transfer of Components among Extensions, or between an Extension and the core, is subject to the terms of the IHTSDO Affiliate License and, within an IHTSDO Member country, may also be subject to the terms of that Member’s SNOMED CT national license. Examples of transfers include: • From the SNOMED CT core to an organization responsible for an Extension. • This occurs if a decision is made that some Concepts in the SNOMED CT core are specific to a Realm or domain or interest for which another organization has been allocated responsibility. • For example, this applies to UK specific drugs and UK specific administrative Concepts which are maintained by the UK NHS.

• From an organization responsible for an Extension to the SNOMED CT core. • This occurs if an organization recognizes that some of its Extension content belongs in the SNOMED CT core as it has general applicability. • It also occurs if an organization hands over responsibility for its entire Extension to the IHTSDO.

• From one organization responsible for an Extension to another organization. • This occurs if one organization recognizes that some of its Extension content belongs in a domain managed by another organization. • It also occurs if an organization hands over responsibility for its entire Extension to another organization.

There are two types of transfer of responsibility: • Transfer of an entire Extension (i.e. all Components ever issued with an SCTID in a given Namespace. from one organization to another organization). • This is a straight forward process. All that happens is that another organization assumes responsibility for the original Namespace-identifier. There is no need for detailed tracking of individual Components.

• Transfer of one or more Components: • In this case, the Namespace is not transferred and thus, to fulfill the roles of the Namespace-identifier, the Component must be assigned new SCTIDs in the Namespace of the newly responsible organization. • The previous instances of these Components are withdrawn from current use with the Status value Moved Elsewhere. • Appropriate Relationships point to replacement Components in the new Namespace.

The transfer of responsibility depends on the release schedules of the organizations involved. Often the original source organization will be aware of an intended move before the target organization has accepted responsibility and released the Component. To facilitate this, an interim Status value Pending Move is applied to Components that are being moved to another Namespace but are intended for active use until their replacements are found in the target Namespace. To provide continuity for a Concept if responsibility is transferred, the Concept Status and history are coordinated as follows:

Sending Organization Receiving Organization3 Start State Concept A Concept Status = Current

Agreement to transfer responsibility Concept A Concept Status = Move Pending

Responsibility Transferred Concept A Concept B (Concept B is a new ConceptID using namespace = Concept Status = Moved Elsewhere 999) History Files = Concept A “Status Concept Status = Current Change” to “Moved Elsewhere” History Files = Concept B “Added” History Files = Concept A “Moved to” Namespace 999 in this release History Files = Concept B “Moved from” Concept A Note: Namespace 999 is recorded as a “Special Concept” in the Note: The Receiving Organization SNOMED CT Concepts File. can record the ConceptID Therefore, the Sending previously used for the concept. Organization can track the Note: If the Receiving Organization organization to which the concept is the IHTSDO, the namespace has moved, even if the new would be the core namespace ConceptID is not yet assigned. rather than the example used of namespace = 999

End State Concept A is Inactive Concept B is Active Concept Status = Moved Elsewhere Concept Status = Current History relates Concept A to the History relates Concept B back to Receiving Organization by use of Concept A the Namespace Identifier

3 Assume assigned namespace = 999

Released Extensions

The following extensions are included in the International Release of SNOMED CT from the IHTSDO. As with any extension, their content may not be suitable for use everywhere, and users should consult with their National Release Center for information regarding the use of extension content within an IHTSDO Member country.

Extension Distribution Extension Contents U.S. Drug Extension International Release Actual manufactured drugs approved for distribution in the United States at the “actual medicinal product” (AMP) level. The AMP is a syntactic normal form consisting of: • Name (Proprietary) • Strength • Dosage Form All AMPs relate to “virtual medicinal product” (VMP) concepts in the SNOMED CT Core. All AMPs include the “has active ingredient” relationship where the active ingredient is a substance in the SNOMED CT Core.

Appendix A

SNOMED CT Data Structures

Topics:

• SNOMED CT Data Structure Detail • Core Tables Data Structure Detail • Subset Mechanism Data Structure Detail • Cross Mapping Mechanism Data Structure Detail • History Mechanism Data Structure Detail • Developer Toolkit Structure Overview

SNOMED CT Data Structure Detail

Refer to the Technical Implementation Guide for data diagrams with UML notation.

Core Tables Data Structure Detail

• A Concept is described by the Term of 2-n Descriptions. • A Relationship refers to 3 Concepts: a source, target, and relationship type. • Each Description refers to 1 Concept. • A Concept is the source of 1-n Relationships (except the root Concept). • A Concept is the target of 0-n Relationships. • A Concept represents the type of Relationship.

Subset Mechanism Data Structure Detail

A Concept may be a member of 0-n Subsets. A Description may be a member of 0-n Subsets. A Relationship may be a member of 0-n Subsets. A Subset Member may refer to 1 Concept, 1 Relationship, 1 Description, or 1 Relationship. MemberID may be a ConceptID, DescriptionID, or RelationshipID, depending on the SubsetType.

A Subset Definition may specify the membership of a Subset.

Cross Mapping Mechanism Data Structure Detail

• A Cross Map Set (target scheme) refers to 1-n Cross Maps. • A Concept may be in 0-n Cross Maps. • A Cross Map refers to 1 Concept. • A Target can be used in 1-n Cross Maps. • Each Target contains 1-n target codes (except for unmappable Concepts).

History Mechanism Data Structure Detail

A Concept or Description may be referenced in 0-1 Component History Rows per release. A Description may be the ComponentID in 0-1 rowsof the References Table. A Concept or Description may be the ReferencedID in 0-n rows in the References Table.

Developer Toolkit Structure Overview

Appendix B

Table Structure Details

Topics:

• Concepts Table • Descriptions Table • Relationships Table • Subset Mechanism • Cross Maps • History

Concepts Table

Each row in the Concepts Table represents a clinical concept. Each Concept has a unique identifier of the concept and a Fully Specified Name specifying the nature of the concept.

Key Fields

Concepts Table Key Fields Field Type Permitted characters Length ConceptId SCTID Digits 0 to 9 only 6 to 18

The unique SNOMED CT Identifier for this clinical concept. See The SNOMED Clinical Terms Identifier (SCTID) on page 120 for an explanation of the SCTID data type format.

Data Fields

The Concepts table contains the following data fields: • ConceptStatus • FullySpecifiedName • CTV3ID • SNOMEDID • IsPrimitive

ConceptStatus

Concepts Table Data Field Field Type Permitted characters Length ConceptStatus Enumerated See listed values 1 or 2

The status of a Concept indicates whether it is in active use and, if not, indicates the reason for withdrawal from current use.

Table 6: ConceptStatus Values

Value Meaning 0 Current The Concept is in current use and is considered active. 1 Retired The Concept has been withdrawn without a specified reason. These concepts are considered inactive. 2 Duplicate The Concept has been withdrawn from current use because it duplicates another Concept. These concepts are considered inactive. 3 Outdated The Concept has been withdrawn from current use because it is no longer recognized as a valid clinical concept. These concepts are considered inactive. 4 Ambiguous The Concept has been withdrawn from current use because it is inherently ambiguous. These concepts are considered inactive.

Value Meaning 5 Erroneous The Concept has been withdrawn from current use as it contains an error. A corrected but otherwise similar Concept may have been added to replace it. These concepts are considered inactive. 6 Limited The Concept is of limited clinical value as it is based on a classification concept or an administrative definition. Concepts with this status are not valid for current use and are considered inactive. 10 Moved elsewhere The Concept has been moved to an extension, to a different extension, or to the core. Use the “Moved To” Relationship to locate the namespace to which the concept has been moved. These concepts are considered inactive. 11 Pending move The Concept will be moved to an extension, to a different extension, or to the core. Use the “Moved To” Relationship to locate the namespace to which the concept will be moved when the recipient organization confirms the move. These concepts are considered active.

FullySpecifiedName

Concepts Table Data Field Field Type Permitted characters Length FullySpecifiedName String Any (except LF, CR and 1 to 255 TAB)

A phrase that describes a Concept in a way that is intended to be unambiguous. Each Fully Specified Name contains a suffix that indicates where it is integrated into the primary hierarchy. This can help distinguish, at a glance, for example, a finding from a disorder. The suffixes are:

• administrative concept • assessment scale • attribute • body structure • cell • cell structure • disorder • environment / location • environment • ethnic group • event • finding • geographic location • inactive concept • life style • link assertion • linkage concept • morphologic abnormality • namespace concept • navigational concept • observable entity • occupation • organism • person • physical force • physical object • procedure • product • qualifier value • racial group • record artifact • regime/therapy • religion/philosophy • situation • social concept • special concept • specimen • staging scale • substance • tumor staging

Note: The Fully Specified Name is not the same as the Preferred Term in the Descriptions Table. The Fully Specified Name explains the meaning of the concept more fully than the Preferred Term to remove or reduce ambiguity.

The limitation in the length of this field is 255 bytes. All ASCII characters in the range 32 to 127 can be encoded in a single byte using in UTF-8. However, accented and special characters require two or three byte encoding. The maximum length of a Term that contains these characters is less than 255 characters. The Fully Specified Name is also represented as a row in the Descriptions Table. This allows translated versions of the Fully Specified Name to co-exist and to be referenced by appropriate Language Subsets. The Fully Specified Name in the Concepts Table is the American English Fully Specified Name. Typically the Fully Specified Name will not be a Term that would be used in a clinical record. Instead, it may be stylized to ensure that it has a single unambiguous meaning. Example: The Preferred Term of a concept could be ‘Aspiration of stomach contents’, however, the Fully Specified Name might be ‘Aspiration of stomach contents (procedure)’ to distinguish it from a post-operative complication.

CTV3ID

Concepts Table Data Field Field Type Permitted characters Length CTV3ID String 0 to 9, A to Z, a to z or . 5 (stop)

The Read Code for the concept taken from the United Kingdom’s Clinical Terms Version 3 terminology. As CTV3 is a superset of FourByte and Version 2 Read codes, all the codes from those versions are present in CTV3 and SNOMED CT. The identifiers can be picked out easily as all FourByte codes have a leading ‘.’ and Version 2 codes have a trailing ‘.’. As new concepts are added to SNOMED Clinical Terms, new codes are used to populate this field. This will allow records to be maintained or searched using the existing codes and identifiers during an extended migration period. The IHTSDO will review this commitment from time to time and it may be discontinued at some point in the future. In Extensions, these additional identifier fields may not be populated.

SNOMEDID

Concepts Table Data Field Field Type Permitted characters Length SNOMEDID String 0 to 9, A to Z or -(dash) 6 to 8

The SNOMED RT identifier for this concept. As new concepts are added to SNOMED Clinical Terms, new SNOMED identifiers are generated to populate this field. This will allow records to be maintained or searched using the existing codes and identifiers during an extended migration period. The IHTSDO will review this commitment from time to time and it may be discontinued at some point in the future. In Extensions, these additional identifier fields may not be populated.

IsPrimitive

Concepts Table Data Field Field Type Permitted characters Length IsPrimitive Boolean 0 or 1 1

Indicates if a Concept is Primitive or Fully defined by its defining characteristics. A Concept may be Primitive because: • Its only stated Defining characteristics are “IS A” subtype Relationships • An aspect of its meaning is not fully expressed by existing Relationships. If a Concept is Primitive its place in the subtype hierarchy may be known but it cannot be checked for equivalence with another Concept expression or Post-coordinated expression.

Table 7: IsPrimitive Values

Values 0 Fully defined 1 Primitive

Descriptions Table

Each row in the Descriptions Table associates a term with a clinical concept, which it can be used to represent. Each Description has its own unique identifier and also contains the text of a Term and the identifier of the Concept that it represents. Note: Some terms may be applied to more than one concept. In this case each is represented by a separate row in the Descriptions Table with the same term text but with different identifiers.

Each Description contains a single term, which is valid in one or more languages or dialects. To identify the descriptions for any language edition, the appropriate Language Subset must be used. Do no use the Descriptions Table alone. The descriptions for each language edition (including English) are designated in the Subset.

Key Fields

Descriptions Table Key Fields Field Type Permitted characters Length DescriptionId SCTID Digits 0 to 9 only 6 to 18

The unique SNOMED CT Identifier for this description. See The SNOMED Clinical Terms Identifier (SCTID) on page 120 for an explanation of the SCTID data type format.

Data Fields

The Descriptions Table contains the following data fields: • DescriptionStatus • ConceptId • Term • InitialCapitalStatus • DescriptionType • LanguageCode

DescriptionStatus

Descriptions Table Data Field Field Type Permitted characters Length DescriptionStatus Enumerated See listed values 1 to 2

The status of a Description indicates whether it is in current use and, if not, indicates the reason for withdrawal from current use.

Table 8: DescriptionStatus Values

Value Meaning 0 Current The Description and its associated Concept are in current use. 1 Non-Current The Description has been withdrawn without a specified reason. 2 Duplicate The Description has been withdrawn from current use because it duplicates another description containing the same term (or a very similar term) associated with the same Concept. 3 Outdated The Description has been withdrawn from current use because this Term is no longer in general clinical use as a label for the associated Concept. 5 Erroneous The Description has been withdrawn as the Term contains errors. 6 Limited The Description is a valid Description of a Concept which has “limited” status (i.e. the Concept has ConceptStatus = 6). 7 Inappropriate The Description has been withdrawn as the Term should not refer to this concept. 8 Concept non-current The Description is a valid Description of a Concept which has been made non-current (i.e. the Concept has ConceptStatus 1, 2, 3, 4, 5, or 10). 10 Moved elsewhere The Description has been moved to an extension, to a different extension, or to the core. A reference will indicate the namespace to which the description has been moved.

Value Meaning 11 Pending move The Description will be moved to an extension, to a different extension, or to the core. A reference will indicate the namespace to which the description has been moved when the recipient organization confirms the move (Future Use).

Note: Status value 4 is only applicable to ConceptStatus.

A Description is only marked as current (DescriptionStatus = 0) if the associated Concept is also current (ConceptStatus = 0). • A Concept made inactive (with ConceptStatus = 1, 2, 3, 4, 5 or 10) retains its previous current Descriptions but these are marked “Concept non-current” (DescriptionStatus = 8). • An inactive “limited” Concept (ConceptStatus = 6) has valid usable Descriptions but these are also marked “limited” (DescriptionStatus = 6).

ConceptId

Descriptions Table Data Field Field Type Permitted characters Length ConceptId SCTID Digits 0 to 9 only 6 to 18

The unique SNOMED CT Identifier of the clinical concept to which this Description applies. Note: This field provides the association between the Descriptions and Concepts tables.

Term

Descriptions Table Data Field Field Type Permitted characters Length Term String Any (except LF, CR and 1 to 255 TAB)

The text of a Term used to describe the associated Concept. Note: The term may be the FullySpecifiedName, the Preferred Term or a synonymous term for the associated concept. The DescriptionType field indicates the type of term. The Preferred Term is not the same as the Fully Specified Name. The Preferred Term expresses the concept accurately using language that a clinician would expect to find in a clinical record. In order to remove or reduce any possible ambiguity the Fully Specified Name may use phraseology that is stylized and unfamiliar.

The Term may be one or more languages or dialects. The Descriptions applicable to each language and/or dialect are indicated by inclusion in Language Subsets distributed with the core tables. The limitation in the length of this field is 255 bytes. All ASCII characters in the range 32 to 127 can be encoded in a single byte using UTF-8. However, accented and special characters require two or three byte encoding. Therefore, the maximum length for a Term that contains these characters is less than 255 characters. The FullySpecifiedName is also present in the Concepts Table. It is included in the Descriptions Table to allow language and dialect variations to be represented.

InitialCapitalStatus

Descriptions Table Data Field Field Type Permitted characters Length InitialCapitalStatus Boolean 0 or 1 1

Indicates whether the capitalization status of the first character of the Term is significant.

Table 9: InitialCapitalStatus Values

Value Meaning 0 False The first character of the Term may be capitalized or uncapitalized according to its position in a sentence without changing its meaning. This is true for most Terms. 1 True The capitalization of the first character of the Term must not be changed. This setting is used to indicate that the Term must retain an initial capital (e.g. "Down syndrome") or must not have its initial letter capitalized (e.g. "ml").

Note: Capitalization of characters other than the first character in the Term is always regarded as significant.

DescriptionType

Descriptions Table Data Field Field Type Permitted characters Length DescriptionType Enumerated See listed values 1

Indicates whether the Term is the Preferred Term or Synonym for the associated Concept.

Table 10: DescriptionType Values

Value Meaning 0 Unspecified This may be assigned as either a Preferred Term or Synonym by a Description Subset for a language, dialect or realm. 1 Preferred This is the Preferred Term for the associated Concept. 2 Synonym This is a Synonym for the associated Concept. 3 FullySpecifiedName This is the FullySpecifiedName for the associated Concept.

Note: The Preferred Term and Synonyms may vary according to language and dialect. These variations are specified using Subsets. In any one language or dialect there is one and only one Preferred Term for each Concept. The Preferred Term in one language or dialect may be a Synonym in other languages or dialects. Any Description with a DescriptionType “Unspecified”, “Preferred” or “Synonym” in the distributed table may be assigned as a Preferred Term or Synonym in any language or dialect.

The FullySpecifiedName will vary according to language and dialect. These variations are specified using Subsets. In any language or dialect there is one FullySpecifiedName for each Concept. Only Descriptions that have the DescriptionType “FullySpecifiedName” may be assigned as the FullySpecifiedName in any language or dialect.

LanguageCode

Descriptions Table Data Field Field Type Permitted characters Length LanguageCode String 0 to 9, a to z, A to Z and 1 to 8 dash "-"

This field specifies the language/dialect of the term. A string identifying a language and, if appropriate, a dialect in which this Description is valid. Consists of a code and optionally a sub-code. If a sub-code is present it is separated from the code by a dash ("-"). • The code is the two-character ISO639-1 language code. ISO639 is the International Standard for "Codes for the representation of names of languages". • The sub code is a string of upper-case letters that represent the dialect. This deliberately mirrors the W3C approach and will either be: • If the dialect is general to an entire country, the two-letter ISO 3166 country code is used. ISO3166 is the International Standard for "Codes for the representation of names of countries". • If dialects are used that are less common or not country or language linked, the IANA approach is used. This code consists of a string of more than two letters. IANA is the Internet Assigned Numbers Authority.

This structure follows Internet conventions. Examples: "en" for "English", "es" for Spanish, "en-US" for United States English, "en-GB" for British English. To identify the members of an edition of SNOMED CT, use the Language subset for that edition. Do not simply search for all entries in the Descriptions Table using the Language Code field. Each edition includes the appropriate Language Subset, which designates the descriptions that are intended for that edition.

Relationships Table

Each row in the Relationships Table represents a Relationship between two Concepts. Notes: Most Relationship Types are directional and are therefore regarded as having source concept and a target concept. Reciprocal relationships are not explicitly represented by rows in the Relationships Table.

For example, if B is a subtype of A, it follows that A is a supertype of B. The first of these relationships is represented by a row in the Relationships Table. The reciprocal relationship is implied and is not restated by another row in the table.

The Relationship Types supported include the "ISA" (subtype) relationship. In the case of hierarchical relationships (e.g. "ISA" relationships) only the closest relationships are represented explicitly. Other relationships are subsumed and are not represented by rows in the Relationships Table.

For example, if C is a subtype of B and B is a subtype of A, it follows that C is a subtype of A. The relationship between C and A is not represented by a row in the Relationships Table but is subsumed by the chain of relationships between C and B and B and A.

Relationships other than “ISA” (subtype) relationship are called attribute relationships. These relationships include the concept (object), relationship type (attribute), and attribute value (another concept). This is sometimes called the OAV triplet, which stands for Object-Attribute-Value. Some sets of relationships may have an expected or logical display order (e.g. cranial nerves or cervical vertebrae). The order is described using the subset mechanism and is not part of the Relationships Table. In 2003-2004, some relationships were packaged into a separate file called the Historical Relationships Table. These relationships were merged into the Relationships Table starting with the January 2005 release. To recreate these two tables, use these SQL commands:

Create table historical_relationships as Select * from relationships Where characteristictype = ‘2’; Delete from relationships Where characteristictype = ‘2’;

Note: The type of relationship is itself described using a concept.

Key Fields

Relationships Table Key Fields Field Type Permitted characters Length RelationshipId SCTID Digits 0 to 9 only 6 to 18

The unique SNOMED CT Identifier for this relationship. See The SNOMED Clinical Terms Identifier (SCTID) on page 120 for an explanation of the SCTID data type format. Note: This field allows a Relationship to be referenced by a Subset or Extension.

Data Fields

The Relationships Table contains the following data fields: • ConceptId1 • RelationshipType • ConceptId2 • CharacteristicType • Refinability • RelationshipGroup

ConceptId1

Relationships Table Data Field Field Type Permitted characters Length ConceptId1 SCTID Digits 0 to 9 only 6 to 18

The unique SNOMED CT Identifier of the Concept which is the source of this Relationship. Note: This field provides the first association between the Relationships and Concepts tables and is sometimes referred to as the “object.”

RelationshipType

Relationships Table Data Field Field Type Permitted characters Length RelationshipType SCTID Digits 0 to 9 only 6 to 18

The unique SNOMED CT Identifier of the Concept which represents the type of relationship between the related Concepts. Note: A special category of Concepts is used to represent RelationshipTypes.

This field provides the second association between the Relationships and Concepts tables and is sometimes called the “attribute” or “role.”

ConceptId2

Relationships Table Data Field Field Type Permitted characters Length ConceptId2 SCTID Digits 0 to 9 only 6 to 18

The unique SNOMED CT Identifier of the Concept which is the target of this Relationship. Note: This field provides the third association between the Relationships and Concepts tables and is sometimes called the “value.”

CharacteristicType

Relationships Table Data Field Field Type Permitted characters Length CharacteristicType Enumerated See listed values 1

An indication of whether a Relationship specifies a defining characteristic of the source Concept or a possible qualification of that Concept. Note: The Relationships Table is concerned with definitions, qualifiers and additional facts about a Concept. Although it can also be used to display a hierarchy of subtypes it does not have a specified or natural display order. More effective browser Navigation is supported by use of a Navigation Subset.

Table 11: CharacteristicType Values

Value Meaning 0 Defining This relationship represents a defining characteristic of the source concept. Hierarchical relationships (e.g. “IS A”) are also regarded as defining relationships. Example: “‘PROCEDURE SITE’ = ‘Liver’” is a defining characteristic of ‘Liver biopsy’.

1 Qualifier This relationship represents an optional qualifying characteristic. Example: “‘REVISION STATUS’ = ‘First revision’” is a possible qualification of ‘Hip replacement’.

2 Historical This is used to relate an inactive concept to another concept. Example: The “SAME AS” relationship connects an inactive concept with the concept it duplicates.

3 Additional This relationship represents a context specific characteristic. This is used to convey characteristics of a concept that apply at a particular time within a particular organization but which are not intrinsic to the concept. Example: ‘Prescription Only Medicine’ is a context specific characteristic of the Concept ‘Amoxycillin 250mg capsule’. It is true currently in the UK but is not true in some other countries.

Refinability

Relationships Table Data Field Field Type Permitted characters Length Refinability Enumerated See listed values 1

An indication of whether it is possible to refine the target concept when this Relationship is used as a template for clinical data entry.

Table 12: Refinability Values

Value Meaning 0 Not refinable Not refinable. 1 Optional May be refined by selecting subtypes. 2 Mandatory Must be refined by selecting a subtype.

RelationshipGroup

Relationships Table Data Field Field Type Permitted characters Length RelationshipGroup Integer 0 to 9 1 to 2

An integer value that expresses an association between two or more Relationships. The default Relationship group value is zero and this applies to all Relationships that have not been stated to be associated with any other Relationships. All Relationships that share the same ConceptId1 and the same non-zero Relationship group value are associated with one another. Any Relationships that share the same ConceptId1 but have different Relationship group values are not associated with one another. See example below.

ConceptId1 RelationshipType ConceptId2 RoleGroup Ureteroscopic removal of ureteric calculus Direct morphology Calculus 1 Ureteroscopic removal of ureteric calculus Method Removal 1 Ureteroscopic removal of ureteric calculus Procedure site - Ureteric structure 1 Indirect Ureteroscopic removal of ureteric calculus Method Surgical action 2

Subset Mechanism

Subset Table

Each row in the Subsets Table represents a Subset. Each Subset has a unique identifier, a SubsetName, a SubsetType and a collection of additional characteristics.

Key Fields

Subsets Table Key Fields Field Type Permitted characters Length SubsetId SCTID Digits 0 to 9 only 6 to 18

The unique SNOMED CT Identifier for this subset. See The SNOMED Clinical Terms Identifier (SCTID) on page 120.

Data Fields The Subsets table contains the following data fields: • SubsetOriginalId • SubsetVersion • SubsetName • SubsetType • LanguageCode • RealmId • ContextId

SubsetOriginalId

Subsets Table Data Field Field Type Permitted characters Length SubsetOriginalId SCTID 0 to 9 6 to 18

The unique SNOMED CT Identifier for the first version of the Subset on which this Subset is based. Note: For the first version of a Subset the SubsetOriginalId and SubsetId fields contain the same value. For each subsequent version the SubsetVersion is incremented and a new SubsetId is allocated but the SubsetOriginalId field retains the same value in all versions.

SubsetVersion

Subsets Table Data Field Field Type Permitted characters Length SubsetVersion Integer 0 to 9 1 to 5

An integer increased for each revised release of this Subset. Note: A single distribution table will only contain one version of a Subset. However, legacy versions of a Subset may need to be retained to support other Subset Definitions or continued use of a protocol which has not been validated for use with the revised Subset.

SubsetName

Subsets Table Data Field Field Type Permitted characters Length SubsetName String Any (except LF, CR and 1 to 255 TAB)

A descriptive name given to the Subset by its originator.

SubsetType

Subsets Table Data Field Field Type Permitted characters Length SubsetType Integer 0 to 9 1 to 2

Indicates the nature of the Subset and the type of SNOMED CT Component that may be a member of the Subset.

Table 13: SubsetType Values

Value Meaning 1 Language Descriptions appropriate to a specified Language or Dialect. 2 Realm Concept Concepts appropriate to a specified Realm. 3 Realm Description Descriptions appropriate to a specified Realm. 4 Realm Relationship Relationships appropriate to a specified Realm (for future use). 5 Context Concept Concepts appropriate to a specified Context Domain. 6 Context Description Descriptions appropriate to a specified Context Domain.

Value Meaning 7 Navigation Navigation Links that represent an ordered Navigation hierarchy. 8 Duplicate Terms Descriptions that contain identical Terms. Other values are reserved for future use.

LanguageCode

Subsets Table Data Field Field Type Permitted characters Length LanguageCode String 0 to 9, a to z, A to Z and 1 to 8 dash "-"

This field specifies the language/dialect of the descriptions in a subset. A string identifying a Language and, if appropriate, a dialect to which the Descriptions in this subset are valid. Consists of a code and optionally a sub-code. If a sub-code is present it is separated from the code by a dash ("-"). • The code is the two-character ISO639-1 language code. ISO639 is the International Standard for "Codes for the representation of names of languages". • The sub code is a string of upper-case letters that represent the dialect. This deliberately mirrors the W3C approach and will either be: • If the dialect is general to an entire country, the two-letter ISO 3166 country code is used. ISO3166 is the International Standard for "Codes for the representation of names of countries". • If dialects are used that are less common or not country or language linked, the IANA approach is used. This code consists of a string of more than two letters. IANA is the Internet Assigned Numbers Authority.

This structure follows Internet conventions. Examples: "en" for "English", "es" for Spanish, "en-US" for United States English, "en-GB" for British English. Usage: Required for Language Subsets, Realm Description Subsets and Context Description Subsets. In all other SubsetTypes the LanguageCode has the value = “0” (zero) and should be ignored. To identify the members of an edition of SNOMED CT, use the Language subset for that edition. Do not simply search for all entries in the Descriptions Table using the Language Code field. Each edition includes the appropriate Language Subset, which designates the descriptions that are intended for that edition.

RealmId

Subsets Table Data Field Field Type Permitted characters Length RealmId String 0 to 9 and full-stop "." 4 to 24

A string identifying a Realm. For example, UK GP subset (a realm subset for general practice physicians in the United Kingdom). Usage Required for Realm Concept Subsets, Realm Description Subsets, Context Concept Subsets and Context Description Subsets. May also be used in Duplicate Terms Subsets. In all other Subset Types the RealmId has the value "0" (zero) and should be ignored.

ContextId

Subsets Table Data Field Field Type Permitted characters Length ContextId String 0 to, 9 a to z, A to Z, "." 1 to 18 and "-"

A string that identifies a Context Domain within the Realm indicated by the RealmId. Context Domain may be specified for different purposes. These include: • Categories of Concepts with particular roles in the terminology or in a record: • Concepts that have an organizing role in the terminology but which are not appropriate to use in an individual patient record (e.g. the Root Concept, Top-Level Concepts and other Concepts that provide a rational hierarchical structure without the precision appropriate to a patient record. • Concepts are applicable as organizing headers in a record but which are not appropriate for use in making clinical statements.

• Broad contexts for use within parts of a record: • Concepts that are appropriately detailed for use as a discharge diagnosis according to a local convention or agreed protocol.

• Narrow contexts used to constrain data entry or population of a message field: • Concepts or Descriptions to be presented as valid choices for a particular field in a screen or protocol. • Concepts that are applicable to a message field. Examples include: • An HL7 "value domain"; • The NHS Pathology Message bounded code list.

Usage: Required for Context Concept Subsets and Context Description Subsets. May also be used in Duplicate Terms Subsets. In all other Subset Types the ContextId has the value "0" (zero) and should be ignored.

Subset Members Table

Subset Members Table: Common Details Each row in the Subset Members Table represents one member of a Subset. The Subset to which a member belongs is identified by the Subset ID. The member is identified by a MemberId, which refers to a Concept, Description, or Relationship. The MemberStatus and LinkedId fields are interpreted depending on the SubsetType. Each type of subset is described separately. The types of subsets are: • Language Subset • Realm Concept Subset • Realm Description Subset • Realm Relationship Subset (for future use) • Context Concept Subset • Context Description Subset • Navigation Subset • Duplicate Terms Subset The MemberId may be a ConceptId, DescriptionId, or RelationshipId.

Key Fields The Subset Members Table has the following key fields: • SubsetId • MemberId • MemberStatus

SubsetId

Subsets Members Table Key Fields Field Type Permitted characters Length SubsetId SCTID 0 to 9 6 to 18

The unique SNOMED CT Identifier for the Subset to which this applies.

MemberId

Subsets Members Table Key Fields Field Type Permitted characters Length MemberId SCTID 0 to 9 6 to 18

The SNOMED CT Identifier of a Subset Member. The permitted Subset Members depends on the SubsetType and can be a ConceptId, DescriptionId, or RelationshipId.

MemberStatus

Subsets Members Table Key Fields Field Type Permitted characters Length MemberStatus Integer 0 to 9 1 to 5

The status of the identified member in this Subset. The value of MemberStatus must be greater than zero. The interpretation of MemberStatus values depends on the SubsetType. For most Subsets the combination of Subset ID and MemberId is unique. The exception to this rule is Navigation Subsets and for this reason the MemberStatus is included in the key. Data Fields

Subsets Table Data Field Field Type Permitted characters Length LinkedId SCTID 0 to 9, Null 6 to 18

The Interpretation of LinkedId depends on the SubsetType and may be null in some cases.

Language Subset Members Tables Key Fields The Language Subset Members Table has the following key fields: • SubsetId • MemberId • MemberStatus

SubsetId

Language Subset Members Table Key Fields Field Type Permitted characters Length SubsetId SCTID 0 to 9 6 to 18

The unique SNOMED CT Identifier for the Subset to which this applies.

MemberId

Language Subset Members Table Key Fields Field Type Permitted characters Length MemberId SCTID 0 to 9 6 to 18

The Identifier of a SNOMED CT Description.

MemberStatus

Language Subset Members Table Key Fields Field Type Permitted characters Length MemberStatus Integer 0 to 9 1 to 5

The status of the identified member in this Subset. The value of MemberStatus must be greater than zero. Language Subset The MemberStatus specifies the role of the referenced Description in this Language. There are three roles.

1 = Preferred Term 2 = Synonym 3 = Fully Specified Name

Notes: The following rules must apply to each Subset: 1. A Description cannot be assigned the role Fully Specified Name unless its DescriptionType is also "Fully Specified Name". 2. Only one Description of each Concept may be assigned as the Fully Specified Name. 3. If no Description of a Concept is assigned the role Fully Specified Name, the Fully Specified Name in the Concepts Table assumes this role. 4. A Description cannot be assigned the role Preferred Term or Synonym if its DescriptionType is "Fully Specified Name". 5. One and only one Description of each Concept must be assigned the role "Preferred Term". 6. Any number of Descriptions of a Concept may be assigned the role "Synonym".

Data Fields

Language Subset Members Table Data Field Field Type Permitted characters Length LinkedId SCTID Null 0

This field is not used and may be treated as null.

Realm Concept Subset Members Table Key Fields The Realm Concept Subset Members Table has the following key fields: • SubsetId • MemberId • MemberStatus

SubsetId

Realm Concept Subset Members Table Key Fields Field Type Permitted characters Length SubsetId SCTID 0 to 9 6 to 18

The unique SNOMED CT Identifier for the Subset to which this applies.

MemberId

Realm Concept Subset Members Table Key Fields Field Type Permitted characters Length MemberId SCTID 0 to 9 6 to 18

The identifier of a SNOMED CT Concept.

MemberStatus

Realm Concept Subset Members Table Key Fields Field Type Permitted characters Length MemberStatus Integer 0 to 9 1 to 5

The status of the identified member in this Subset. The value of MemberStatus must be greater than zero. The priority assigned to this Concept. Note: The lower the value, the greater the priority. Thus the highest priority is assigned to Concepts with the MemberStatus value "1" (first).

The priority should be used by applications to determine the items to be displayed first or selected most readily.

Data Fields

Realm Concept Subset Members Table Data Fields Field Type Permitted characters Length LinkedId SCTID Null 0

This field is not used and may be treated as null.

Realm Description Subset Members Table Key Fields The Realm Description Subset Members Table has the following key fields: • SubsetId • MemberId • MemberStatus

SubsetId

Realm Description Subset Members Table Key Fields Field Type Permitted characters Length SubsetId SCTID 0 to 9 6 to 18

The unique SNOMED CT Identifier for the Subset to which this applies.

MemberId

Realm Description Subset Members Table Key Fields Field Type Permitted characters Length MemberId SCTID 0 to 9 6 to 18

The Identifier of a SNOMED CT Description.

MemberStatus

Realm Description Subset Members Table Key Fields Field Type Permitted characters Length MemberStatus Integer 0 to 9 1 to 5

The status of the identified member in this Subset. The value of MemberStatus must be greater than zero. Realm Subset The MemberStatus specifies the role of the referenced Description in this Realm. There are three roles.

1 = Preferred Term 2 = Synonym 3 = Fully Specified Name

Realm Description Subset Members Table Data Fields Field Type Permitted characters Length LinkedId SCTID Null 0

This field is not used and may be treated as null.

Realm Relationship Subset Members Table Key Fields The Realm Relationship Subset Members Table has the following key fields: • SubsetId • MemberId • MemberStatus

SubsetId

Realm Relationship Subset Members Table Key Fields Field Type Permitted characters Length SubsetId SCTID 0 to 9 6 to 18

The unique SNOMED CT Identifier for the Subset to which this applies.

MemberId

Realm Relationship Subset Members Table Key Fields Field Type Permitted characters Length MemberId SCTID 0 to 9 6 to 18

The identifier of a SNOMED CT Relationship.

MemberStatus

Realm Relationship Subset Members Table Key Fields Field Type Permitted characters Length MemberStatus Integer 0 to 9 1 to 5

The status of the identified member in this Subset.

The value of MemberStatus must be greater than zero. Realm Relationship Subset The only permitted value of MemberStatus is:

1 = Include

All members of these Subsets are treated as equal. Data Fields

Realm Relationship Subset Members Table Data Fields Field Type Permitted characters Length LinkedId SCTID Null 0

This field is not used and may be treated as null (for future use).

Context Concept Subset Members Table Key Fields The Context Concept Subset Members Table has the following key fields: • SubsetId • MemberId • MemberStatus

SubsetId

Context Concept Subset Members Table Key Fields Field Type Permitted characters Length SubsetId SCTID 0 to 9 6 to 18

The unique SNOMED CT Identifier for the Subset to which this applies.

MemberId

Context Concept Subset Members Table Key Fields Field Type Permitted characters Length MemberId SCTID 0 to 9 6 to 18

The identifier of a SNOMED CT Concept.

MemberStatus

Context Concept Subset Members Table Key Fields Field Type Permitted characters Length MemberStatus Integer 0 to 9 1 to 5

The status of the identified member in this Subset. The value of MemberStatus must be greater than zero. The priority assigned to this Concept.

Note: The lower the value, the greater the priority. Thus the highest priority is assigned to Concepts with the MemberStatus value "1" (first).

The priority should be used by applications to determine the items to be displayed first or selected most readily. Data Fields

Context Concept Subset Members Table Data Fields Field Type Permitted characters Length LinkedId SCTID Null 0

This field is not used and may be treated as null.

Context Description Subset Members Table Key Fields The Context Description Subset Members Table has the following key fields: • SubsetId • MemberId • MemberStatus

SubsetId

Context Description Subset Members Table Key Fields Field Type Permitted characters Length SubsetId SCTID 0 to 9 6 to 18

The unique SNOMED CT Identifier for the Subset to which this applies.

MemberId

Context Description Subset Members Table Key Fields Field Type Permitted characters Length MemberId SCTID 0 to 9 6 to 18

The identifier of a SNOMED CT Description.

MemberStatus

Context Description Subset Members Table Key Fields Field Type Permitted characters Length MemberStatus Integer 0 to 9 1 to 5

The status of the identified member in this Subset. The value of MemberStatus must be greater than zero.

Context Description Subset The only permitted value of MemberStatus is:

1 = Include

All members of these Subsets are treated as equal. Data Fields

Context Description Subset Members Table Data Fields Field Type Permitted characters Length LinkedId SCTID Null 0

This field is not used and may be treated as null.

Navigation Subset Members Table Key Fields The Navigation Subset Members Table has the following key fields: • SubsetId • MemberId • MemberStatus

SubsetId

Navigation Subset Members Table Key Fields Field Type Permitted characters Length SubsetId SCTID 0 to 9 6 to 18

The unique SNOMED CT Identifier for the Subset to which this applies.

MemberId

Navigation Subset Members Table Key Fields Field Type Permitted characters Length MemberId SCTID 0 to 9 6 to 18

The identifier of a SNOMED CT Concept.

MemberStatus

Navigation Subset Members Table Key Fields Field Type Permitted characters Length MemberStatus Integer 0 to 9 1 to 5

The status of the identified member in this Subset. The value of MemberStatus must be greater than zero. Navigation Subset The MemberStatus specifies the order of the child Concepts within the set of Navigation Links from the same parent Concept. The combination of SubsetId and MemberId and MemberStatus forms the unique key.

Data Fields

Navigation Subset Members Table Data Fields Field Type Permitted characters Length LinkedId SCTID 0 to 9 6 to 18

The ConceptId of a Navigation child of the Concept identified by the MemberId.

Duplicate Terms Subset Members Table Key Fields The Duplicate Terms Subset Members Table has the following key fields: • SubsetId • MemberId • MemberStatus

SubsetId

Duplicate Terms Subset Members Table Key Fields Field Type Permitted characters Length SubsetId SCTID 0 to 9 6 to 18

The unique SNOMED CT Identifier for the Subset to which this applies.

MemberId

Duplicate Terms Subset Members Table Key Fields Field Type Permitted characters Length MemberId SCTID 0 to 9 6 to 18

The Description Identifier for a SNOMED CT Concept that has a duplicate term.

MemberStatus

Duplicate Terms Subset Members Table Key Fields Field Type Permitted characters Length MemberStatus Integer 0 to 9 1 to 5

The status of the identified member in this Subset. The value of MemberStatus must be greater than zero. Duplicate Terms Subset The priority assigned to this Concept. Note: The lower the value, the greater the priority. Thus the highest priority is assigned to Concepts with the MemberStatus value "1" (first).

The priority should be used by applications to determine the items to be displayed first or selected most readily.

Data Fields

Duplicate Terms Subset Members Table Data Fields Field Type Permitted characters Length LinkedId SCTID 0 to 9 6 to 18

The MemberID (and therefore, the DescriptionId) of the Member with the same Term which has the highest priority. A group of duplicate terms can be identified since they will all point to the same LinkedId.

Subset Definition File

Please contact the IHTSDO or your SNOMED CT National Release Center for the current specifications for this file.

Cross Maps

Cross Map Sets Table

Each row in the Cross Map Sets Table identifies a Target Scheme to which SNOMED CT is mapped and specifies characteristics of the associated Cross Maps and Cross Map Targets.

Key Fields

Cross Map Sets Table Key Fields Field Type Permitted characters Length MapSetId SCTID 0 to 9 6 to 18

The unique SNOMED CT Identifier for this Cross Map Set. Note: The format and construction of these identifiers is described in The SNOMED Clinical Terms Identifier (SCTID) on page 120.

Data Fields The Cross Map Sets Table contains the following data fields: • MapSetName • MapSetType • MapSetSchemeId • MapSetSchemeName • MapSetSchemeVersion • MapSetRealmId • MapSetSeparator • MapSetRuleType

MapSetName

Cross Map Sets Table Data Field Field Type Permitted characters Length MapSetName String Any (except LF, CR and 1 to 255 TAB)

A descriptive name given to the Cross Map Set by its originator.

MapSetType

Cross Map Sets Table Data Field Field Type Permitted characters Length MapSetType Enumerated 0 to 9 1 to 2

Indicates the nature of the Cross Maps associated with this scheme. CrossMapType is used to indicate the inclusion of one to one, one to many and choices of maps.

Table 14: MapSetType Values

Value Meaning 0 Unspecified. 1 Single All maps are unique one-to-one maps. • Each Concept has only one associated Cross Map • Each Cross Map Target contains a single Target Code.

2 Multiple Some maps are one-to-many maps but there are no choices. • Each Concept has only one associated Cross Map • Some Cross Map Targets contains a list of more than one Target Code.

3 Choice Some maps include choices of one-to-one maps but there are no one-to-many maps. • Some Concepts have more than one associated Cross Map • Each Cross Map Target contains a single Target Code.

4 Flexible Some maps include choices and there are some one-to-many maps. • Some Concepts have more than one associated Cross Map.

Some Cross Map Targets contain a list of more than one Target Code.

MapSetSchemeId

Cross Map Sets Table Data Field Field Type Permitted characters Length MapSetSchemeId String Any (except LF, CR and 1 to 64 TAB)

A standard identifier for the Target Scheme. This may be an International Coding Scheme Identifier (ISO7826) or an Object Identifier (OID) used as specified by HL7.

MapSetSchemeName

Cross Map Sets Table Data Field Field Type Permitted characters Length MapSetSchemeName String Any (except LF, CR and 1 to 255 TAB)

The full name of the Target Scheme.

MapSetSchemeVersion

Cross Map Sets Table Data Field Field Type Permitted characters Length MapSetSchemeVersion String Any (except LF, CR and 1 to 12 TAB)

The version number of the Target Scheme as published by the issuing organization.

MapSetRealmId

Cross Map Sets Table Data Field Field Type Permitted characters Length MapSetRealmId String Any (except LF, CR and 1 to 24 TAB)

A string identifying a Realm within which this mapping table is applicable. This is only used in cases where Realm specific business rules or guidelines alter the acceptable mappings. Realm is the same as used in the Subsets Table. It includes a four character ISO6523 identifier followed by an optional series of concatenated subdivision codes defined by the registered organization. Example: The EDI identifier scheme used by the NHS. The "0080" is the ISO6523 identifier for the NHS Trusts, Health Authorities, GP practices are issued with a ten-digit identifier and are permitted to issue subdivision codes of up to five digits in length. This results in a 19-digit string. Usage: This is only used in cases where Realm specific business rules or guidelines alter the acceptable mappings. In all other cases the RealmId has the value "0" (zero) and should be ignored.

MapSetSeparator

Cross Map Sets Table Data Field Field Type Permitted characters Length MapSetSeparator String Any (except LF, CR and 1 TAB)

The character used as a separator between the individual codes in the Target Codes field of the Cross Map Targets.

MapSetRuleType

Cross Map Sets Table Data Field Field Type Permitted characters Length MapSetRuleType Enumerated 0 to 9 1

An indication of the types of rules used in the Cross Maps and Cross Map Targets. This discussion of rules is included although rules are not yet used in the released SNOMED CT Cross Maps. However, this feature may be of interest to implementers. See Cross Mappings Guide on page 144 for more information.

Cross Maps Table Each row in the Cross Maps Table represents one option for mapping a Concept to a Cross Map Target. If there are several alternative Cross Maps for a Concept: • Each option is represented by a row in the Cross Maps Table. • Each row may include rules for choosing that option • The rules for choosing an option may be expressed as: • Machine-processable instructions • Textual advice to support manual coding • Both of the above

Key Fields The Cross Maps Table contains the following key fields: • MapSetId • MapConceptId • MapOption

MapSetId

Cross Maps Table Key Fields Field Type Permitted characters Length MapSetId SCTID 0 to 9 6 to 18

The unique SNOMED CT Identifier for the Cross Map Set of which this Cross Map is a member.

MapConceptId

Cross Maps Table Key Fields Field Type Permitted characters Length MapConceptId SCTID 0 to 9 6 to 18

The SNOMED CT Identifier of the mapped Concept.

MapOption

Cross Maps Table Key Fields Field Type Permitted characters Length MapOption Integer 0 to 9 1 to 5

An integer that distinguishes between alternative mappings for a single Concept. If automatic rules are used to determine which option is applicable, the Cross Map with the lowest MapOption value is tested first. Data Fields The Cross Maps Table contains the following data fields: • MapPriority • MapTargetId • MapRule • MapAdvice

MapPriority

Cross Maps Table Data Field Field Type Permitted characters Length MapPriority Integer 0 to 9 1 to 5

Indication of the suggested order in which to present a series of options for mapping a Concept for manual assessment. The first of these is the default option for mapping the Concept.

MapTargetId

Cross Maps Table Data Field Field Type Permitted characters Length MapTargetId SCTID 0 to 9 6 to 18

The unique SNOMED CT Identifier for a Cross Map Target to which this Concept can be mapped.

MapRule

Cross Maps Table Data Field Field Type Permitted characters Length MapRule String Any (except LF, CR and 0 to 255 TAB)

A machine-processable expression that determines whether this is an appropriate Cross Map. Note: The form of expression used for these rules depends on the MapSetRuleType and is discussed in Cross Mappings Guide on page 144.

MapAdvice

Cross Maps Table Data Field Field Type Permitted characters Length MapAdvice String Any (except LF, CR and 0 to 255 TAB)

Textual advice to support manual mapping decisions between this Cross Map and other alternative Cross Maps for mapping the same Concept.

Cross Map Targets Table Each row in this table represents a code or set of codes in the Target Scheme, which provides a mapping for one or more SNOMED CT Concepts. A Cross Map Target may include a rule indicating the conditions in which it applies. Key Fields

Cross Map Targets Table Key Fields Field Type Permitted characters Length TargetId SCTID 0 to 9 6 to 18

The unique SNOMED CT Identifier for the Cross Map Set of which this Cross Map is a member. See The SNOMED Clinical Terms Identifier (SCTID) on page 120. Data Fields The Cross Map Targets Tablecontains the following data fields: • TargetSchemeId • TargetCodes • TargetRule • TargetAdvice

TargetSchemeId

Cross Map Targets Table Data Field Field Type Permitted characters Length TargetSchemeId String Any (except LF, CR and 1 to 64 TAB)

A standard identifier for the coding scheme in which the TargetCodes are expressed. This may be an International Coding Scheme Identifier (ISO7826) or an Object Identifier (OID) used as specified by HL7. Note: The value of this field must be the same as the MapSetSchemeId of any Cross Map Set that includes Cross Maps referring to this Cross Map Target.

TargetCodes

Cross Map Targets Table Data Field Field Type Permitted characters Length TargetCodes String Any (except LF, CR and 1 to 255 TAB)

A code or list of codes in the Target Scheme that together represent an appropriate mapping for one or more Concepts. If more than one code is included: • A separator character specified in the Cross Map Sets Table is used to separate the codes. • The mapping is to the combination of all the codes in the list. This field may be null if no target codes apply to this cross map.

TargetRule

Cross Map Targets Table Data Field Field Type Permitted characters Length TargetRule String Any (except LF, CR and 0 to 255 TAB)

A machine processable expression of rules that determine the combinations of conditions to which this Cross Map Target applies. Note: The form of expression used for these rules depends on the Map Set Rule Type and is discussed in Cross Mappings Guide on page 144.

TargetAdvice

Cross Map Targets Table Data Field Field Type Permitted characters Length TargetAdvice String Any (except LF, CR and 0 to 255 TAB)

Textual advice expressing the combinations of conditions to which this Cross Map Target applies.

® SNOMED CT - LOINC Integration Table Note: The LOINC Integration Table is not currently supported by the IHTSDO, and has not been updated for the current SNOMED CT International Release. The information below is provided for reference purposes only.

The Laboratory LOINC database provides a standardized set of names and codes for identifying laboratory test results. Created by the Regenstrief Institute, the purpose of LOINC is to facilitate the exchange and pooling of results for outcomes management and research. Each LOINC code represents a unique laboratory test distinguished by six main parts that include the analyte measured, the property observed, the time aspect involved, the sample or system type, the scale of measurement, and where relevant the method of measurement. Taken together, these six components define a single laboratory test result. Additional details about LOINC, including access to the LOINC database files, are available from www.regenstrief.org/loinc/loinc.htm. SNOMED CT is a clinical reference terminology. SNOMED CT concepts are explicitly represented in a multi-hierarchical structure. Each of the six distinguishing parts of a given LOINC test result are found in SNOMED CT and assigned in a hierarchy. The integration exists as a table containing 11 columns. The first nine columns of the table are taken directly from the Laboratory LOINC version 1l database. The last two columns contain concept identifiers from SNOMED CT that relate a specific component of the LOINC test to the SNOMED CT hierarchy. An excerpt from the LOINC-SNOMED integration table is shown below. This example shows how LOINC code 5792-7 is defined in the integrated SNOMED hierarchy.

Table 15: Excerpt from SNOMED-LOINC Integration table

LOINC COMP- PROP- TIME_ AS- SYSTEM SCALE_ METHOD Relations- Conce- _NUM ONENT ERTY PCT TYP _ TYP hip_ Type ptID 5792-7 GLUCOSE MCNC PT UR QN TEST 116684007 123029007 STRIP 5792-7 GLUCOSE MCNC PT UR QN TEST 116678009 67079006 STRIP 5792-7 GLUCOSE MCNC PT UR QN TEST 116680003 69376001 STRIP 5792-7 GLUCOSE MCNC PT UR QN TEST 116686009 122575003 STRIP 5792-7 GLUCOSE MCNC PT UR QN TEST 116685008 118539007 STRIP 5792-7 GLUCOSE MCNC PT UR QN TEST 116687000 30766002 STRIP 5792-7 GLUCOSE MCNC PT UR QN TEST 84203001 117021008 STRIP

Data in the following columns of the SNOMED-LOINC Integration table are derived directly from the LOINC table: LOINC_NUM = LOINC code COMPONENT = one of the six parts of the LOINC fully specified name; maps to the SNOMED RelationshipType "has measured component" PROPERTY = one of the six parts of the LOINC fully specified name; maps to the SNOMED RelationshipType "has property" TIME_ASPCT = one of the six parts of the LOINC fully specified name; maps to the SNOMED RelationshipType "has time aspect" SYSTEM = one of the six parts of the LOINC fully specified name; maps to the SNOMED RelationshipType "has specimen"

SCALE_TYP = one of the six parts of the LOINC fully specified name; maps to the SNOMED RelationshipType "has scale type" METHOD_TYP = one of the six parts of the LOINC fully specified name; maps to the SNOMED RelationshipType "has method" RELAT_NMS = column in the LOINC table that provides synonyms (when applicable) for the fully specified LOINC name. ANSWERLIST = column in the LOINC table that provides examples of answers for results that are reportable from a multiple choice list (when applicable) Data in the last two columns of the SNOMED-LOINC Integration table are derived directly from the SNOMED CT Concepts Table: Relationship_Type = Concept identifier (ConceptID) from the SNOMED CT Concepts table; defines the relationship between the LOINC name and the target SNOMED concept. ConceptID = target SNOMED Concept from the SNOMED CT Concepts table The SNOMED-LOINC integration table may be better visualized with the following figure, where the SNOMED identifiers in the last two columns are replaced with their corresponding SNOMED CT description. The table below is an example of SNOMED-LOINC integration with SNOMED ConceptIDs in last two columns replaced with the SNOMED description. Underlined cells highlight the part of the LOINC fully specified name that is being mapped in each row.

LOINC_ COMPONENT PROPERTY TIME_ SYSTEM SCALE_ METHOD_ RELAT_ ANSWER Relationship_ ConceptID NUM ASPCT TYP TYP NMS LIST Type

© 5792-7 GLUCOSE MCNC PT UR QN TEST STRIP Is a Urinalysis, 2002-2010 glucose, qualitative 5792-7 GLUCOSE MCNC PT UR QN TEST STRIP has Glucose The measured International component 5792-7 GLUCOSE MCNC PT UR QN TEST STRIP Has property Mass concentration

Health 5792-7 GLUCOSE MCNC PT UR QN TEST STRIP has time Single point aspect in time T erminology 5792-7 GLUCOSE MCNC PT UR QN TEST STRIP Has Urine specimen specimen 5792-7 GLUCOSE MCNC PT UR QN TEST STRIP Has scale Quantitative Standards type 5792-7 GLUCOSE MCNC PT UR QN TEST STRIP Has method Test strip

Development method Organisation T able Structure Details | 107 108 | SNOMED CT Technical Reference Guide - January 2010

The value of the SNOMED/LOINC integration lies within the structure of the corresponding SNOMED hierarchies. For example, the first row in the figures above show that LOINC 5792-7 is a "Urinalysis, glucose, quantitative" (ConceptID 123029007). Looking up ConceptId 123029007 ("Urinalysis, glucose, quantitative") in the SNOMED CT Relationships Table, the following hierarchy can be traced: • Urinalysis, glucose, quantitative IS A Urinalysis • Urinalysis IS A Body fluid analysis • Body fluid analysis IS A Laboratory procedure • Laboratory Procedure IS A Procedure In the LOINC-SNOMED integration, numerous other Laboratory LOINC codes are also defined as IS A Urinalysis (16408-7, 11135-1, etc.) or, as in the example above, a child of Urinalysis (11276-3, 11258-0, etc.). The SNOMED-LOINC integration enables aggregation of LOINC-coded data, so that all urinalysis tests, for example, can be isolated. Listed below is a small sample of LOINC codes that would be included in a retrieval of all urinalysis procedures.

LOINC_NUM COMPONENT PROPERTY TIME_ASPCT SYSTEM SCALE_TYP METHOD_TYP 11276-3 TUBULAR CELLS ACNC PT URNS ORD MICROSCOPY.LIGHT ©

2002-2010 11277-1 SQUAMOUS CELLS NARIC PT URNS QN MICROSCOPY.LIGHT.HPF 11278-9 BLADDER CELLS NARIC PT URNS QN MICROSCOPY.LIGHT.HPF 11279-7 URINE SEDIMENT COMMENT FIND PT URNS NAR MICROSCOPY.LIGHT The

International 12248-1 RENAL CELLS ACNC PT URNS ORD MICROSCOPY.LIGHT 12258-0 SQUAMOUS CELLS ACNC PT URNS ORD MICROSCOPY.LIGHT.HPF 12448-7 KETONES^ POST CFST MCNC PT UR QN TEST STRIP

Health 12512-0 BRUSHITE CRYSTALS ACNC PT URNS ORD MICROSCOPY.LIGHT

T 13653-1 EPITHELIAL CELLS.RENAL NCNC PT URNS QN erminology 13945-1 ERYTHROCYTES NARIC PT URNS QN MICROSCOPY.LIGHT.HPF 15033-4 ASCORBATE SRAT 24H UR QN Standards 16408-7 ASCORBATE MCNC PT UR QN 1702-0 ACETOACETATE MCNC PT UR QN

Development 18407-7 LEUKOCYTES NRAT 12H URNS QN MICROSCOPY.LIGHT 18487-9 BROAD CASTS NARIC PT URNS QN MICROSCOPY.LIGHT.LPF 20409-9 ERYTHROCYTES NCNC PT UR QN TEST STRIP Organisation 20453-7 EPITHELIAL CELLS ACNC PT URNS ORD MICROSCOPY.LIGHT 20409-9 ERYTHROCYTES NCNC PT UR QN TEST STRIP T able Structure Details | 109 110 | SNOMED CT Technical Reference Guide - January 2010

The SNOMED CT Relationships Table enables even broader searches such as, for example, all body fluid analyses. Since Urinalysis is a Body fluid analysis all the LOINC codes shown above would be included in the search, in addition to LOINC codes for CSF analyses, joint fluid analyses, etc. The SNOMED-LOINC Integration provides a mechanism that reflects the complementary relationship between LOINC and SNOMED. This integration yields formally defined appropriately classified laboratory terms that can be implemented in the design of robust laboratory analysis applications.

Table 18: Comments on Some LOINC Analyte Names and Their Corresponding SNOMED Codes

LOINC Analyte Name(s) SNOMED ID Comments SNOMED ConceptID

ENTEROTOXIN C-00226 This may represent an assay for bacterial 116554007 enterotoxins, but rotavirus also produces an enterotoxin, and so we use the more general parent term C-00226 Enterotoxin, instead of the more specific term C-36205 Bacterial enterotoxin.

ANTHRAQUINONE C-10097 LOINC lists 9,10 anthracenedione as a related name 9,10-ANTRHACENEDIONE for ANTHRAQUINONE, with CAS number 84-65-1 ------(the number for 9,10anthracenedione. The SNOMED 116283009 code means the class of anthraquinones, which includes anthraquinone antineoplastics (e.g. mitoxantrone) as well as anthraquinone laxatives and anthraquinone dyes. We assume an anthraquinone assay would measure any anthraquinone, not just 9,10anthracenedione.

BUTANE N-BUTANE C-20522 Butane and n-butane are generally regarded as 73229004 synonyms. In other words, ordinarily isobutane (C-20527) is specified explicitly, and is not counted as a subtype of butane.

HEXANE N-HEXANE C-20524 Unlike butane, hexane is a general term for 6carbon 40647006 saturated hydrocarbons. N-hexane is one isoform. C-20529 123008003

DIOXANE 1,4-DIOXANE C-21304 Assume dioxane is 1,4-diethylene dioxide, same as 27247007 1,4-dioxane.

HEXACHLOROCYCLOHEXANE C-23112 LOINC lists CAS 608-73-1, but this refers to GAMMA 49490007 hexachlorocyclohexane mixed isomers (SNOMED HEXACHLOROCYCLOHEXANE code C-20885). We assume a hexachlorocyclohexane C-91170 assay would measure any isomer or mixture of 77496001 isomers, so the parent term C-23112 is the right one, even though it does not correspond to CAS 608-73-1.

FENCLORVOS FENCHLORPHOS C-23151 Fenclorvos is probably a "spelling variant" of 22008009 fenchlorphos.

LOINC Analyte Name(s) SNOMED ID Comments SNOMED ConceptID

ENDOTOXIN C-36210 We assume "endotoxin" and "bacterial endotoxin" are 18127008 synonymous.

KETOCONAZOLE C-52B50 Ketokonazole is probably a "spelling variant". KETOKONAZOLE 40232005

MONACETYLDAPSONE C-55296 Monacetyldapsone may be a "spelling variant" of MONOACETYLDAPSONE 123003007 monoacetyldapsone.

ACETYLMORPHINE C-606B3 We assume these are all the same as MONOACETYLMORPHINE 118290009 6-Omonoacetylmorphine, the major metabolite of 6-MONOACETYLMORPHINE heroin (besides morphine). If this is true, it appears to result in some duplicate LOINC codes.

OXYCODINONE OXYCODONE C-606D0 Oxycodinone is probably another name for oxycodone, 55452001 but we were unable to find the name Oxycodinone in MEDLINE or any major chemical/drug reference.

6-BETA NALTREXONE 6-BETA C-60D22 The major metabolite of naltrexone is 6-beta naltrexol, NALTREXOL 116562004 also called 6-beta hydroxynaltrexone. We assume this is what is meant by 6-beta naltrexone.

METHABARBITAL METHARBITAL C-61340 LOINC related names for Methabarbital says 30676006 Barbitone (not the same! Barbitone is Ethylbarbital!) and also Metharbital (the correct name) is a synonym. "Methabarbital" does not occur in MEDLINE, though some lists of controlled substances also use this spelling.

DESMETHYLDOXEPIN C-62285 These are synonyms for the demethylated metabolite NORDOXEPIN 96204007 of doxepin, N-desmethyldoxepin.

HYDROXYALPRAZOLAM ALPHA C-64523 Probably hydroxyalprazolam is intended to include HYDROXYALPRAZOLAM 123010001 both alpha- and 4- hydroxyalprazolam... (C-64521 is the alpha form). C-64521 117158005

N-DESALKYLFLURAZEPAM C-64552 Synonyms for a major metabolite of flurazepam, DESALKYLFLURAZEPAM 115558004 N-1-desalkylflurazepam.

DESMETHYLAMIODARONE C-80352 The only important metabolite of amiodarone DESETHYLAMIODARONE 96295003 (particularly in humans) is DESETHYLAMIODARONE, which is the meaning we have chosen here. There are no MEDLINE references containing the word DESMETHYLAMIODARONE, and we have assumed the addition of the "M" may be a spelling error.

LOINC Analyte Name(s) SNOMED ID Comments SNOMED ConceptID

LINDANE C-91170 Lindane is the gamma isomer of 77496001 hexachlorocyclohexane (strictly speaking must contain over 99% pure gamma isomer).

AMINOBENZOATE PARA C-93210 Para-aminobenzoic acid (PABA), UV screen, B AMINOBENZOATE 39707000 vitamin. Although both m-aminobenzoic acid and o-aminobenzoic acid exist, they are probably not what is meant here.

FLUBIPROFEN FLURBIPROFEN C-96050 Flubiprofen is probably a "spelling variant" of 54344006 flurbiprofen.

2-AMINOBUTYRATE F-65C04 2-aminobutyrate. 2-AMINOBUTYRIC 115343006

A-1-IDURONIDASE F-6A928 Alpha L iduronidase. 86430005

KETOGENIC STEROIDS F-B2430 Assume these mean the same. These steroids have 17-KETOGENIC STEROIDS 46120009 an -OH on C17. They include all of the 17-hydroxycorticosteroids, plus pregnanetriol, cortol, cortolone, etc.

17-HYDROXYKETOSTEROIDS F-B2430 Possibly means any steroids with a keto or hydroxy 46120009 on carbon 17. Assume these are the 17-ketogenic steroids.

20-HYDROXYPROGESTERONE F-B2460 F-B2460 is 20-Hydroxyprogesterone, but LOINC 52422003 related names and the CAS number both point to 17-alpha hydroxyprogesterone, which is F-B2470 (and has a keto group at C20!).

11-DEOXYCORTISOL F-B2480 These two are assumed to be the same. DEOXYCORTISOL 22941009

HYDROCORTICOSTERONE F-B2491 Corticosterone is 18-HYDROXYCORTICOSTERONE 103034000 11,21-Dihydroxypregn-4ene-3,20-dione; hydroxylation of corticosterone could commonly occur at carbons 17 and 18. If a hydroxy is added at 17 we get cortisol, and at 18 we get 18hydrocorticosterone. We assume "hydrocorticosterone" means the latter.

11-OXOPREGNANETRIOL F-B2746 Assume this is a class that includes 116617008 11ketopregnanetriol plus 11-hydroxy substituted pregnanetriol.

LOINC Analyte Name(s) SNOMED ID Comments SNOMED ConceptID

ANDROSTANEDIOL F-B28A0 Same as 3-alpha-androstanediol, a major metabolite 103048000 of dihydrotestosterone. Distinct from the 3-beta- isomer.

HYDROXYCALCIDIOL F-BB140 Assume this is 24,25dihydroxycholecaliciferol. 1459001 Calcidiol is 25hydroxycholecalciferol. The other possibility might be calcitriol, which is 1,25dihydroxycholecalciferol.

COMPLEMENT C3.NEPHRITIC F-C2402 Complement C3 nephritic factor, is not a complement 123001009 component but an (auto)antibody which causes unregulated C3 splitting activity, usually by preventing intrinsic decay of C3bBb (F-C7640).

COMPLEMENT C4.NEPHRITIC F-C2403 Complement C4 nephritic factor, is not a complement 123002002 component but an (auto)antibody which prevents the intrinsic decay of C4b2a (F-C7540).

COMPLEMENT CLR2-CLS2 F-C70D1 Assume both refer to C1r2C1s2, see Biochem J 1989 COMPLEMENT C1R2+C1S2 123000005 Oct 15;263(2):463-9 "The quaternary structure in solution of human complement subcomponent C1r2C1s2".

COMPLEMENT C'2 ESTERASE F-C7100 Assume these mean the complement components COMPLEMENT C'3 ESTERASE 923009 C2, C3 and C4. The "prime" symbol (C') used in early COMPLEMENT C'4 ESTERASE literature has been dropped from complement F-C7150 nomenclature. C2, C3 and C4 are proenzymes. 10473000 F-C7200 65044008

COMPLEMENT C3B.INACTIVE F-C7171 Could also have LOINC name "COMPLEMENT IC3B". 122999009

COMPLEMENT IC3 F-C7172 Could also have LOINC name "COMPLEMENT 123004001 C3.INACTIVE".

COMPLEMENT MEMBRANE F-C7A10 Also known as MCP and CD46, a "widely distributed C3BC4B COFACTOR PROTEIN 73042005 C3b/C4b-binding glycoprotein that inhibits complement activation".

HYDROXYTRYPTAMINE F-CB040 Serotonin is 5-hydroxytryptamine. SEROTONIN 33635003 (5hydroxytryptophan is a precursor).

L LITTLE E NOS AG F-D1300 There is no Le NOS antigen, but perhaps this means 2728001 Lewis blood group antigen, not otherwise specified.

LOINC Analyte Name(s) SNOMED ID Comments SNOMED ConceptID

ENTEROVIRUS L-30200 Picornavirus group. 32697003

File Structure SNOMED-LOINC Integration version 1.0 is provided as an ASCII tab delimited flat file. Note: There have been no additions or significant updates to this file since the release of SNOMED RT Version 1.1. Minor revisions have been made where SNOMED concepts have been retired and, in some cases, replaced with other concepts.

The first row of the file contains column headings.

Column Name Data Type Max. Description Length LOINC_NUM Char 7 The unique LOINC Code.4 COMPONENT Char 150 Fields 2-7 contain the six parts of the name. The fully specified name for a given LOINC code would be PROPERTY Char 10 constructed by printing out the contents of these fields TIME_ASPCT Char 10 (27), inserting a colon (:) between the contents of each of these fields.5 SYSTEM Char 50 SCALE_TYP Char 30 METHOD_TYP Char 50 RELAT_NMS Char 254 One or more synonyms, separated by semicolons (;). This field is intended to make it easier to find a given observation by providing other names by which the observation may be known. For a drug level, for example, we include the trade names of that drug under the related names.6 ANSWERLIST Char 2056 The list of answers for results that are reportable from a multiple choice list (e.g., the answers for the term DISPOSITION OF BLOOD PACK are GIVEN;PARTIALLY GIVEN;DISCARDED). This field provides examples, not required answer lists.7

4 Copyright 1995-2008, Regenstrief Institute and the Logical Observation Identifier Names and Codes (LOINC®) Committee. All rights reserved. 5 Copyright 1995-2008, Regenstrief Institute and the Logical Observation Identifier Names and Codes (LOINC®) Committee. All rights reserved. 6 Copyright 1995-2008, Regenstrief Institute and the Logical Observation Identifier Names and Codes (LOINC®) Committee. All rights reserved. 7 Copyright 1995-2008, Regenstrief Institute and the Logical Observation Identifier Names and Codes (LOINC®) Committee. All rights reserved.

Column Name Data Type Max. Description Length RelationshipType Integer 18 SNOMED CT Concept Identifier (ConceptId) from the SNOMED CT Concepts table. Defines the relationship between the LOINC name and the target SNOMED concept. ConceptID Integer 18 Target SNOMED Concept ID from the SNOMED CT Concepts table

History

Component History Table

Each row in the Component History Table represents a single instance of a change to a Component in a particular release of SNOMED CT.

Key Fields The Component History Table has the following key fields: • ComponentId • ReleaseVersion • ChangeType

ComponentId

Component History Table Key Fields Field Type Permitted characters Length ComponentId SCTID 0 to 9 6 to 18

The unique SNOMED CT Identifier for the changed Component. The Component may be a Concept, Description, Relationship, Subset or a Cross Map Set.

ReleaseVersion

Component History Table Key Fields Field Type Permitted characters Length ReleaseVersion Integer 0 to 9 8

The version of SNOMED CT in which this change was made. Several changes may be made during internal maintenance between one release and the next but only the net result of these changes is recorded in the distributed Component History Table. Therefore, no more than one change is recorded for each Component in each Release Version. The format for this field is the ISO format date of the release, not the date of the individual change to the component. The format is "yyyymmdd" so for a release on 10 December 2002 the value would be "20021210". Please refer to History on page 37 for details about the special considerations for the Release Version values used for the SNOMED CT First Release that merged the SNOMED RT and Clinical Terms Version 3 terminologies.

ChangeType

Component History Table Key Fields Field Type Permitted characters Length ChangeType Enumerated 0 to 9 1

An indication of the nature of the change. Values

0 Added The Component was added to SNOMED CT in this Release Version. 1 Status Change The status of the Component has changed since the last Release Version. 2 Minor Change A minor change has been made to this Component since the last Release Version. All other changes require a Component to be inactivated and replaced with a new component with a different SCTID.

Data Fields The Component History Table has the following data fields: • Status • Reason

Status

Component History Table Data Fields Field Type Permitted characters Length Status Enumerated 0 to 9 1 to 2

The status of the Component after the change.

Values

0 Current Active Component In current use. This may apply to any type of Component. However, a Description only has this status if both it and its associated Concept are in current use. 1 Retired Inactivated without a specified reason. 2 Duplicate Inactivated as it duplicates another Component 3 Outdated Inactivated from current use because it is no longer in general clinical use. 4 Ambiguous Concept withdrawn as it is inherently ambiguous. 5 Erroneous Inactivated as it contains errors. A corrected but otherwise similar Component has been added to replace it. 6 Limited Applies to an Inactive Component that is based on a classification concept or an administrative definition. Also applies to all valid Descriptions of that Concept. 7 Inappropriate Description has been inactivated as the Term should not refer to this concept. 8 Concept Inactive Remains as a valid Description of a Concept which is no longer active. 9 Implied Relationship withdrawn but is implied by other active Relationships. 10 Moved elsewhere The Concept has been moved to an Extension, to a different Extension, or to the core. Use the “Moved To” Relationship to located the Namespace to which the Concept has been moved. These Concepts are considered inactive. 11 Pending move The Concept will be moved to an Extension, to a different Extension, or to the core. Use the “Moved To” Relationship to locate the Namespace to which the Concept will be moved when the recipient organization confirms the move. These Concepts are considered active.

Notes: The permitted values differ according to the nature of the Component. The release tables contain active and Inactive Concepts and Descriptions. The status value in the most recent Status Change associated with each Concept and Description will be identical to the value in the ConceptStatus or DescriptionStatus field for that Component. Relationships, Subsets, Cross Map Sets and Cross Map Targets are only included in a release if their status is “current”. Therefore, the only source of information about the changing status of these Components is the Component History Table and References Table (for Future Use). The released Subsets Table contains current Subsets and may also contain previous versions of Subsets (distinguished by the Subset Version).

Reason

Component History Table Data Fields Field Type Permitted characters Length Reason String Any (except LF, CR and 0 to 255 TAB)

An optional textual description of the reasons for this change.

References Table

Each row in the References Table represents a Reference from an inactive Component to other equivalent or related Components that were current in the Release Version in which that Component was inactivated. Each Reference indicates the nature of the relationship between the Components. The References Table contains References: • From each inactive Description to one or more other Descriptions that are current in the Release Version in which the Description was inactivated. • From each inactive Subset for which there is a current replacement to the replacement Subset. • From each inactive Cross Map Set for which there is a current replacement to the replacement Cross Map Set. • From an inactive Description to a Concept that is current in the Release Version in which the Description was inactivated, and which is correctly described by the Term of the inactive Description. • From an inactive Concept with ConceptStatus = 10 (Moved Elsewhere) to one or more other Concepts that are active in the Release Version in which the Concept's status is set to "10". The References Table does not include References: • Between Concepts • Except for Concepts with ConceptStatus = 10, as described above. For all other Concepts, equivalent functionality is provided by Relationships with specialized Relationship Types. The rules for their use for tracking replacement Concepts are outlined in Component History Rules on page 40.

• Between Relationships • There are technical obstacles to tracking Relationships that replace or imply other inactive Relationships and no practical use case has been identified in which this would provide added value.

The requirement for References between Cross Map Targets depends on further analysis and definition of this type of Component.

Key Fields The References Table has the following key fields: • ComponentId • ReferenceType • ReferencedId

ComponentId

References Table Key Fields Field Type Permitted characters Length ComponentId SCTID 0 to 9 6 to 18

The unique SNOMED Clinical Terms Identifier for the inactive Component. The Component may be a Description, a Subset, a Cross Map Set, or a Concept with ConceptStatus = 10 (Moved Elsewhere). If the Component is a Concept, then ReferenceType may only have a value of "1" (Replaced By) or "4" (Alternative).

Note: The format and construction of these identifiers is described in The SNOMED Clinical Terms Identifier (SCTID) on page 120.

ReferenceType

References Table Key Fields Field Type Permitted characters Length ReferenceType Enumerated 0 to 9 1 to 5

Indicates the nature of the relationship between the inactive Component and the active Component. Values:

1 Replaced by Refers to a revised replacement for the Component. 2 Duplicated by Refers to an identical duplicate for the Component. 3 Similar to Refers to a Description that is identical in all respects except for the associated Term which, while not identical, is similar 4 Alternative Refers to one of several alternatives that are similar or equivalent to the Component (e.g. where a single Component is replaced by two more narrowly defined Components). 5 Moved to Refers to the Concept identifying the target Namespace to which a Component has been moved (Status value Moved Elsewhere or is scheduled to be moved (Status value Pending Move). 6 Moved from Refers to an original Component in another Namespace which is the source of this current Component. 7 Refers to Concept Refers to a Concept which is correctly described by the Term of an inactive Description.

ReferencedId

References Table Key Fields Field Type Permitted characters Length ReferencedId SCTID 0 to 9 6 to 18

The unique SNOMED Clinical Terms Identifier for the referenced Component. The Component identified by the ReferencedId must be an instance of the same class of Component as the component identified by the ComponentId, with two exceptions. 1. If the ReferenceType value is "5" (Moved to) or "6" (Moved from), ReferencedId must identify the namespace Concept of the namespace that the Component has been moved to or moved from. This approach is used since the organization sourcing the component may not always be able to determine the precise reference that is applicable in the receiving organization (namespace). Thus the responsibility for these references lies with the new responsible (receiving) organization. 2. If the ReferenceType value is “7” (Refers to Concept), then the ComponentId must identify a Description and ReferencedId must identify a Concept.

Appendix C

The SNOMED Clinical Terms Identifier (SCTID)

Topics:

• Introduction • SCTID Data Type • SCTID Representation • SCTIDs and Extensions • SCTID Constraints • Check-digit • Partition-identifier • Extension namespaces • Item identifier digits • Example SCTIDs

Introduction

Components within SNOMED Clinical Terms are identified using numeric identifiers. In the descriptions of the individual tables these identifiers are noted as having the data type SCTID. This section describes the characteristics of all fields with the data type SCTID. These identifiers have a common set of characteristics and obey a set of rules, which enable each identifier to refer unambiguously to a single component.

SCTID Data Type

The SCTID data type is a 64-bit integer, which is subject to the following constraints: • Only positive integer values are permitted. • The minimum permitted value is 100,000 (6 digits) • The maximum permitted value is 999,999,999,999,999,999 (18-digits). • As a result of rules for the partition-identifier and check-digit, many integers within this range are not valid SCTIDs.

SCTID Representation

The SCTID does not contain semantic information related to the meaning of a concept or term. It does however have a structure that is designed to allow different types of terminological components to be recognized. The nature of a component can also be derived from the table in which a component is distributed. However, the advantage of partitioning the SCTID is that it avoids reuse of the same identifier for a different type of component – thus avoiding ambiguity. This also allows the nature of the identifier to be recognized when stored in a record or transferred in a message. The rightmost digits in a decimal string representation of the SCTID have the following defined roles (see Figure 6: SCTID Structure for centrally issued component on page 122). • A single check-digit is used to validate the identifier. • A two-digit partition-identifier, which: • Ensures that the identifier is unique in the scope of SNOMED CT; for example, the same identifier cannot be allocated to a Concept and to a Description. • Ensures that the identifier of a component in a valid Extension of SNOMED CT cannot be the same as the identifier of a component in the main body of SNOMED CT.

Figure 6: SCTID Structure for centrally issued component

SCTIDs and Extensions

If the partition-identifier indicates that the SCTID is part of an Extension the next seven-digits (from the right) are a namespace-identifier (see Figure 7: SCTID Structure for a component in an Extension on page 122). Namespace-identifiers are allocated to organizations which are authorized to issue Extensions. They enable unique SCTIDs to be issued by many organizations and allow each SCTID to be traced to an authorized originating organization.

Figure 7: SCTID Structure for a component in an Extension

SCTID Constraints

The constraints on value range for SCTIDs allow consistent string and integer representation of these values. Exclusion of negative values avoids potential formatting confusion in string representations. The lower limit of 100,000 ensures the decimal string representation is at least six digits in length. This ensures that an SCTID can be distinguished from: • A Read Code, which is 4 or 5 characters in length. • A SNOMED ID, which always starts with a letter.

The upper limit of 18 digits ensures that any valid decimal string can be stored in either a signed or unsigned 64-bit integer.

Check-digit

The final (units) digit of the SCTID is the check-digit. It is not envisaged that users will be routinely required to type SCTID values. However, the objective of the check-digit is to detect the commonest types of error that may occur due to typographical errors on those occasions where transcription or communication mechanisms may introduce error. Examples may include high-level development such as creating or modifying protocols or pre-specified queries. An SCTID is checked by using the "Verhoeff check", which is a Dihedral D5 Check. This detects a higher proportion of common typographical errors than either the IBM or Modulus 11 check. Unlike the Modulus 11 check (used for the UK NHS number) it is effective on decimal strings longer than ten-digits. Furthermore its value can always be represented as a decimal digit without excluding any values. See Check-digit computation on page 132 for detailed information about the Verhoeff check-digit and sample program code.

Partition-identifier

The penultimate two-digits of the SCTID (second and third from the right), are the partition-identifier. The partition-identifier indicates the nature of the entity identified. This allows the identifier of a Description to be distinguished from the identifier of a Concept. It also allows SCTIDs issued centrally to components of the main body of SNOMED CT to be distinguished from components issued as parts of Extensions. Values Identifiers of components in the main body of SNOMED CT have one of the following partition-identifier values:

00 A Concept 01 A Description 02 A Relationship 03 A Subset 04 A Cross Map Set 05 A Cross Map Target

Identifiers of components in Extensions have one of the following partition-identifier values:

10 A Concept in an Extension 11 A Description in an Extension 12 A Relationship in an Extension 13 A Subset in an Extension 14 A Cross Map Set in an Extension 15 A Cross Map Target in an Extension

All other partition-identifier values are reserved for future use.

Extension namespaces

If the partition-identifier indicates that the SCTID is part of an Extension the seven-digits immediately to the left of the partition-digit are a namespace-identifier. Each organization that is authorized to issue Extensions is allocated a namespace-identifier. The authorized organization is permitted to assign any valid item identifier that ends with this string of digits. SNOMED CT core release files include Namespace Concepts representing each of the allocated Namespace-identifiers. These Concepts have the following characteristics: • They are direct subtypes of the Concept “Namespace Concept” which is a direct subtype of the Concept “Special Concept”. • The Fully Specified Name has the form “Extension Namespace {nnnnnnn} (namespace concept) – where nnnnnnn is the seven digit Namespace-identifier. • The Preferred Term associated with the Concept has the form “Extension Namespace nnnnnnn” • Where appropriate Synonyms may be included to identify the nature of the Extension and/or responsible organization. However, this information may not be made available for all Namespaces due to privacy constraints.

Item identifier digits

The remaining digits to the left of the partition-identifier (or in the case of Extensions, to the left of the namespace-identifier) are available to uniquely identify an individual entity within the specified partition. The same item identifier can be allocated in each partition and is rendered unique by the partition-identifier. For components in the main body of SNOMED CT, item identifiers will usually be issued in the arbitrary order in which components are added to SNOMED Clinical Terms. Due to management of the editing process the sequence of issued item identifiers may be discontinuous and the order of identifiers should be regarded as meaningless.

Example SCTIDs

The following SCTID examples are based on the above rules and illustrate the range of possible item identifiers within each partition.

SCTID Partition-identifier Check Notes -digit 100005 00=Concept 5=OK The Item identifier digits ‘1000’ are the lowest permitted value thus this is the lowest SCTID that can be allocated to a Concept. 100014 01=Description 4=OK This is the lowest SCTID that can be allocated to a Description. 100022 02=Relationship 2=OK This is the lowest SCTID that can be allocated to a Relationship. 100033 03=Subset 3=OK This is the lowest SCTID that can be allocated to a Subset.

SCTID Partition-identifier Check Notes -digit 101291009 00=Concept 9=OK A valid SCTID for a Concept. 1290023401015 01=Description 5=OK A valid SCTID for a Description. 9940000001029 02=Relationship 9=OK A valid SCTID for a Relationship. 40099901037 03=Subset 7=OK A valid SCTID for a Subset. 10000001105 10=Extra-Concept 5=OK A valid SCTID for a Concept in an Extension in the 0000001 namespace. 10989121108 10=Extra-Concept 8=OK A valid SCTID for a Concept in an Extension in the 0989121 namespace. 1290989121103 10=Extra-Concept 3=OK A valid SCTID for a Concept in an Extension in the 0989121 namespace. 1290000001117 11=Extra-Description 7=OK A valid SCTID for a Description in an Extension in the 0000001 namespace. 9940000001126 12=Extra-Relationship 6=OK A valid SCTID for a Relationship in an Extension in the 0000001 namespace. 40000001132 13=Extra-Subset 2=OK A valid SCTID for a Subset in an Extension in the 0000001 namespace. 999999990989121104 The maximum valid SCTID for a Concept in an Extension in the 0989121 namespace.

Appendix D

Distribution Files

Topics:

• Distribution Media • File Formats • Directory Structures and Naming Conventions • Terminology version information

Distribution Media

The SNOMED CT International Release is distributed to most Affiliates by an IHTSDO Member National Release Center. The core files are in the standard flat file structure for healthcare terminology. See the readme.txt file for a complete list of files included in the release. These files can be loaded into the specific file or database system used at your location.

File Formats

SNOMED CT files are UTF-8 encoded to support character sets from around the world. Some database products, such as Oracle, require UTF-8 to be specified in advance; if UTF-8 is not specified, there may be some difficulty with using and displaying the special characters used in some of the terms. Note that these special characters are used occasionally in the SNOMED English language edition, as well as in non-English editions. Some English language medical terms are eponyms, based on the name of an individual, which may contain special characters. As of January 2010, SNOMED CT release files are consistently named according to the convention documented in "IHTSDO File Naming Convention for SNOMED CT Release Files". The basic pattern for SNOMED CT release file names consists of five elements, each separated by an underscore (“_”) and followed by a full stop (“.”) and a file extension: ____. The file format standard used starting in 2002 is now called "Release Format One" or RF1. There is now a draft format that will eventually replace it, known as "Release Format Two" or RF2. During the testing and transition phase, files in both formats may be available, and therefore it is important to have a file naming convention that distinguished them. This is done using the number 1 or 2 in the FileType Element. As an example, here is the file name of the concepts file for the January 2010 release, in the current release format (RF1): • sct1_Concepts_Core_INT_20100131.txt The various parts of the concepts table name are given in the table below:

Table 19: File Naming Elements

Element Value Explanation FileType sct1 A terminology data file in Release Format 1 ContentType Concepts The data rows each represent a concept ContentSubType Core The file is part of the International Release (Release Format 1) Country or Namespace INT The file is part of the International Release Version Date 20100131 an 8-digit number in the pattern “YYYYMMDD”, in compliance with the ISO 8601 standard Extension txt The file is in text format

A readme.txt file is distributed with each release. It contains a full list of all files and file sizes.

Directory Structures and Naming Conventions

Where compressed files are used for distribution, each archive may contain multiple files and subdirectories. The archives are named to reflect the types of files they contain, the YYYYMMDD version, and the file extension “.zip”. For example, SNOMED_CT_International_Release_20070731_essential.zip was the name for the distributed zip archive for the essential files in the July 2007 release. Note that National Releases of SNOMED CT distributed by Member National Release Centers may use different directory structures and contain additional files.

Terminology version information

• Information about the current release is contained in a Description for the Root Concept Code. • The Description carrying this information is a Synonym (DescriptionType=2) and its status is current (DescriptionStatus=0). • The Description conveying version information for each release has a unique DescriptionId (i.e. it is not a revision of a previous versioning Description) • In each release there is only one Preferred Term and one current “version” Synonym associated with the Root Concept. All previous version Synonyms are non-current (DescriptionStatus=1). • The information in the “version” synonym is represented in the Term field as follows: • SNOMED Clinical Terms version: YYYYMMDD [status] (description) • status represents a word indicating of whether this is a release [R] or has some other status (e.g. for development set [D], evaluation [E], etc.). • yyyymmdd represents the release date in ISO format. • description is a textual description of the release (optional). • For example: SNOMED CT 20020131 [R]

• Other synonyms may be active for the Root Concept Code. SNOMED CT enabled applications must make this version information synonym visible, along with copyright and other similar information about the terminology.

Appendix E

Unicode UTF-8 encoding

Topics:

• Introduction • Character encoding • Notes on encoding rules • Example encoding

Introduction

UTF-8 is an efficient encoding of Unicode character-strings that recognizes the fact that the majority of text-based communications are in ASCII. It therefore optimizes the encoding of these characters. UTF-8 is ® supported by many 32-bit Windows applications. Unicode is preferred to ASCII because it permits the inclusion of accents, scientific symbols and characters used in languages other than English. The UTF-8 format is a standard encoding that provides the most efficient means of encoding 16-bit Unicode characters in cases where the majority of characters are in the ASCII range. Both UTF-8 and the alternative UTF-16 encoding are supported by modern 32-bit operating ® systems such as Windows 95, 98 and NT. SNOMED CT uses UTF-8 characters.

Character encoding

ASCII characters are encoded as a single byte. • Greek, Hebrew, Arabic and most accented European characters are encoded as two bytes. • All other characters are encoded as three bytes. • The individual characters are encoded according to the following rules.

Single byte encoding

Characters in the range 'u+0000' to 'u+007f' are encoded as a single byte.

byte 0 0 bits 0-6

Two byte encoding

Characters in the range 'u+0080' to 'u+07ff' are encoded as two bytes.

byte 0 byte 1 1 1 0 bits 6-10 1 0 bits 0-5

Three byte encoding

Characters in the range 'u+0800' to 'u+ffff' are encoded as three bytes:

byte 0 byte 1 byte 2 1 1 1 0 bits 12-15 1 0 bits 6-11 1 0 bits 0-5

Notes on encoding rules

The first bits of each byte indicate the role of the byte. A zero bit terminates this role information. Thus possible byte values are:

Bits Byte value Role 0???? ?? ? 000-127 Single byte encoding of a character 10??? ?? ? 128-191 Continuation of a multi-byte encoding 110?? ?? ? 192-223 First byte of a two byte character encoding 1110? ?? ? 224-239 First byte of a three byte character encoding 1111? ?? ? 240-255 Invalid in UTF-8

Example encoding

Character S C T ® Unicode 0053 0043 0054 00AE 2462 Bytes 01010011 01000011 01010100 11000010 10101110 11101111 10111111 10111111

Appendix F

Check-digit computation

Topics:

• Introduction • Reasons for using a check-digit • A brief comparison of check-digit effectiveness • Verhoeff’s Dihedral Group D5 Check • Sample Java Script for computing Verhoeff’s Dihedral Check • Sample Visual Basic for computing Verhoeff’s Dihedral Check

Introduction

The SCTID (See The SNOMED Clinical Terms Identifier (SCTID) on page 120) includes a check-digit, which is generated using Verhoeff's dihedral check. This section explains the reasons for including a check-digit and the rationale for use of this particular algorithm. It also includes sample source code for generating and checking the check-digit in Java Script and Microsoft Visual Basic.

Reasons for using a check-digit

Although a user should rarely type the SCTID, experience suggests that from time to time this will happen. A user may also copy and paste an SCTID. There is a significant risk of errors in these processes and inclusion of a check-digit is intended to reduce the risk of such errors passing undetected. The choice of check-digit algorithm has been made to maximize the detection of common typographical errors. These have been analyzed by in a paper by J. Verhoeff ("Error Detecting Decimal Codes", Mathematical Centre Tract 29, The Mathematical Centre, Amsterdam, 1969) and subsequently cited in Wagner and Putter, ("Error Detecting Decimal Digits", CACM, Vol 32, No. 1, January 1989). These papers give a detailed categorization of the sorts of errors humans make in dealing with decimal numbers, based on a study of 12000 errors: • single errors: a becomes b (60% to 95% of all errors) • omitting or adding a digit (10% to 20%) • adjacent transpositions: ab becomes ba (10% to 20%) • twin errors: aa becomes bb (0.5% to 1.5%) • jump transpositions: acb becomes bca (0.5% to 1.5%) • jump twin errors: aca becomes bcb (below 1%) • phonetic errors: a0 becomes 1a -similar pronunciation e.g. thirty or thirteen (0.5% to 1.5%) In the explanations above, a is not equal to b, but c can be any decimal digit.

A brief comparison of check-digit effectiveness

The IBM Check

The check-sums used for credit cards (the IBM check) picks up the most common errors but miss some adjacent transpositions and many jump transpositions. Assuming the pattern of errors described above, on average it will miss between 4% and 5% of expected errors.

The ISBN Check (Modulus 11)

The ISBN modulus 11 (used for UK NHS number) picks up more errors than the IBM checksum. Leaving 2% to 3% of errors undetected. However, it generates a check-sum value of 0 to 10 and thus cannot be represented as a single check-digit in about 9% of cases. The ISBN convention is to use "X" to represent the check-digit value 10 but this is incompatible with an integer representation. The UK NHS number uses this check-sum but regards and number generating a check-sum of 10 as an invalid identifier. This approach could be applied to the SCTID but this would render 9% of possible values unusable in each partition and namespace. This would prevent a simple sequence of values from being allocated as the "item identifier" within each namespace. More significantly the unusable item identifiers would differ in each namespace or partition and this would prevent simple transpositions of item identifiers between partitions and namespaces. Partitions could be a useful way of distinguishing developmental and released components and revising the partition and recalculating the check-digit would then be an elegant way to activate these components for a distribution version. It seems unwise to prevent future development and maintenance by using a check-sum that will prevent this.

Verhoeff’s Check

Verhoeff's check catches all single errors, all adjacent transpositions, over 95% of twin errors, over 94% of jump transpositions and jump twin errors, and most phonetic errors. Therefore, like modulus 11, the Verhoeff check reduces the undetected error rate to 2% or 3%. Unlike modulus 11, it does this using a single decimal check-digit and without limiting the range of valid numbers. The majority of the undetected errors with both modulus 11 and Verhoeff result from additions or omissions of digits. Any check-digit methods is likely to miss 10% of such errors and since these comprise 10% to 20%. The Verhoeff scheme also misses four jump twin errors involving digits with a difference of 5 (i.e. 050 vs. 505, 161 vs. 616, 272 vs. 727, and 494 vs. 949).

Verhoeff’s Dihedral Group D5 Check

The mathematical description of this technique may appear complex but in practice it can be reduced to a pair of two-dimensional arrays, a single dimensional inverse array and a simple computational procedure. These three arrays are shown in the following tables. • The first array contains the result of “Dihedral D5” multiplication. • The second array consists of 8 rows of which two are defined while the rest are derived by applying the following formula: F(i, j) = F(i - 1, F(1, j)). • The third array consists of a single row containing the inverse of the Dihedral D5 array it identifies the location of all the zero values in the first array.

Table 20: Results of Dihedral D5 multiplication

0 1 2 3 4 5 6 7 8 9 0 0 1 2 3 4 5 6 7 8 9 1 1 2 3 4 0 6 7 8 9 5 2 2 3 4 0 1 7 8 9 5 6 3 3 4 0 1 2 8 9 5 6 7 4 4 0 1 2 3 9 5 6 7 8 5 5 9 8 7 6 0 4 3 2 1 6 6 5 9 8 7 1 0 4 3 2

0 1 2 3 4 5 6 7 8 9 7 7 6 5 9 8 2 1 0 4 3 8 8 7 6 5 9 3 2 1 0 4 9 9 8 7 6 5 4 3 2 1 0

Table 21: The full array for Function F

0 1 2 3 4 5 6 7 8 9 0 0 1 2 3 4 5 6 7 8 9 1 1 5 7 6 2 8 3 0 9 4 2 5 8 0 3 7 9 6 1 4 2 3 8 9 1 6 0 4 3 5 2 7 4 9 4 5 3 1 2 6 8 7 0 5 4 2 8 6 5 7 3 9 0 1 6 2 7 9 3 8 0 6 4 1 5 7 7 0 4 6 9 1 3 2 5 8

Table 22: The Inverse D5 array

0 1 2 3 4 5 6 7 8 9 0 4 3 2 1 5 6 7 8 9

The identifier is checked by starting at the rightmost digit of the identifier (the check-digit itself) and proceeding to the left processing each digit as follows: • Check = ArrayDihedralD5 (Check, ArrayFunctionF((Position Modulus 8), Digit)) Check = the running value of the check-sum (starts at zero and modified by each step). Position = the position of the digit (counted from the right starting at zero). Digit = the value of the digit.

The final value of Check should be zero. Otherwise the check has failed. When calculating the check-digit the same process is applied with a minor variation: • Position is the position that the digit will have when the check-digit has been appended. • The final value of Check is applied to the Inverse D5 array to find the correct check-digit. Check-digit = ArrayInverseD5 (Check).

Sample Java Script for computing Verhoeff’s Dihedral Check

The script is presented here as part of an HTML page.

Verhoeff's Check

Verhoeff's Dihedral Check Digit

Note: The code above can be used by copying all the lines in the above section into a plain text document and naming it “checksum.htm”. Then open that document in a web browser.

Sample Visual Basic for computing Verhoeff’s Dihedral Check

Private Dihedral(9) As Variant Private FnF(7) As Variant Private InverseD5 As Variant Public Function VerhoeffCheck(ByVal IdValue As String) As Boolean 'Check the supplied value and return true or false

Dim tCheck As Integer, i As Integer VerhoeffArrayInit For i = Len(IdValue) To 1 Step -1 tCheck = Dihedral(tCheck)(FnF((Len(IdValue) - i) Mod 8)(Val(Mid(IdValue, i, 1))))

Next VerhoeffCheck = tCheck = 0

End Function

Public Function VerhoeffCompute(ByVal IdValue As String) As String

Dim tCheck As Integer, i As Integer 'Compute the check digit and return the identifier complete with check-digit VerhoeffArrayInit For i = Len(IdValue) To 1 Step -1 tCheck = Dihedral(tCheck)(FnF((Len(IdValue) - i + 1) Mod 8)(Val(Mid(IdValue, i, 1)))) Next VerhoeffCompute = IdValue & InverseD5(tCheck) End Function

Private Sub VerhoeffArrayInit()

'Create the arrays required

Dim i As Integer, j As Integer

'if already created exit here

If VarType(InverseD5) >= vbArray Then Exit Sub

'create the DihedralD5 array Dihedral(0) = Array(0, 1, 2, 3, 4, 5, 6, 7, 8, 9) Dihedral(1) = Array(1, 2, 3, 4, 0, 6, 7, 8, 9, 5) Dihedral(2) = Array(2, 3, 4, 0, 1, 7, 8, 9, 5, 6) Dihedral(3) = Array(3, 4, 0, 1, 2, 8, 9, 5, 6, 7) Dihedral(4) = Array(4, 0, 1, 2, 3, 9, 5, 6, 7, 8) Dihedral(5) = Array(5, 9, 8, 7, 6, 0, 4, 3, 2, 1) Dihedral(6) = Array(6, 5, 9, 8, 7, 1, 0, 4, 3, 2) Dihedral(7) = Array(7, 6, 5, 9, 8, 2, 1, 0, 4, 3) Dihedral(8) = Array(8, 7, 6, 5, 9, 3, 2, 1, 0, 4) Dihedral(9) = Array(9, 8, 7, 6, 5, 4, 3, 2, 1, 0)

'create the FunctionF array

FnF(0) = Array(0, 1, 2, 3, 4, 5, 6, 7, 8, 9) FnF(1) = Array(1, 5, 7, 6, 2, 8, 3, 0, 9, 4)

'compute the rest of the FunctionF array

For i = 2 To 7 FnF(i) = Array(0, 0, 0, 0, 0, 0, 0, 0, 0, 0) For j = 0 To 9 FnF(i)(j) = FnF(i - 1)(FnF(1)(j)) Next Next

'Create the InverseD5 array InverseD5 = Array("0", "4", "3", "2", "1", "5", "6", "7", "8", "9") End Sub

Appendix G

Top Levels and Special Codes

Topics:

• The Root Concept Code and the Root Metadata Code • Top Level Concept Codes • Top Level Metadata Codes

The Root Concept Code and the Root Metadata Code

The Concepts Table includes two special Codes referred to as the Root Concept Code and the Root Metadata Code. They are at the "root" of the two hierarchies that contain all Concept Codes in SNOMED CT. All other Concept Codes are descended from these two "root" codes via at least one series of Relationships of the Relationship Type IS A (i.e. all other Concept Codes are regarded as subclasses of these Concept Codes). The Root Concept Code is 138875005 and is named SNOMED CT Concept. The Root Metadata Code is 900000000000441003 and is named SNOMED CT Model Component. Note: The Root Metadata Code and the hierarchy under it have been included in a technology preview release, but have been omitted from the official January 2010 International Release of SNOMED CT. The technology preview provides SNOMED CT in a new release format, called Release Format 2 (RF2), as a draft for trial use.

In each release of SNOMED CT the Root Concept Code will be associated with a Description stating the release date in a human readable form. The objective of this term is to provide a simple implementation independent mechanism for a person to determine what is the current installed release of SNOMED CT.

Top Level Concept Codes

Concept Codes that are directly related to the Root Concept Code or the Root Metadata Code by a single Relationship of the Relationship Type IS A are referred to as "Top Level Concept Codes" or "Top Level Metadata Codes". All other concept codes are descended from at least one Top Level Concept or Metadata Code via at least one series of Relationships of the Relationship Type IS A (i.e. all other concept codes represent subclasses of the meaning of at least one Top Level Concept Code or Metadata Code). Most Top Level Concept Codes are intended to represent things outside of SNOMED CT (including processes, events, and material entities) in the real world. These include:

• Clinical finding • Physical force • Procedure • Event • Observable entity • Environment or geographical location • Body structure • Social context • Organism • Situation with explicit context • Substance • Staging and scales • Pharmaceutical/biologic product • Physical object • Specimen • Qualifier value • Special concept • Record artifact • Linkage concept

These hierarchies are described further in the SNOMED CT User Guide. Three of them are of note here: the Qualifier value hierarchy, the Linkage concept hierarchy, and the Special concept hierarchy.

Qualifier value

The Qualifier value hierarchy contains some of the concepts used as values for SNOMED CT attributes that are not contained elsewhere in SNOMED CT. Such a code may be used as the value of an attribute in a defining Relationship in pre-coordinated definitions, and/or as the value of an attribute in a qualifier in a post-coordinated expression. However, the values for attributes are not limited to this hierarchy and are also found in hierarchies other than Qualifier value. For example, the value for the attribute LATERALITY in the concept shown below is taken from the Qualifier value hierarchy: • Left kidney structure (body structure) LATERALITY Left (qualifier value) However, the value for the attribute FINDING SITE in the concept shown below is taken from the Body structure hierarchy, not the Qualifier value hierarchy. • Pneumonia (disorder) FINDING SITE Lung structure (body structure) Examples of Qualifier value concepts: • Unilateral (qualifier value) • Left (qualifier value) • Puncture - action (qualifier value)

Special Concept

The Top Level Concept Code Special concept and its subclass codes provide a place for concept codes that are no longer active in the terminology. The subclasses of Special concept are: • Navigational concept • Inactive concept

Navigational concept These concept codes are to be used only as nodes in a Navigation Subset. They are not suitable for data recording or aggregation. The subclasses of Navigational concept have the following characteristics: • They have no IS A subclasses. • They have no IS A superclasses other than Navigational concept. • They may be associated with other concept codes by the use of Navigation Links (See Subset Mechanism on page 24.)

Inactive concept These concept codes are no longer current within SNOMED CT and should not be used for encoding data. There is one hierarchical level which consists of these subclasses: • Reason not stated • Duplicate • Outdated • Ambiguous • Erroneous • Limited / Classification • Moved Elsewhere

Each inactive concept code falls into one of these seven subclasses based upon its ConceptStatus value of 1, 2, 3, 4, 5, 6, or 10. There is no further subclassing of inactive concepts. Note that concept codes with a ConceptStatus value of 6 (Limited) were formerly considered active, but are now inactive and are included in the inactive hierarchy. This also means that the former confusing distinction between "active" and "current" no longer is required. "Active" and "current" now mean the same thing, and "inactive" and "non-current" also now mean the same thing.

Namespace concept These codes have integer-valued names that are the Extension namespace identifiers that have been assigned. (See Specification for Namespace within the SCTID on page 62 and SCTIDs and Extensions on page 122.)

Linkage concept

Linkage concept codes are intended to link two or more other codes to each other to express compositional meanings. All concept codes that can be used as a Relationship Type are included under Linkage concept. The ones approved for use are the Concept Model Attributes. Implementation guidance is as yet quite limited for the other Linkage concept codes. Use of them should be regarded as non-standard, tentative and experimental, requiring extra care. The Linkage concept hierarchy contains the sub-hierarchies: • Link assertion • Attribute

Link assertion The Link assertion sub-hierarchy enables the use of SNOMED CT concepts in HL7 statements that assert relationships between statements. Currently this content supports the UK NHS Connecting for Health requirements for encoding of Statement relationships for the implementation of HL7 Version 3 messaging in the UK realm. Examples of Link assertion concepts: • Has reason (link assertion) • Has explanation (link assertion)

Attribute Concepts that descend from this sub-hierarchy are used to construct relationships between two SNOMED CT concepts, since they indicate the relationship type between those concepts. Some attributes (relationship types) can be used to logically define a concept (defining attributes). This sub-hierarchy also includes non-defining attributes (like those used to track historical relationships between concepts) or attributes that may be useful to model concept definitions but which have not yet been used in modeling pre-coordinated concepts in SNOMED CT. Examples of Defining attributes: • IS A (attribute) • Concept model attribute (attribute): • Laterality (attribute) • Procedure site (attribute) • Finding site (attribute) • Associated morphology (attribute)

Examples of Non-defining attributes: • Concept history attribute (attribute)

• REPLACED BY (attribute) • SAME AS (attribute)

• Unapproved attribute (attribute) • Relieved by (attribute) • Has assessment (attribute)

Top Level Metadata Codes

Metadata codes represent structural information about the terminology itself. The Top Level Metadata Codes represent broad groups of metadata.

• Core metadata concept • Foundation metadata concept

Note: Originally, the Linkage concept and Namespace concept hierarchies were placed under SNOMED CT Concept. They remain there as of the January 2010 release of SNOMED CT, but they are fundamentally metadata and therefore will, in a future release, be placed in the metadata hierarchy.

Core metadata concept

These codes provide structural information for the so-called "core" tables, which include the concepts table, the descriptions table, and the relationships table.

Foundation metadata concept

These metadata codes provide structural information for other release structures (besides the core tables).

Appendix H

Cross Mappings Guide

Topics:

• Introduction • SNOMED CT to ICD-9-CM Epidemiological and Statistical Map • SNOMED to ICD-O Cross Mapping • SNOMED CT – LOINC® • Cross Mapping Rules • Applying rules to Cross Map Targets • Mapping Model

Introduction

® ® SNOMED Clinical Terms (SNOMED CT ) contains cross-mapping tables (perhaps more correctly referred to as cross-reference tables) from clinical concepts in SNOMED CT to categories listed in classifications such as ICD-9-CM. These classifications are used for data aggregation and analysis and are used by health care systems and services around the world. Effective and efficient use of these files requires an understanding of the rules, conventions and principles of the classification as well as SNOMED itself. This section describes the principles used in developing these cross mappings, the technical schema and a number of examples to communicate how the SNOMED cross mapping could be used to translate from SNOMED CT to target mapping(s). These cross mapping files are available for the following classifications:

Classification Version ICD-9-CM International Classification of Updated Version for 2007 Diseases 9th Revision Clinical Modification ICD-O International Classification of Version 2, Version 3 Diseases for Oncology Geneva, World Health Organization

The cross-mapping approach in SNOMED Clinical Terms is based on these general principles. • SNOMED CT concepts always retain their meaning. • SNOMED CT is a concept-based reference terminology where extensive scientific expertise has been utilized to provide a rich work of medical concepts along with their descriptions, synonyms, logical descriptors and relationships to other concepts. Therefore, in developing these mappings, SNOMED concepts have retained their meaning and not the meaning suggested by a classification.

• Automated mapping is a goal. • The cross mapping scheme is designed to support automated cross mapping (in future releases) by striving for one-to-one mappings when possible and by providing a technical schema that supports rule-based processing.

• Implementation Review of mappings is expected. • The mapping files are intended as tools to jumpstart SNOMED sites in cross mapping projects. It is expected that each site will review these files and implement cross mapping functions and values specific to their needs. • Some concepts may be part of a SNOMED extension file and can be ignored if that extension is not used. These concepts are designed with a 10 in the partition identifier component of the concept ID.

In this appendix, these terms are used with the following intended meaning. More extensive and authoritative definitions can be found in the SNOMED CT Glossary.

Term Meaning Concept A SNOMED CT clinical concept. Concepts Table One of the three SNOMED CT “core” tables that contains the SNOMED CT concepts. Cross Map The mapping from a single SNOMED CT concept to the Target Scheme.

Term Meaning Cross Maps Table One of the three SNOMED CT Cross Mapping tables. This table contains the identifier for the SNOMED CT concept and a link to another table that contains the relevant Target Codes. Target Scheme A terminology, coding scheme, or classification to which some or all SNOMED CT concepts are mapped; for example, ICD-9-CM is a Target Scheme. Target Code A value in the Target Scheme. The Cross Map relates a SNOMED CT concept to one or more Target Codes. Cross Maps Target Table One of the three SNOMED CT Cross Mapping tables. This table contains the Target Codes. Cross Mapping One of the mappings from SNOMED CT to another classification scheme (also known as Target Scheme); for example, SNOMED CT to ICD-9-CM is one Cross Mapping. Cross Map Set The collection of maps for a Target Scheme. Could also be called a Cross Mapping. Cross Map Sets Table One of the three SNOMED CT Cross Mapping tables. This table contains general information about each Cross Mapping (Cross Map Set), such as the name of the Target Scheme and the version that was used for the Cross Mapping.

Specification of cross-reference schema The SNOMED CT structure for supporting Cross Maps includes three tables specific to the cross map function. The structure of these tables provides tremendous flexibility to support the expression and delivery of several types of cross mappings. The technical structure of these tables is summarized elsewhere in the Technical Reference Guide.

Figure 8: Overview of Cross Map Schema

SNOMED CT to ICD-9-CM Epidemiological and Statistical Map

ICD-9-CM, the International Classification of Diseases 9th Revision Clinical Modification Version, is a coding scheme sponsored by the National Center for Health Statistics (NCHS). It is used extensively in the United States for reporting and tracking of mortality, statistical reporting of diseases as well as billing and reimbursement processing. The SNOMED CT to ICD-9-CM cross-map is updated to reflect the version of ICD-9-CM current as of the date of its release. It includes all the SNOMED CT Clinical Findings (disorders and findings). Note: It is important to note that this mapping table is NOT intended for direct billing or reimbursement without additional authoritative review.

Whenever possible, the ICD code or codes(s) with the highest level of specificity have been selected. Terms that cannot be assigned to appropriate ICD-9-CM code or codes are considered unmappable. They are denoted by a null in the Target Codes field and a zero in the MapAdvice field.

Mapping Categorization Methodology

The MapAdvice field in the Cross Maps table contains the categorization methodology that provides further information about the characteristics of the map. The methodology is as follows:

Category Description 0 Unmappable. SNOMED term cannot be assigned to an appropriate ICD-9-CM code. 1 One to one SNOMED to ICD map. The SNOMED and ICD correlates are identical or synonyms; or the SNOMED term is listed as an inclusion within the target ICD code description. • Many SNOMED concepts can map to the same ICD target code description. • More than one ICD code may be required to fully describe the SNOMED concept.

2 Narrow to Broad SNOMED to ICD map. The SNOMED source code is more specific than the ICD target code. 3 Broad to Narrow SNOMED to ICD map. The SNOMED code is less specific than the ICD target code. 4 Partial overlap between SNOMED and ICD. Overlap exists between correlates and additional patient information and rules are necessary to select an appropriate mapping.

SNOMED CT to ICD-9-CM Cross Mapping – Examples

The following examples show the details of how this mapping is delivered.

Sunburn of second degree This example involves one-to-one mapping from the SNOMED Clinical Terms concept Sunburn of Second Degree to the ICD-9-CM category represented by the code ‘692.76.’ This concept is active in the SNOMED CT Concepts Table.

Table 23: Concepts Table

ConceptID Concept Status FullySpecified CTV3ID SNOMEDID IsPrimitive Name 200834004 0 Sunburn of M1276 DD-10319 1 second degree (disorder)

The relevant classification is ICD-9-CM. MapSet Type = 2 means that it is a multiple map in which each unique SNOMED concept maps to either one target code or a set of target codes. The SNOMED concept is never duplicated in more than one row; that is, each concept has one and only one map. However, that map can contain more than one target code.

MapSetID MapSet MapSet MapSet SchemeId MapSet Scheme Name MapSet MapSet MapSet MapSet Name Type Scheme RealmId* Separator Rule Type* Version © 2002-2010 100046 ICD-9-CM 2 2.16.840.1.11 International 2006 | Map 3883.6.5.2.1 Classification of Diseases and Related

The Health Problems, 9th

International Revision, Clinical Modifications. Fields marked with an asterisk are not currently used in SNOMED CT. Health T erminology Standards Development Organisation Cross Mappings Guide | 149 150 | SNOMED CT Technical Reference Guide - January 2010

The Map TargetId field identifies the row in the Targets Table with the target codes for this SNOMED concept. The MapAdvice field contains a value of 1 as the categorization methodology, which, for this SNOMED to ICD-9-CM mapping, means a 1:1 mapping.

Table 25: Cross Maps Table (Maps Table)

MapSetId Map ConceptId Map Map Map Map Rule* Map Advice (taken from Option* Priority* TargetId Maps table above) 100046 200834004 0 0 1381051 1 Fields marked with an asterisk are not currently used in SNOMED CT.

The TargetCodes are an approximation of the closest ICD-9-CM codes or codes (692.76) that best represent the SNOMED concept.

Table 26: Cross Map Targets Table (Targets Table)

TargetId TargetSchemeId TargetCodes TargetRule* TargetAdvice* 1381051 2.16.840.1.11 692.76 3883.6.5.2.1 Fields marked with an asterisk are not currently used in SNOMED CT.

Pulmonary hypertension with extreme obesity This concept is active in the SNOMED CT Concepts Table.

Table 27: Concepts Table

ConceptID Concept Status FullySpecified CTV3ID SNOMEDID IsPrimitive Name 276792008 0 Pulmonary Xa0Cx D3-40324 1 hypertension with extreme obesity (disorder)

Note: The MapSet Separator field has a value of bar.

Table 28: Cross Maps Sets Table

MapSetID MapSet MapSet MapSet SchemeId MapSet MapSet MapSet MapSet MapSet Name Type Scheme Scheme RealmId* Separator Rule Name Version Type* 100046 ICD-9-CM 2 2.16.840.1.11 ICD-9-CM 2005 | Map 3883.6.5.2.1 Fields marked with an asterisk are not currently used in SNOMED CT.

The MapAdvice field contains a value of 2 as the categorization methodology, which means a narrow-to-broad mapping.

Table 29: Cross Maps Table (Maps Table)

MapSetId (taken from Map ConceptId Map Map Map Map Rule* Map Maps table above) Option* Priority* TargetId Advice 100046 276792008 0 0 329056 2 Fields marked with an asterisk are not currently used in SNOMED CT.

The TargetCodes field contains approximation of the closest ICD-9-CM codes or codes (416.8, 278.00) that best represent the concept. Note that the values are separated by a bar ( | ), as specified in the MapSet Separator field in the Cross Maps Set Table.

Table 30: Cross Map Targets Table (Targets Table)

TargetId TargetSchemeId TargetCodes TargetRule* TargetAdvice* 329056 2.16.840.1.11 3883.6.5.2.1 278.00|416.8 Fields marked with an asterisk are not currently used in SNOMED CT.

SNOMED to ICD-O Cross Mapping

The International Classification of Diseases for Oncology (ICD-O) is sponsored by the World Health Organization and is used for reporting the topography, morphology and behavior of neoplasms. It is widely used by cancer registries in the United States and abroad for reporting of cancer cases. The SNOMED CT to ICD-O Topography map consists of a one-to-one mapping from concepts in the SNOMED Body Structure hierarchy to the topography concepts in ICD for Oncology (ICDO-2 and ICD-O-3). Cancer registries receiving SNOMED CT-encoded information from health care providers, especially anatomical pathology laboratories, will find this translation helpful. The two most important items of medical information for a cancer patient are the primary site of the tumor and morphologic or histological type of the tumor as diagnosed microscopically by a pathologist. Reportable cancer cases can be identified by SNOMED CT codes describing tumor morphology and behavior – codes that represent reportable neoplasms. The ICD-O morphology codes are drawn from SNOMED CT. These codes are in the SNOMEDID field of the Concepts Table in the M8 and M9 series. Topography codes are also needed by cancer registries to identify the site of the tumor. The topography terms of SNOMED CT are more extensive and are not identical to the topography section of ICD-O. SNOMED CT includes codes not found in ICD-O; for example, SNOMED CT has specific codes for paired anatomic structures for laterality such as left breast while ICD-O does not. In addition, SNOMED includes terms expressed more specifically than in ICD-O such as “subcutaneous and other Soft tissues of lower limb and hip” in ICD-O. And finally, SNOMED CT includes more terms than those needed to identify cancer sites; for example, “nail” is unmappable to ICD-O because the nail is not a site for neoplastic disease. The mapping from ICD-O to SNOMED was a collaborative effort between the College of American Pathologists (CAP), the Centers for Disease Control and Prevention (CDC) and the National Cancer Institute (NCI). The IHTSDO would like to acknowledge and offer special thanks to Daniel S. Miller, MD, MPH, former head of the Division of Cancer Prevention and Control, CDC and Mary L. Lerchen, DrPH, MS, Public Health Practice Program Office, CDC who initiated this effort on behalf of cancer registries.

SNOMED CT to ICD-O Cross Mapping – Example

The following example shows how this mapping is delivered.

Gastric fundus structure This example involves SNOMED Clinical Terms concept Gastric fundus structure to the ICD-O classification represented by the code “C16.1” . This concept is active in the SNOMED CT Concept Table.

Table 31: ConceptsTable

ConceptId ConceptStatus FullySpecified CTV3ID SNOMEDID Is Primitive Name 414003 0 Gastric fundus X7551 T-57400 1 structure (body structure)

The relevant classification is ICD-O. MapSet Type = 1 means that all maps are one-to-one mappings. The SNOMED concept is never duplicated in more than one row; that is, each concept has one and only one map.

Table 32: Cross Map Sets Table

Map Map Set Map Set MapSet MapSetS cheme Map Set Map Set Map Set Map Set SetId Name Type SchemeId Name Scheme RealmId* Separator Rule Version Type* 102041 ICD-O-3 1 2.16.840.1.1 International 2001 | 13883.6.5.2.2 Classification of Diseases for Oncology, 3rd Edition Fields marked with an asterisk are not currently used in SNOMED CT.

Table 33: Cross Maps Table

MapSetId MapConceptId MapOption* MapPriority* MapTargetId MapRule* MapAdvice 102041 414003 0 1 2977055 Fields marked with an asterisk are not currently used in SNOMED CT.

The TargetCodes are an approximation of the closest ICD-O codes or codes (C16.1) that best represent the SNOMED concept.

Table 34: Cross Map Target Table

TargetId TargetSchemeId TargetCodes TargetRule* TargetAdvice* 2977055 2.16.840.1.11 3883.6.5.2.2 C16.1 Fields marked with an asterisk are not currently used in SNOMED CT.

SNOMED CT – LOINC®

Please see SNOMED CT - LOINC® Integration Table on page 104 for details about SNOMED CT – LOINC integration.

Cross Mapping Rules

Please contact the IHTSDO before using these specifications. Recent work has been done on planning for rules-based maps to ICD-9-CM and ICD-10, which may result in a substantial revision of this section.

Introduction

The discussion of rules is included although rules are not yet used in the released SNOMED CT Cross Maps. However, this feature may be of interest to implementers. The objective of the MapRule fields is to allow addition of machine-processable instructions that then allow automated cross mappings even in cases where there is more than one way to map a particular SNOMED CT Concept. For Concepts with several alternative Cross Maps, the rules contained in each Cross Map should be checked to determine which is most appropriate in the context of a particular patient record. This section provides an initial syntax of mapping rules and discussion of some possible variants.

Nature of the Rules

The types of rules required may vary according to the nature of the Target Scheme. However, the following general types of rule can be recognized in several different types of mapping: • Age or sex of the person to whom the Concept is applied. • Qualifiers associated with the mapped Concept. • Temporal attributes of the mapped Concept. • Coexisting conditions • Including pathological conditions and other conditions (e.g. pregnancy)

• Related statements: • Procedure applied to particular condition. • Condition treated by particular procedure. • Condition arising as a result of particular procedure. • Other statements of causation (e.g. condition caused by accident).

Representation

Each type of rule can be expressed as a function with parameters which when evaluated returns a true or false result (similar to the NHS Casemix grouper tools). Alternatively the rules could be expressed as SQL style queries against an agreed common core data model (similar to the NHS MIQUEST Health Query Language). In either case, the end result is a decision that either accepts or rejects a particular mapping. Whichever form of representation is used the Extensible Markup Language (XML) is suggested as a general-purpose syntax because it support flexible expressions and facilitates parsing. Thus the content of the MapRule is an XML string that contains one or more elements. According to the form of expression each element may represent either a function with parameters or query predicate.

Processing order

Introduction When determining which of a set of cross map options is to be used for mapping a particular Concept a further consideration is the order in which the rules are tested. The following example is used to illustrate each of the options: Concept “A” can be mapped to one or more of the five possible cross map codes (“V”,“W”,“X”,“Y”,“Z”) • “V” applies if the patient does not have co-existing condition “B” or “C”. • “W” applies if the patient is under aged 60 and has co-existing condition “B” • “X” applies if the patient is aged 60 or over and has co-existing condition “B” • “Y” applies if the patient is under aged 60 and has co-existing condition “C” • “Z” applies if the patient is aged 60 or over and has co-existing condition “C” In addition to the five single target code options, there are two possible combinations • “W,Y”and“X,Z” indicating the presence of co-existing conditions “B”and“C” in either age group.

Order Implementation processing To allow order independent processing of Cross Maps, the rules associated with all options for mapping a Concept must be complete and mutually exclusive. For every possible occurrence of a Concept only one Cross Map must have a mapping rule that evaluates as true. If this approach is followed, there is no opportunity to optimize the order of processing and no easy way to provide a catch-all default option to be applied if all other rules fail. Several Cross Maps may include the same function or predicate as part of their rules and this may require complex evaluations to be performed more than once. Example:

Concept Option Rule TargetId TargetCodes “A” 1 NOT Coexists “B” AND NOT Coexists “C” 101050 V “A” 2 Age < 60 AND Coexists “B” AND NOT 102056 W Coexists “C” “A” 3 Age >= 60 AND Coexists “B” AND NOT 103053 X Coexists “C” “A” 4 Age < 60 AND NOT Coexists “B” AND 104055 Y Coexists “C” “A” 5 Age >= 60 AND NOT Coexists “B” AND 105059 Z Coexists “C” “A” 6 Age < 60 AND Coexists “B” AND Coexists “C” 106058 W, Y “A” 7 Age >= 60 AND Coexists “B” AND Coexists 107054 X, Z “C”

Sequential Processing The sequential approach tests the rules of each Cross Map in a stated order until a rule is found to be true. When a true rule is identified the associated Cross Map Target is used.

One advantage of this approach is that some optimization can occur to limit the number of times that the same function or predicate is tested. A catch-all default Cross Map can be included as the last option in the sequence with a rule which always evaluates as true. The disadvantage of this approach is that the order is significant. Therefore, whenever an alternative Cross Map is added the existing Cross Maps for that Concept must be revised and reordered in a way that achieves the intended results. Example

Concept Option Rule TargetId TargetCodes “A” 1 Age < 60 AND Coexists “B” AND Coexists “C” 106058 W, Y “A” 2 Age >= 60 AND Coexists “B” AND Coexists 107054 X, Z “C” “A” 3 Age < 60 AND Coexists “B” 102056 W “A” 4 Age >= 60 AND Coexists “B” 103053 X “A” 5 Age < 60 AND Coexists “C” 104055 Y “A” 6 Age >= 60 AND Coexists “C” 105059 Z “A” 7 TRUE 101050 V

Branching Model The branching approach tests each element of a rule separately and if any test fails it provides a specified reference to the next Cross Map to be tested. If all the tests are true the associated Cross Map Target is used. If any test fails the specified option is tested next. If this approach is followed significant optimization can occur so that any test is only performed once for each Concept mapped. However, one disadvantage is that addition, removal or revision of any Cross Map requires a review of the entire set of Cross Maps for that Concept. Another disadvantage is that branching logic is less transparent than sequential testing. There are greater risks of logical errors requiring debugging of different test cases. Example

Concept Option MapRule TargetId TargetCodes “A” 1 Age < 60 (ELSE 4) AND Coexists “B” (ELSE 106058 W, Y 3) AND Coexists “C” (ELSE 2) “A” 2 TRUE 102056 W “A” 3 Coexists “C” (ELSE 7) 104055 Y “A” 4 Coexists “B” (ELSE 6) AND Coexists “C” 107054 X, Z (ELSE 5) “A” 5 TRUE 103053 X “A” 6 Coexists “C” (ELSE 7) 105059 Z “A” 7 TRUE 101050 V

Applying rules to Cross Map Targets

The proposed structures allow rules to be associated with Cross Map Targets instead of Cross Maps. A Cross Map Target may be the target of several Cross Maps. If there are no rules in a Cross Map any rules in the referenced Cross Map Target are tested. This approach allows a more consistent representation of the rules that relate to generating a particular mapping. However, since each Cross Map Target is a stand-alone component that may be referenced by Cross Maps associated with several different Concepts the rules must be complete and order independent. The decision on whether to apply the rules to the Cross Maps or the Cross Map Targets depends on the nature of the mapping of SNOMED CT. In cases where there is a clear-cut set of primary Concepts from which mappings are to be generated, it is preferable to reflect this with rules in the Cross Maps for those Concepts. In less clearly defined cases, it may be better to express the rules in the Cross Map Target. Example Extending the illustration in the previous section, Cross Maps from Concept “B” could reference some of the same Cross Map Targets as Concept “A”. However, in the case of the map from Concept “B” the co-existence of condition “A” must be tested rather than “B”. Concept “B” could be mapped to: • “W” if the patient is under aged 60 and has co-existing condition “A” but not “C” • “X” if the patient is aged 60 or over and has co-existing condition “A” but not “C” • "W, Y" if the patient is under aged 60 and has co-existing conditions “A”and“C” • "X, Z" if the patient is aged 60 or over and has co-existing conditions “A”and“C” • An additional Target Code “S” if neither of the conditions “A”or“C” is present. Using the sequential approach the Cross Maps for Concept “B” would be as follows:

Concept Option Rule TargetId TargetCodes “B” 1 Age < 60 AND Coexists “A” AND Coexists “C” 106058 W, Y “B” 2 Age >= 60 AND Coexists “A” AND Coexists 107054 X, Z “C” “B” 3 Age < 60 AND Coexists “A” 102056 W “B” 4 Age >= 60 AND Coexists “A” 103053 X “B” 5 TRUE 108057 S

Note: The first four rows Cross Maps refer to the same four Cross Map Targets that were used in the mapping from Concept “A”. However the rules differ because these are Cross Maps from Concept “B” rather than from Concept “A”. If rules are to be stated for these Cross Map Targets, these must be made complete and order independent so that they are not dependent on the Concept that initiated the mapping.

TargetId TargetCodes TargetRule 101050 V Coexists “A” AND NOT Coexists “B” AND NOT Coexists “C” 102056 W Age < 60 AND Coexists “A” AND Coexists “B” AND NOT Coexists “C”

TargetId TargetCodes TargetRule 103053 X Age >= 60 AND Coexists “A” AND Coexists “B” AND NOT Coexists “C” 104055 Y Age < 60 AND Coexists “A” AND NOT Coexists “B” AND Coexists “C” 105059 Z Age >= 60 AND Coexists “A” AND NOT Coexists “B” AND Coexists “C” 106058 W, Y Age < 60 AND Coexists “A” AND Coexists “B” AND Coexists “C” 107054 X, Z Age >= 60 AND Coexists “A” AND Coexists “B” AND Coexists “C” 108057 S Coexists “B” AND NOT Coexists “A” AND NOT Coexists “C”

Mapping Model

Figure 9: A logical model of the cross mapping process on page 158 is a general model of the mapping process that pulls together the table structure, patient record, and possible rules processing. The classes Concept, Cross Map Set, Cross Map, and Cross Map Target are equivalent to the tables of the same name described earlier in this section. The other classes are shown to illustrate the more detailed aspects of mapping.

1. A record may contain many record complexes. 2. A record complex may contain many statements. 3. A statement may contain a coded or uncoded qualifier. 4. A statement contains a primary concept. 5. Primary and qualifying concepts are specialised uses of Concepts. 6. A Concept may have any number of Cross Maps representing either: • mappings to different Target schemes or • alternative mappings in the same Target Scheme. Cross Maps associated with different Target Schemes are distinguished by membership of a particular Cross Map Set. Alternative Cross Maps associated with the same Target Scheme are distinguished by examination of other information in the Patient Record either manually or using mapping rules. 7. A Cross Map Target may contain rules that fully define it in terms of various tests to be applied to a patient record or specified record complex. 8. Each Cross Map may contain rules which determine its applicability based on other information in the Patient Record. This may include testing the qualifiers applied to the mapped Concept, examining other statements in the record including those with specific contextual or temporal relationships to the mapped concept. 9. A Cross Map Set contains all the Cross Maps for a particular Target Scheme. 10. A cross map refers to one Cross Map Target. Any number of Cross Maps may refer to the same Cross Map Target.

11. A Cross Map Target contains a set of one or more codes in the Target Scheme. Figure 9: A logical model of the cross mapping process

Simple one-to-one mapping

One-to-one mapping between a selected SNOMED CT Concept and single Target Code is possible in some cases. This is represented by a single Cross Map, which is associated with the Concept and is a member of the Cross Map Set associated with that Target Scheme. The Cross Map refers to a Cross Map Target that contains only one Target Code.

Simple one-to-many mapping

One-to-many mapping between a selected SNOMED CT Concept and set of more than one Target Codes is required for Target Schemes that use combinations of codes to express the same meaning as a single SNOMED CT Concept. This is represented by a single Cross Map, which is associated with the Concept and is a member of the Cross Map Set associated with that Target Scheme. The Cross Map refers to a Cross Map Target that contains two or more Target Codes.

Mapping with options

Mapping with options is required where there are several possible ways of mapping a Concept into the Target Scheme. Multiple options may occur in two circumstances: • The Target Scheme provides more detailed representation than is offered by the SNOMED CT Concept. This may occur with SNOMED CT Concepts that are mappable if qualified in some way. • If the qualification required is an associated qualifying Concept or an associated numeric value then automated mapping is feasible. • If the qualification is provided as free text then manual intervention will be required but may be assisted by providing appropriate advice.

• The Target Scheme encodes the Concept in a manner that includes other related information about the patient. Examples of this include: • Classifications that subdivide disorders by age, sex or other patient characteristics. • Groupers that encode combinations of procedures and disorders. • Use of patient record context or links between statements to indicate suspected causation or other clinically significant relationships.

These requirements are represented by multiple Cross Maps associated with a single Concept with the Cross Map Set associated with the Target Scheme. • The Concept for which Cross Maps are sought is the primary Concept of a selected Statement in the patient record. • Where multiple maps are found, the rules in these Cross Maps are processed to determine which of the maps is appropriate. These rules may refer to: • Qualifications of the selected Statement • Other Statements (including relevant qualifications) that are: • Explicitly related to the selected Statement (e.g. a treatment specifically undertaken for a particular condition)

• In the same complex as the selected Statement (e.g. another diagnosis during the same episode or admission) • Temporally related to the selected Statement (e.g. indicating that a patient was pregnant at the time that hypertension was diagnosed) • Previous occurrences of the same condition or procedure described in the selected Statement. • Related only in being part of the same patient record.

• Other information in the patient record • For example age, sex, occupation, etc.

Appendix I

Supplementary Text Descriptions

Topics: The following table provides supplementary text descriptions for several hundred SNOMED CT concepts. Although many concepts might benefit • Supplementary Text Descriptions from such descriptions, especially primitive concepts, this table contains Table descriptions available to date. These text descriptions can help resolve ambiguities or uncertainties about the meaning of a concept beyond what is provided by the Fully Specified Name, Preferred Term, and semantic definitions.

Supplementary Text Descriptions Table

For the current version of this table, please refer to the tab-delimited text file in the “Documentation” folder of the SNOMED CT International Release.

CONCEPTID SNOMEDID FULLY SPECIFIED NAME DEFINITION 52250000 A-81050 X-ray electromagnetic Electromagnetic radiation of wavelength radiation (physical force) between approximately 001 nm and 10 nm 56242006 A-81070 Light, electromagnetic Electromagnetic radiation in the visible range radiation (physical force) as well as parts of the ultraviolet and infrared ranges 75184002 A-81072 Visible light, electromagnetic Electromagnetic radiation in the visible range radiation (physical force) 55080005 A-81112 Electromagnetic radiation from Electromagnetic radiation from a RAdio radar device (physical force) Detection and Ranging device 55566008 A-A1000 Accidental physical contact Accidental physical contact or exposure with (event) potential or actual harmful effect 80917008 C-00224 Toxin (substance) Toxic, noxious, or poisonous substance that is produced by a living organism 128489003 C-200A0 Sand (substance) Fine granular particles of rock or similar material 119413000 C-20554 Mineral spirits (substance) Hydrocarbon solvents with flash points above 38 degrees C 56703005 C-21012 Amyl alcohol - commercial An alcohol obtained from refinement of fusel (substance) oil; contains mainly isopentyl alcohol and 2-methyl-1-butanol 88427007 C-21612 Methyl acetylene (substance) Colorless gas with a sweet odor, used as fuel and shipped as compressed gas 62975006 C-21613 Methyl acetylene-propadiene A colorless gas with a characteristic foul odor, mixture (substance) used as a fuel and shipped as a liquefied compressed gas 31716004 C-A6032 Frozen plasma product, Category of human frozen plasma products, human (product) regardless of time from donation to freezing 95323007 D0-00044 Scleredema (disorder) Hard non pitting edema and induration of the skin; a finding associated with Buschke's disease 410016009 D0-005A3 Lipodermatosclerosis A decrease in lower leg circumference due to (disorder) recurrent ulceration and fat necrosis causing loss of subcutaneous tissue in a patient with venous stasis disease 367522007 D0-01036 Dermatitis infectiosa Inflammation of skin adjacent to an infectious eczematoides (disorder) site by autoinnoculation; appears as eczematous plaque with or without vesicles 128045006 D0-01302 Cellulitis (disorder) Inflammation that may involve the skin and or subcutaneous tissues, and or muscle

CONCEPTID SNOMEDID FULLY SPECIFIED NAME DEFINITION 402567004 D0-1015C Vesicular eczema of hands Self-limited vesicular eruption of palms and and/or feet (disorder) soles 58759008 D0-22020 Intertrigo (disorder) Superficial dermatitis on opposed skin surfaces 95333004 D0-22138 Eosinophilic pustular folliculitis A dermatosis with pruritic sterile papules and (disorder) pustules that come together to form plaques with papulovesicular borders, and a tendency toward central clearing and hyperpigmentation, with spontaneous exacerbations and remissions. Histologically variable with folliculitis of follicle sheath and perifollicular dermis and spongiosis of follicular epithelium, sometimes with peripheral leukocytosis and or eosinophilia and or eosinophilic abscesses. 7119001 D0-23010 Cutaneous lupus Disease of skin in someone with Lupus erythematosus (disorder) erythematosis, though not necessarily systemic or subacute 95336007 D0-40051 Localized Recurrent ulceration and fat necrosis, lipodermatosclerosis associated with loss of subcutaneous tissue (disorder) and a decrease in lower leg circumference 110986000 D0-53824 Acquired digital fibrokeratoma A keratotic cutaneous polyp containing (disorder) abundant connective tissue 22649008 D0-75240 Photodermatitis (disorder) Dermatitis caused by exposure to sunlight 21143006 D0-75310 Calcaneal petechiae Traumatic hemorrhage into heel that persists (disorder) as black dots 80406003 D1-22350 Pathological dislocation of Dislocation of joint caused by presence of joint (disorder) another disease 23680005 D1-30000 Enthesopathy (disorder) Disorder occurring at the site of insertion of tendons or ligaments into bones or joint capsules 109361004 D2-01280 Surgical ciliated cyst A cyst composed of maxillary sinus epithelium (disorder) along a surgical line of entry 1648002 D2-61424 Lymphocytic pseudotumor of Tumor-like mass in lungs composed of fibrous lung (disorder) tissue or granulation tissue with inflammatory cells 33622007 D3-16200 Round heart disease A spontaneous cardiomyopathy of unknown (disorder) etiology that affects healthy poultry 44808001 D3-30000 Conduction disorder of the Abnormality in rhythm of heartbeat, including heart (disorder) rate, regularity, and/or sequence of activation abnormalities 413577001 D3-80064 Arterial thoracic outlet Thoracic outlet syndrome, either nerve or syndrome due to cervical rib vessel compression, due to a cervical rib (disorder)

CONCEPTID SNOMEDID FULLY SPECIFIED NAME DEFINITION 95442007 D3-80506 Peripheral cyanosis (disorder) Disorder characterized by slowing of blood flow to a body region in association with an increase in oxygen extraction from normally saturated arterial blood 128065004 D4-38016 Congenital partial Congenital portal-systemic shunt in which at portal-systemic shunt least some portal blood perfuses the liver (disorder) 111029001 D4-40131 Acrokerato-elastoidosis A developmental disorder characterized by (disorder) keratotic papules of skin of hands and soles with disorganization of dermal elastic fibers that does not appear to be due to trauma or sunlight 111030006 D4-40139 Howel-Evans' syndrome A form of diffuse palmoplantar keratoderma (disorder) that occurs between the ages of 5 and 15 and may be associated with the subsequent development of esophageal cancer 109478007 D4-51098 Kohlschutter's syndrome Ameliogenesis imperfecta, mental retardation, (disorder) and epileptic seizures 128533009 D4-A0655 Micropapilla (disorder) Congenital small optic disc with normal visual function 93040009 D4-A0806 Congenital blepharophimosis A decrease in size of opening of the eye, not (disorder) due to eyelid fusion, but rather lateral displacement of the inner canthi 94684003 D4-A0824 Microblepharia (disorder) Congenital abnormal vertical shortness of eyelids 75076004 D4-F1137 Amyelencephalus (disorder) Congenital absence of the spinal cord and brain 109750005 D5-15106 Abfraction (disorder) Noncarious lesion, where tooth is fatigued, flexed, and deformed by biomechanical loading of the tooth structure, primarily at the cervical region. These are usually wedge-shaped lesions with sharp-line angles, but sometimes are circular invaginations on occlusal surfaces. 109778006 D5-21244 Bednar's aphthae (disorder) Symmetric excoriation of the hard palate often due to sucking in infants 109788007 D5-21613 Peripheral ossifying fibroma A fibroma of the gums with calcification and of gingivae (disorder) possibly ossification 15270002 D5-42004 Obturation obstruction of Complete obstruction of the intestine due to intestine (disorder) the presence in the lumen of blocking material, such as tumor, fecalith, gallstone, or foreign body 31201001 D5-45211 Knight's disease (disorder) Infection of perianal region of skin following abrasion, which is named for the occurrence in horsemen 109817001 D5-60862 Intersigmoid hernia (disorder) Hernia of part of the intestinal tract through the intersigmoid recess or fossa

CONCEPTID SNOMEDID FULLY SPECIFIED NAME DEFINITION 95564001 D5-90416 Pancreatemphraxis (disorder) Obstruction of the pancreatic duct leading to swelling of the pancreas as a whole 6595006 D6-34730 Calcinosis (disorder) Structure with calcium deposition 84757009 DA-30000 Epilepsy (disorder) A disorder characterized by recurrent seizures 84299009 DA-40020 Neuritis (disorder) Inflammation of a peripheral and/or cranial nerve 78141002 DA-42100 Erb-Duchenne paralysis A disorder of the superior trunk of the brachial (disorder) plexus or the fifth and sixth cervical spinal nerves or motor roots, resulting in weakness of proximal upper extremity musculature innervated by these nerve roots 76440000 DA-48100 Equine grass sickness Autonomic dysfunction of unknown etiology (disorder) in horses, with gut paralysis as primary manifestation 12371008 DA-70170 Ophthalmia nodosa (disorder) A granulomatous, inflammatory disorder of the eye; reaction to vegetable or insect hairs 95692001 DA-71725 Lipidemia retinalis (disorder) An abnormal milky appearance of arteries and veins of retina, for example due to lipids in blood greater than 5%, diabetes mellitus, or leukemia 95712005 DA-72546 Entropion uveae (disorder) Eversion of the margin of the pupil 53889007 DA-73540 Nuclear cataract (disorder) A cataract involving the nucleus of the lens 44248001 DA-78238 Raymond-Cestan syndrome Abducent nerve paralysis with contralateral (disorder) hemiparesis 95837007 DC-10190 Central cyanosis (disorder) A form of cyanosis that occurs when there is a decrease in oxygen saturation in the arterial blood, usually with an SaO2 of below 75% 127062003 DC-38001 Erythrocytosis (disorder) Peripheral blood red cell count above the normal range 64779008 DC-60000 Blood coagulation disorder Disorders involving the elements of blood (disorder) coagulation, including platelets, coagulation factors and inhibitors, and the fibrinolytic system 86075001 DC-63000 Coagulation factor deficiency Includes both quantitative and qualitative syndrome (disorder) disorders of procoagulants 128105004 DC-64101 Von Willebrand disorder Includes true von Willebrand disease with (disorder) mutation at the VWF locus, as well as mimicking disorders with other mutations (pseudo VWD) and acquired von Willebrand syndrome 128115005 DC-64211 Pseudo von Willebrand Any inherited disorder mimicking von disease (disorder) Willebrand disease but lacking mutation at the VWF locus 61653009 DD-12432 Bennett's fracture (disorder) Fracture and dislocation of the first metacarpal and the carpal-metacarpal joint

CONCEPTID SNOMEDID FULLY SPECIFIED NAME DEFINITION 123976001 DE-00004 Post-infectious disorder A disorder that follows infection but is distinct (disorder) from the infection itself and its usual manifestations 19168005 DE-01200 Nosocomial infectious disease Infection associated with hospitalization, not (disorder) present or incubating prior to admission, but generally occurring more than 72 hours after admission 127326005 DF-000D3 Non-human disorder Disorders which occur in animals but not in (disorder) man 127346000 DF-000F9 Neurologic disorder of eye Disorders characterized by eye movement movements (disorder) abnormalities that are the result of brain, cranial nerve, or neuromuscular junction dysfunction 417163006 DF-00776 Traumatic AND/OR Disorder resulting from physical damage to non-traumatic injury (disorder) the body 417746004 DF-00777 Traumatic injury (disorder) Disorder resulting from physical damage to the body 128207002 DF-00833 Giant axonal neuropathy An autosomal recessive condition (disorder) characterized by progressive degeneration of the central and peripheral nervous system with enlargement of axons 62014003 DF-10010 Adverse reaction to drug All noxious and unintended responses to a (disorder) medicinal product related to any dose should be considered adverse drug reactions (from US FDA "Guideline for Industry, Clinical Safety Data Management: Definitions and Standards for Expedited Reporting"). 30623001 F-16340 Catch (finding) A sudden pain, usually sharp, occurring during movement, or exacerbated by movement, and prompting cessation of movement 78064003 F-20000 Respiratory function Any function involved in the exchange of (observable entity) oxygen and carbon dioxide between the atmosphere and the cells of the body 77329001 F-20160 Mouth breathing (finding) Habitual breathing through the mouth, usually associated with obstruction of nasal passages 3791008 F-20370 Bohr effect, function Right shift of the hemoglobin oxygen (observable entity) dissociation curve due to lower pH with increased carbon dioxide 11421009 F-23550 Fremitus (finding) Vibration felt on the chest wall, either by examiner or subjective 119251002 F-24432 Reverse sneezing (finding) An inhalation reflex stimulated by an irritation of the mucous membrane of the nose 76777009 F-25170 Artificial respiration by Procedure that applies electrical stimulation electrophrenic stimulation to the phrenic nerve to achieve ventilation (procedure)

CONCEPTID SNOMEDID FULLY SPECIFIED NAME DEFINITION 24184005 F-31003 Finding of increased blood A finding of increased blood pressure; not pressure (finding) necessarily hypertensive disorder 12763006 F-31004 Finding of decreased blood A finding of decreased blood pressure; not pressure (finding) necessarily hypotensive disorder 85595005 F-31730 Abdominal aortic pulse, Pulse felt over the abdominal aorta function (observable entity) 61086009 F-31760 Pulse irregular (finding) A pulse with repeated irregularity 74478000 F-32320 Detection of cardiac shunt Anomalous flow of blood between different (finding) parts of the circulation 67551009 F-35072 Abnormal third heart sound, Any abnormality of the third heart sound S>3< (finding) 86484008 F-35142 Abnormal fourth heart sound, Any abnormality of the fourth heart sound S>4< (finding) 32615007 F-35736 Austin Flint murmur (finding) A mid-to-late diastolic murmur heard best at the cardiac apex, heard in cases of aortic insufficiency 19384000 F-35738 Graham Steell murmur High-pitched diastolic murmur heard best at (finding) left sternal border, associated with pulmonary valve insufficiency 1735007 F-35760 Thrill (finding) Vibration felt by examiner on the surface of the body 4592006 F-35820 Fourth sound gallop (finding) A "galloping" sound on cardiac auscultation because of an abnormally audible fourth heart sound 49864004 F-35830 Protodiastolic gallop with A "galloping" sound on cardiac auscultation abnormally audible third heart because of an abnormally audible third heart sound (finding) sound 42842009 F-35854 Plateau cardiac murmur Cardiac murmur with no significant crescendo (finding) or decrescendo 40015002 F-54170 Flatus, function (observable Passage of gas by anus entity) 119248009 F-62023 Hyperalbuminemia (disorder) Increased serum albumin concentration 119247004 F-62024 Hypoalbuminemia (disorder) Reduced serum albumin concentration 102704008 F-63007 Short chain fatty acid Fatty acid with fewer than 10 carbon atoms (substance) 102705009 F-63008 Medium chain fatty acid Fatty acid with 10 to 14 carbon atoms (substance) 102706005 F-63009 Long chain fatty acid Fatty acid with 10 or more carbon atoms (substance) 1677001 F-8A080 Haagensen test (procedure) Breast examination for malignancy in which patient leans forward and breasts are examined for abnormal contour 91454002 F-A7923 Pleocytosis of cerebrospinal Presence of greater than normal number of fluid (finding) cells in the cerebrospinal fluid

CONCEPTID SNOMEDID FULLY SPECIFIED NAME DEFINITION 17374005 F-A8870 Queckenstedt's test Measurement of CSF pressure following (procedure) compression of jugular vein 119249001 F-C0710 Agammaglobulinemia (finding) Absence of the gamma fraction of serum globulin 119250001 F-C0720 Hypogammaglobulinemia Decreased concentration of the gamma (finding) fraction of serum globulin 106190000 F-C30F9 Allergic state (disorder) Known to have allergic reactions to particular substance(s) 70730006 F-D0110 Ineffective erythropoiesis Increased destruction of erythrocyte (finding) precursors 50857004 F-D7300 Tissue factor (substance) Tissue factor, the high-affinity receptor and cofactor for the plasma serine protease VII/VIIa 20364005 F-F5002 Paracusis (disorder) Altered sense of hearing, other than simple decreased hearing or deafness 184034005 F-F5074 Auditory area (sound intensity) Range of sound intensity between the (observable entity) minimum audible intensity and the auditory pain threshold 399264008 G-0373 Image mode (observable Image mode refers to the type of image entity) acquisition (modality). For example, most ultrasound systems use 2D, Color Flow, M Mode and Doppler modes. 399030000 G-0374 Left ventricular systolic area Area measurement of the left ventricle in (observable entity) systole. 399109006 G-0375 Left ventricular diastolic area Area measurement of the left ventricle in (observable entity) diastole. 399287000 G-0376 Left ventricular area fractional (Diastolic Area - Systolic Area) / Diastolic Area change (observable entity) 399063007 G-0377 Left ventricular semi-major Semi-major axis is the dimension from the axis diastolic dimension widest minor axis to the apex of the left (observable entity) ventricle at end diastole. 399309003 G-0378 Left ventricular truncated Truncated semi-major axis is from widest short semi-major axis diastolic axis diameter to the mitral annulus plane in dimension (observable entity) the left ventricle at diastole. 399293008 G-0379 Left ventricular epicardial Epicardial area of the left ventricle, cross diastolic area, psax pap view section [parasternal short axis view] at the (observable entity) level of the papillary muscles in diastole. 399133000 G-037A Left ventricular peak early Myocardial tissue velocity by Pulsed Wave diastolic tissue velocity Doppler, typically adjacent to the mitral (observable entity) annulus, measured in early diastole. 399140004 G-037B Ratio of mitral valve peak Transmitral velocity measured at the leaflet velocity to left ventricular peak tips at the onset of diastole divided by the tissue velocity e-wave myocardial velocity measured at the same (observable entity) point in the cardiac cycle. Correlates with left ventricular filling pressure.

CONCEPTID SNOMEDID FULLY SPECIFIED NAME DEFINITION 399007006 G-037C Left ventricular peak diastolic Myocardial tissue velocity by Pulsed Wave tissue velocity during atrial Doppler, typically adjacent to the mitral systole (observable entity) annulus, measured at the time of left atrial contraction. 399167005 G-037D Left ventricular peak systolic Myocardial tissue velocity by Pulsed Wave tissue velocity (observable Doppler, typically adjacent to the mitral entity) annulus, measured during left ventricular systole. 399051002 G-037E Left ventricular isovolumic The time interval from mitral valve closure to contraction time (observable aortic valve opening. Measured as the interval entity) between the mitral valve closing click and the aortic valve opening click on Continuous Wave Doppler. 399266005 G-037F Left ventricular index of (MCO-ET(Left Ventricle OT))/ET(Left Ventricle myocardium performance OT), where MCO is MV Closure to Opening (observable entity) time and ET is Ejection Time. 399023006 G-0380 Right ventricular peak systolic Right ventricular systolic pressure calculated pressure (observable entity) from the peak right ventricular-right atrial systolic gradient (from the peak tricuspid regurgitation velocity using the modified Bernoulli equation) plus estimated right atrial/central venous pressure. 399154007 G-0381 Right ventricular index of (TCO-ET(RVOT))/ET(RVOT), where TCO is myocardial performance TV Closure to Opening time and ET is Ejection (observable entity) Time. 399058008 G-0382 Ratio of aortic valve Ratio of Aortic Valve Acceleration Time to acceleration time to aortic Aortic Valve Ejection Time valve ejection time (observable entity) 399235004 G-0383 Left atrium systolic volume Volume of blood contained in the left atrium (observable entity) at end-systole. 399354002 G-0384 Mitral valve E-wave The time interval from the peak of the deceleration time (observable transmitral Doppler early filling velocity to the entity) intersection with the Doppler baseline derived from the slope of the transmitral early filling wave. 399229004 G-0385 Mitral valve A-wave duration Duration of the transmitral velocity wave (observable entity) during atrial contraction. 399062002 G-0386 Ratio of mitral valve Ratio of the Mitral Valve Acceleration Time to acceleration time to mitral the Mitral Valve Deceleration Time. valve deceleration time (observable entity) 399104001 G-0387 Mitral valve closure to opening The time interval from the closure of the 1st time (observable entity) Doppler spectral taken from the mitral valve to the opening of the 2nd Doppler spectral of the mitral valve.

CONCEPTID SNOMEDID FULLY SPECIFIED NAME DEFINITION 399238002 G-0388 Ratio of pulmonic valve Ratio of Pulmonic Valve Acceleration Time to acceleration time to pulmonic Pulmonic Valve Ejection Time valve ejection time (observable entity) 399282006 G-0389 Tricuspid valve closure to The time interval from the closure of the 1st opening time (observable Doppler spectral taken from the tricuspid valve entity) to the opening of the 2nd Doppler spectral of the tricuspid valve. 399048009 G-038A Main pulmonary artery peak Peak velocity obtained from Pulsed Wave velocity (observable entity) Doppler or continuous wave Doppler, positioned in the main pulmonary artery. 399070007 G-038B Pulmonary vein A-wave Duration of the retrograde velocity in the duration (observable entity) pulmonary vein during atrial contraction. 399267001 G-038C Pulmonary vein S-wave The integral of the Doppler spectral profile of velocity time integral the systolic component of pulmonary venous (observable entity) flow. 399039004 G-038D Pulmonary vein D-wave The integral of the Doppler spectral profile of velocity time integral the diastolic component of pulmonary venous (observable entity) flow. 399367004 G-038E Cardiovascular orifice area Area of an orifice as calculated by Orifice area (observable entity) = Peak Instantaneous Flow Rate / Maximal Velocity of the Regurgitant jet at the Jet Orifice 399301000 G-0390 Regurgitant fraction Ratio of the Regurgitant Volume to the Stroke (observable entity) Volume: Regurgitant Volume / Inflow Volume. The Regurgitant Volume is the retrograde flow. The Inflow Volume is total antegrade volume. which is the sum of the Regurgitant Volume and net antegrade volume. 399093001 G-0391 Medial mitral annulus Area of the mitral annulus adjacent to the left structure (body structure) ventricular septum and outflow tract. 399086000 G-0392 Lateral mitral annulus Area of the mitral annulus adjacent to the left structure (body structure) ventricular posterolateral wall. 399345000 G-0393 Adult echocardiography Document title of adult echocardiography procedure report (record procedure (evidence) report. artifact) 399339008 G-0395 Apical long axis (qualifier Imaging plane with the transducer at the value) cardiac apex, which includes the left ventricle, left atrium, aortic outflow tract and proximal aorta. Usually visualizes a small portion of the right ventricle in the near field. 399139001 G-0396 Parasternal long axis view Imaging plane with the transducer at the left (qualifier value) sternal border oriented along the long axis of the left ventricle, which includes the left ventricle, left atrium, aortic outflow tract and proximal aorta. Usually visualizes a small portion of the right ventricle.

CONCEPTID SNOMEDID FULLY SPECIFIED NAME DEFINITION 399306005 G-0397 Parasternal short axis view Imaging plane with the transducer at the left (qualifier value) sternal border oriented along the short axis of the left ventricle. 399239005 G-0398 Parasternal short axis view at Imaging plane with the transducer at the left the aortic valve level (qualifier sternal border oriented along the short axis of value) the left ventricle, at the base of the heart, IVC, atrial septum, tricuspid valve, which includes the aortic valve, right and left atria, right ventricular outflow tract and pulmonic valve, pulmonary artery, and in some patients, the LPA and RPA. 399371001 G-0399 Parasternal short axis view at Imaging plane with the transducer at the left the level of the mitral chords sternal border oriented along the short axis of (qualifier value) the left ventricle, which includes the left ventricle at the level of the mitral chords, ventricular septum, and right ventricle. This plane is inferior to the mitral valve. 399036006 G-039A Parasternal short axis view at Imaging plane with the transducer at the left the mitral valve level (qualifier sternal border oriented along the short axis of value) the left ventricle, which includes the left ventricle at the level of the mitral valve leaflets, ventricular septum, and right ventricle. This plane is inferior to the aortic valve at the base of the heart. 399271003 G-039B Parasternal short axis view at Imaging plane with the transducer at the the papillary muscle level sternal border oriented along the short axis of (qualifier value) the left ventricle, which includes the left ventricle at the level of the papillary muscles, and right ventricle. This plane is inferior to the cordae. 398998003 G-039C Right ventricular inflow tract View of the Portion of the right ventricle view (qualifier value) adjacent to the tricuspid valve, the inflow portion of the RV. Common acronym: RVIT. 399195005 G-039D Right ventricular outflow tract View of the portion of the right ventricle view (qualifier value) adjacent to the pulmonic valve, the outflow portion of the RV. Common Acronym: RVOT. 399310008 G-039E Subcostal long axis view Imaging plane with the transducer at the (qualifier value) subcostal space (inferior to sternum) oriented along the long axis of the left ventricle, which includes the left ventricle, left atrium, right ventricle and right atrium, septum between left and right ventricles, and septum between the left and right atria. 399200001 G-039F Subcostal short axis view Imaging plane with the transducer at the (qualifier value) subcostal space oriented along the short axis of the left ventricle, either at the aortic valve level (base of heart) or more inferior plane of section through the left ventricle

CONCEPTID SNOMEDID FULLY SPECIFIED NAME DEFINITION 399106004 G-03A0 Suprasternal long axis view Imaging plane with the transducer in the (qualifier value) suprasternal notch, oriented along the long axis of the ascending aorta, aortic arch vessels, and proximal descending aorta. 399145009 G-03A1 Suprasternal short axis view Imaging plane with the transducer in the (qualifier value) suprasternal notch, oriented along the short axis of the aortic arch. This plane of section visualizes a cross-section of the aorta, long axis of the RPA, and in the pediatric patient, the left atrium and four pulmonary veins. 399064001 G-03A2 2D mode ultrasound (qualifier 2D, B-mode, B-scan image type value) 123038009 G-8000 Specimen (specimen) Material (structure, substance, device) removed from a source (patient, donor, physical location, product) 399232001 G-A19B Apical two chamber view Imaging plane with the transducer at the (qualifier value) cardiac apex, which includes the left ventricle and left atrium. 399214001 G-A19C Apical four chamber view A coronal imaging plane with the transducer (qualifier value) at the cardiac apex which includes the left ventricle, left atrium, right ventricle and right atrium. 260674002 G-C048 Direction of flow (attribute) The flow of an anatomic orifice. The orifice may be an opening such as a valve or stenosis. The direction may be valve retrograde flow (regurgitation) or antegrade flow. 119246008 J-14126 Imam (occupation) Muslim prayer leader 388445009 L-000A9 Genus Equus (organism) Horse, donkey, mule genus 68014009 L-88105 Canis familiaris (organism) Domestic dog subspecies 125085001 L-8A122 Equus asinus asinus Equus subspecies (organism) 125086000 L-8A144 Equus caballus gmelini X Intersubspecies equine hybrid Equus caballus caballus (organism) 78678003 L-8B100 Sus scrofa (organism) Domestic pig subspecies 388393002 L-8B1FB Genus Sus (organism) Swine genus 125093001 L-8B951 Bison bison X Bos taurus Intergenus hybrid of cattle indicus X Bos taurus taurus (organism) 125094007 L-8B952 Bos taurus indicus X Bos Intersubspecies cattle hybrid taurus taurus (organism) 125095008 L-8B953 Bos javanicus X Bos taurus Interspecies hybrid of cattle indicus (organism) 388168008 L-8BA18 Genus Bos (organism) Cattle genus

CONCEPTID SNOMEDID FULLY SPECIFIED NAME DEFINITION 125097000 L-8C306 Capra hircus (organism) Domestic goat 125099002 L-8C336 Ovis aries (organism) Domestic sheep species 125101009 L-8C338 Merino sheep superbreed Merino sheep breed group (organism) 125102002 L-9210A Anas platyrhynchos Mallard duck species (organism) 396620009 L-921FA Genus Anas (organism) Duck genus 15778005 L-92220 Anser (organism) Goose genus 70881005 L-92222 Anser anser anser (organism) Greyleg goose subspecies 125104001 L-9222A Anser anser (organism) Greyleg goose species 47290002 L-93790 Gallus gallus (organism) Junglefowl 125105000 L-9379A Gallus (organism) Junglefowl genus 125671007 M-01444 Rupture (morphologic Disruption of continuity of tissue, not abnormality) necessarily due to external forces; may be due to weakness in the tissue or excessive internal pressures 128176002 M-01471 Cutaneous patch Skin lesion, greater than 2 cm, flat, colored; (morphologic abnormality) differs from a macule only in size 128177006 M-01472 Cutaneous plaque Skin lesion, greater than 2 cm, flat, colored; (morphologic abnormality) differs from a macule only in size 27925004 M-03010 Nodule (morphologic A 1 to 5 cm firm lesion raised above the abnormality) surface of the surrounding skin; differs from a papule only in size 25694009 M-03130 Papule (morphologic A small, solid lesion, less than 1 cm in abnormality) diameter, raised above the surface of the surrounding skin and hence palpable 112629002 M-04013 Macule (morphologic A flat lesion, less than 2 cm in diameter, not abnormality) raised above the surface of the surrounding skin 19130008 M-10000 Traumatic abnormality A structure damaged by an external force (morphologic abnormality) 384709000 M-10005 Sprain (morphologic Injury to a ligament due to movement of joint abnormality) beyond normal range 161006 M-11000 Thermal injury (morphologic Injury due to increased heat abnormality) 48333001 M-11100 Burn injury (morphologic Generic burn injury, including that due to abnormality) excessive heat, as well as cauterization, friction, electricity, radiation, sunlight, and other causes 105594005 M-11106 Thermal burn (morphologic Burn injury due to excessive heat abnormality) 127559009 M-31318 Everted margin (morphologic The structure representing the everted margin abnormality) of a part

CONCEPTID SNOMEDID FULLY SPECIFIED NAME DEFINITION 189411005 M-35011 Antemortem thrombus Antemortem blood clot in the cardiovascular (morphologic abnormality) system 64305001 M-36320 Urticaria (morphologic A raised, erythematous papule or cutaneous abnormality) plaque, usually representing short-lived dermal edema 82515000 M-36750 Vesicle (morphologic A small (less than 1 cm) fluid-filled lesion, abnormality) raised above the plane of surrounding skin 339008 M-36760 Blister (morphologic A fluid-filled, raised, often translucent lesion, abnormality) greater than 1 cm in diameter 47002008 M-41601 Pustule (morphologic A vesicle filled with leukocytes abnormality) 128419007 M-55090 Pathologic mineralization Deposition of mineral in normally (morphologic abnormality) non-mineralized tissue 18115005 M-55420 Pathologic calcification, Deposition of calcium in normally non-calcified calcified structure tissue (morphologic abnormality) 122869004 P0-00081 Measurement procedure An observation, by some objective method, (procedure) of amount, number, quantity, size, level, extent, or magnitude, resulting in an ordinal or quantitative value 118661008 P0-00098 Physician service (procedure) Service provided by physician 14734007 P0-00100 Administrative procedure Procedure related to the administrative (procedure) aspects of health care, including admission, discharge, transfer, disposition, referral, business, legal, financial, quality review, peer review, data reporting, notification, and so forth 363687006 P0-0099C Endoscopic procedure An inspection done with an endoscope (procedure) 197157006 P0-0099D Photography of patient An observation that generates a recording (procedure) made from energy of the light spectrum 169283005 P0-009A0 Medical photography An observation that generates a recording (procedure) made from energy of the light spectrum 386053000 P0-009B4 Evaluation procedure Determination of a value, conclusion, or (procedure) inference by evaluating evidence 387713003 P0-009C3 Surgical procedure Planned structural alteration of the body, (procedure) usually requiring disruption of a body surface (usually skin or mucosa) 410614008 P0-00A65 Construction (procedure) The act of building something 410619003 P0-00A66 Application (procedure) Introduction of a substance or device to the surface of the body 409063005 P0-00B19 Counseling (procedure) Psychosocial procedure that involves listening, reflecting, etc. to facilitate recognition of course of action / solution.

CONCEPTID SNOMEDID FULLY SPECIFIED NAME DEFINITION 409073007 P0-00B27 Education (procedure) Procedure that is synonymous with those activities such as teaching, demonstration, instruction, explanation, and advice that aim to increase knowledge and skills, change behaviors, assist coping and increase adherence to treatment. 416118004 P0-00B68 Administration (procedure) Introduction of a substance to the body 119265000 P0-04001 Assisting (procedure) Helping the body perform a function it normally does on its own 119270007 P0-04003 Management procedure A plan or recommendation for services, based (procedure) on an evaluation 122545008 P0-04006 Stimulation procedure Procedure to arouse the body or any of its (procedure) parts or organs to increase functional activity 32485007 P0-10000 Hospital admission Performance of the steps necessary to admit (procedure) a patient to a hospital 58000006 P0-20000 Patient discharge (procedure) Performance of the steps necessary to discharge a patient from a location of care delivery 107724000 P0-20301 Patient transfer (procedure) Performance of the steps necessary to transfer a patient between locations of care delivery 633004 P0-80000 Chart review by physician A chart evaluation performed by a physician (procedure) 107727007 P0-80001 Chart related administrative An administrative procedure that involves a procedure (procedure) medical record chart 107728002 P0-80002 Chart evaluation by healthcare An evaluation of a medical chart by a health professional (procedure) care professional 86078004 P0-80500 Quality of care procedure A procedure that assesses the quality of (procedure) health care service delivery 50659003 P0-80600 Medical audit procedure A quality of care determination performed (procedure) retrospectively 16817006 P0-80660 Medical service audit A medical audit of direct care providers (procedure) 15367004 P0-80690 Ancillary service audit A medical audit of ancillary services (such as (procedure) physical therapy, dietary) 15807005 P0-806A0 Financial audit (procedure) A financial procedure that assesses a financial situation 57430006 P0-80800 Chart evaluation by A chart-related administrative procedure that non-healthcare professional checks a chart for completion and accuracy (procedure) and conformance to chart policy 54455007 P0-80820 Chart review, verification of A financial audit to review and/or verify charges (procedure) charges 29064005 P0-80850 Chart opening (procedure) A chart-related administrative procedure that involves opening the chart

CONCEPTID SNOMEDID FULLY SPECIFIED NAME DEFINITION 6035001 P0-80860 Chart abstracting (procedure) A chart related administrative procedure that involves abstracting information from the chart 42965003 P0-80890 Chart completion by medical A chart related administrative procedure done records (procedure) by the medical records department 118662001 P0-90003 Medicolegal procedure An administrative legal procedure (procedure) 118629009 P0-A0201 Functional training Procedure aimed at enhancing functioning, (procedure) frequently includes repetition of actions to develop, re-create or maintain physiological/cognitive processes. 118635009 P1-00031 Revision (procedure) Repeating a prior procedure to correct or improve the results 34896006 P1-01000 Incision (procedure) Making a cut in something 76145000 P1-01001 Exploratory incision An incision done for the purpose of performing (procedure) an exploration 122458006 P1-01002 Exploration procedure An observation of the body or a body part (procedure) done by inspection and/or palpation 122459003 P1-01003 Dissection procedure A separation of different structures along (procedure) natural cleavage lines by dividing the connective tissue framework 19484001 P1-01008 Decompressive incision An incision that relieves abnormal pressure (procedure) on a structure 122460008 P1-01009 Reexploration procedure A repeated exploration (procedure) 122461007 P1-01012 Evacuation procedure Removal of the contents of a body cavity or (procedure) container 122462000 P1-01013 Drainage procedure Evacuation of liquid contents by gravity (procedure) 70302008 P1-01020 Transection (procedure) A division made transversely across a long axis 118630004 P1-01027 Division (procedure) An incision that separates something into two or more parts 387651008 P1-010A1 Exploration with a probe An exploration done using a probe (procedure) 85921004 P1-01100 Puncture procedure A procedure done by piercing or penetrating (procedure) with a pointed object or instrument 86088003 P1-01130 Centesis (procedure) A puncture into a space with an aspiration of that space 65801008 P1-03000 Excision (procedure) Removal done with a cutting instrument 79095000 P1-03002 Complete excision of organ Complete excision and removal of an entire (procedure) body organ 118292001 P1-03003 Removal (procedure) To take something off or out, to get rid of, to eliminate

CONCEPTID SNOMEDID FULLY SPECIFIED NAME DEFINITION 20418004 P1-03004 Wedge resection (procedure) Excision of a wedge-shaped piece of tissue (often but not necessarily for diagnostic examination) 118636005 P1-0300B Expulsion (procedure) Evacuation using positive pressure 81723002 P1-03030 Amputation (procedure) Excision of normal topography 15440009 P1-03038 Disarticulation (procedure) Amputation through a joint without cutting of bone 14509009 P1-03053 Evisceration (procedure) Radical excision of tissues and organs of a body cavity 39250009 P1-03056 Enucleation (procedure) A removal of an anatomic or pathologic structure in entirety without breakage 86273004 P1-03100 Biopsy (procedure) Removal of tissue for diagnostic examination 8889005 P1-03101 Excisional biopsy (procedure) Biopsy that removes an entire lesion, with or without surrounding tissue 70871006 P1-03102 Incisional biopsy (procedure) Biopsy that involves incision and removal of part of a lesion or organ, rather than excision of the entire lesion or organ 119283008 P1-03103 Open biopsy (procedure) Biopsy by open approach, as opposed to percutaneous or endoscopic methods 14766002 P1-03130 Aspiration (procedure) Extraction using negative pressure 36777000 P1-03140 Debridement (procedure) Removal of devitalized tissue 68688001 P1-03150 Curettage (procedure) Scraping done with a curette 29923002 P1-03153 Shaving (procedure) A scraping away of thin sections 56757003 P1-03154 Scraping (procedure) Removal from a surface by repeated strokes of an edged instrument 107733003 P1-04FFF Introduction (procedure) Introduction of object AND/OR substance into or onto body, including injection, implantation, infusion, perfusion, transfusion, irrigation, instillation, insertion, placement, replacement, packing, intubation, catheterization, cannulation 59108006 P1-05000 Injection (procedure) Administration using positive pressure and a needle or other equipment to drive a substance into the body 14792009 P1-05015 Tattooing (procedure) An injection of indelible pigments 119268003 P1-05025 Inflation (procedure) Insufflation of a hollow organ or body cavity with gas, causing it to distend or swell 36576007 P1-05030 Infusion (procedure) An injection that is continuous 67889009 P1-05050 Irrigation (procedure) Administration that washes with a stream of liquid 68641000 P1-05060 Insufflation (procedure) An injection of a gas or powder into a body cavity by positive pressure

CONCEPTID SNOMEDID FULLY SPECIFIED NAME DEFINITION 55870005 P1-05070 Instillation (procedure) Administration of a liquid, drop by drop, into or onto the body 122463005 P1-05080 Embolization procedure An injection of some substance into the (procedure) circulation to occlude vessels, either to arrest or prevent hemorrhaging or to devitalize a structure or organ by occluding its blood supply 71861002 P1-05500 Implantation (procedure) Introduction of a non biologic device 3137001 P1-05501 Reimplantation (procedure) Implantation that is being revised 52765003 P1-05530 Intubation (procedure) An insertion of a tubular device into a canal, hollow organ, or cavity 4365001 P1-08000 Surgical repair (procedure) Restoring, to the extent possible, the natural anatomical structure 122464004 P1-08005 Augmentation procedure Procedure to increase the size, shape, or (procedure) volume of a body structure 59719002 P1-08060 Exteriorization (procedure) To expose the inner surface of a structure to the external surface of the body 118627006 P1-08061 Marsupialization (procedure) A construction of a pouch, achieved by resecting the anterior wall of a cyst or other enclosed cavity and suturing the cut edges of the remaining wall to adjacent edges of skin 112695004 P1-08400 Reparative closure A repair that unites structures (procedure) 50015006 P1-08413 Closure by staple (procedure) A closure done by stapling 70751009 P1-08420 Ligation (procedure) To bind with a ligature 56275003 P1-08421 Suture ligation (procedure) A ligation where the surgical suture serves as a ligature 1431002 P1-08460 Fixation (procedure) The act or operation of holding, suturing, or fastening in a fixed position 122868007 P1-08490 Staple implantation procedure An implantation of a staple (procedure) 122465003 P1-08601 Reconstruction procedure A reparative construction that builds or (procedure) rebuilds a structure that should normally be present 78817002 P1-08610 Construction of anastomosis A construction of an opening between two (procedure) hollow structures, organs, or spaces, be they real or artificial 88834003 P1-08611 Construction of shunt A construction of an alternate route of (procedure) passage of a bodily substance 75506009 P1-08612 Construction of stoma A construction of an abnormal passage (procedure) between a cavity or hollow organ and the surface of the body 4116001 P1-08613 Construction of window A construction of openings or fenestrae (procedure)

CONCEPTID SNOMEDID FULLY SPECIFIED NAME DEFINITION 118626002 P1-08617 Construction of interposition An anastomosis that places a tubular structure anastomosis (procedure) between the cut ends of a previously contiguous tubular structure 87193006 P1-08700 Fusion-stabilization and A fixation that joins together two body parts, immobilization (procedure) rendering them immobile with respect to each other 122501008 P1-08702 Fusion procedure (procedure) Procedure to cause two adjacent structures to be structurally joined together 122502001 P1-08703 Anchoring procedure Procedure to fix a mobile or flexible structure (procedure) to a rigid or inflexible structure 82254000 P1-08710 Refixation (procedure) A fixation that is being revised 64597002 P1-0C000 Destructive procedure Eradicating all or a portion of a body part (procedure) 9667001 P1-0C002 Surgical avulsion (procedure) A removal done by tearing away or forcible separation 2677003 P1-0C015 Stripping (procedure) A removal done by peeling, often using a stripper 119266004 P1-0C025 Coagulation (procedure) A destruction of tissue by means that results in condensation of protein material 119271006 P1-0C027 Obliteration (procedure) A destruction of a natural space or lumen by induced fibrosis or inflammation 27411008 P1-0C080 Cauterization (procedure) A destruction of tissue by burning or searing with a thermal instrument, an electric current, or a caustic substance 43802008 P1-0C200 Thermocautery (procedure) A cauterization done with thermal energy 60726007 P1-0C400 Crushing (procedure) A destruction done by injurious pressure. Note that this pressure can be mechanical, as in squeezing between two hard bodies, or can be a pressure wave, as is used to crush internal stones. 82413005 P1-0C410 Litholapaxy (procedure) A crushing of calculi (stone). 5845006 P1-0C430 Emulsification procedure A destruction achieved by turning a solid into (procedure) an emulsion 64874008 P1-0C504 Chemodenervation A denervation done using chemicals (procedure) 3324009 P1-0C620 Laser beam photocoagulation A photocoagulation using a laser beam (procedure) 77465005 P1-0D000 Transplantation (procedure) To move body tissue or cells from donor site to recipient site 53088000 P1-0D010 Autogenous transplantation A transplantation where the donor and (procedure) recipient spots are part of the same organism 27782009 P1-0D012 Syngeneic transplantation A transplantation where the donor and (procedure) recipient spots are part of genetically identical organisms

CONCEPTID SNOMEDID FULLY SPECIFIED NAME DEFINITION 50223000 P1-0D016 Allogeneic transplantation A transplantation where the donor and (procedure) recipient spots are from antigenically distinct individuals of the same species 48537004 P1-0D100 Bypass graft (procedure) A construction of a shunt using either biologic or synthetic material 75152009 P1-0D200 Transposition procedure An autogenous transplantation that does not (procedure) entirely sever the topographic object from the donor spot, at least until it is united at the recipient spot 19207007 P1-0E000 Manipulation (procedure) Skilled dextrous action of the hands directly applied to a body part 74923002 P1-0E100 Mobilization (procedure) A procedure that mobilizes or frees up an abnormally fixed structure 66391000 P1-0E150 Traction (procedure) The act of exerting a pulling force 112696003 P1-0E200 Manual reduction (procedure) A repair done via manipulation 62972009 P1-0E300 Extraction (procedure) Removal done by pulling 10012005 P1-0E350 Expression (procedure) An expulsion done by manipulation 62057008 P1-0E410 Dilation and stretching A dilation and a stretching (procedure) 122546009 P1-0E411 Stretching procedure Enlarging or distending a structure, increasing (procedure) its internal wall stress 2802005 P1-0E420 Manual dilation and stretching A dilation and stretching done by manipulation (procedure) 9421007 P1-0E450 Bougienage (procedure) A dilation done with a bougie 122467006 P1-0E501 Fitting procedure (procedure) A measurement or adjustment of a device or biologic material to the right shape or size so as to conform correctly when introduced or transplanted 118659004 P1-10887 Tenosuspension (procedure) Procedure to anchor a tendon to act as a suspensory ligament 7108004 P1-10C04 Osteoclasis (procedure) A destruction that purposefully results in a fracture of bone 81099000 P1-13860 Cervical arthrodesis The stiffening of one or more cervical joints (procedure) by operative means 70502009 P1-17A45 Pollicization of a digit The act of making a thumb out of a digit (finger (procedure) or toe) 46809006 P1-19376 Ostectomy, excision of tarsal Excision of the fibrous, cartilaginous, or bony coalition (procedure) fusion of two or more of the tarsal bones 359593004 P1-19A3E Midtarsal fusion (procedure) Arthrodesis of one or more of the tarsal joints 32350008 P1-41D60 Intermediate delay of small Delayed transfer flap-a flap graft that is flap at scalp (procedure) partially raised from the donor bed to permit collateral circulation of the pedicle

CONCEPTID SNOMEDID FULLY SPECIFIED NAME DEFINITION 57554003 P1-48120 Periprosthetic capsulotomy of Division of a fibrous capsule surrounding a breast (procedure) prosthetic breast implant 90991008 P1-48303 Periprosthetic capsulectomy Excision of a fibrous capsule surrounding a of breast (procedure) prosthetic breast implant 85768003 P1-78331 Excision of median bar of Median bar-a fibrotic structure across the neck prostate by transurethral of the prostate causing urethral obstruction approach (procedure) 77066003 P1-79370 Excision of hydatid of Excision of appendix of testis-vestige of Morgagni in male (procedure) Mullerian duct 28644007 P1-82308 Vaginal enterocelectomy Excision of an enterocele, a posterior vaginal (procedure) hernia 32998005 P1-8280B Latzko operation on vagina Repair of vesicovaginal fistula (procedure) 60753006 P1-82826 McIndoe operation for Construction of an artificial vagina consisting construction of vagina of a mold covered with a split-thickness skin (procedure) graft 64853007 P1-82827 Williams-Richardson operation A vulvovaginoplasty procedure described by for construction of vagina Williams to create a vaginal canal (procedure) 174000 P1-82833 Harrison-Richardson Vaginopexy according to Williams and operation on vagina Richardson is an abdominal colposuspension (procedure) by strips from external oblique 40587007 P1-82909 Pereyra procedure including Pereyra procedure: Needle suspension and anterior colporrhaphy suture of bladder neck for stress incontinence (procedure) 112928008 P1-86E22 Crede maneuver (procedure) A method of external massage of the uterus to promote delivery of the placenta 57551006 P1-A4824 Iridotasis (procedure) Stretching of the iris to increase the outflow of aqueous from the eye in glaucoma patients 3700004 P1-A5344 Erysiphake extraction of Intracapsular extraction of cataract using an cataract by intracapsular erysiphake, an instrument used to aspirate a approach (procedure) cataract 54305003 P1-A5820 Lens couching procedure Obsolete procedure involving displacement (procedure) of lens into vitreous for treatment of cataract 84100007 P2-01000 History taking (procedure) A clinically oriented interview of a patient or someone familiar with the patient 32166003 P2-01060 History taking, A history taken by a self-administered self-administered, questionnaire questionnaire (procedure) 5880005 P2-01400 Physical examination An observation of the body or a body part procedure (procedure) using one of the five human senses (e.g., inspection, palpation, percussion, auscultation) 32750006 P2-01500 Inspection (procedure) An exploration using the sense of sight, done with the eyes

CONCEPTID SNOMEDID FULLY SPECIFIED NAME DEFINITION 113011001 P2-01510 Palpation (procedure) An exploration using the sense of touch 75180006 P2-01550 Percussion (procedure) A listening of the sounds produced in response to tapping the body surface 37931006 P2-01560 Auscultation (procedure) A listening to spontaneously generated body sounds 103741002 P2-01570 Optical transillumination An inspection by the passage of light through (procedure) tissues or a body cavity 16076005 P2-08000 Prescription (procedure) A legal order to dispense and possibly prepare a substance or physical object 1366004 P2-22100 Inhalation therapy procedure An administration into the respiratory tract by (procedure) inspiration 4764004 P2-22223 Jet ventilation procedure Jet ventilation phasically directs a high-velocity (procedure) jet of humidified gas into the endotracheal tube at rapid frequencies, entraining additional fresh gas during insufflation 40617009 P2-22902 Artificial respiration An assistance of respiration (procedure) 11140008 P2-22905 Respiratory assist, manual An artificial respiration done manually (regime/therapy) 23426006 P2-25010 Measurement of respiratory A procedure on the respiratory tract that function (procedure) observes pulmonary function 76572000 P2-25250 Measurement of lung volume A pulmonary function test that measures lung (procedure) volumes 9134004 P2-30600 Ballistocardiography Obsolete method for determining cardiac (procedure) output by measuring recoil of body due to cardiac contraction 91480001 P2-40300 Iontophoresis procedure An administration into the tissues of an ionic (regime/therapy) substance by means of an electric current 225426007 P2-4510F Administration of therapeutic Introduction of a substance to the body substance (procedure) 5447007 P2-68000 Transfusion (procedure) An infusion of blood or blood product 239332003 P3-6018D Percutaneous test for allergy An immune system procedure that observes (procedure) for evidence of hypersensitivity 252512005 P3-60197 In vivo test of hypersensitivity An immune system procedure that observes (procedure) for evidence of hypersensitivity 118640001 P5-C0900 Radioimmunotherapy Radiation therapy using radiolabelled (procedure) antibodies 12894003 P7-00040 Functional assessment An evaluation of the performance of an organ, (procedure) organ system, or body part 71937005 P7-10000 Physiatric manipulation A manipulation done by a physiatrist (regime/therapy) 16992002 P7-11000 Osteopathic manipulation A manipulation done by an osteopath (procedure)

CONCEPTID SNOMEDID FULLY SPECIFIED NAME DEFINITION 46947000 P7-12000 Chiropractic manipulation A manipulation done by a chiropractor (procedure) 15420002 P8-80770 Reline lower partial denture, Refitting a denture by replacing the denture laboratory (procedure) base while keeping the occlusal relationship of the teeth the same 44764005 P8-85460 Crown, porcelain fused to Crowning preparation and covering of the noble metal (procedure) natural crown of a tooth with a veneer consisting of a metal, plastic resin, or porcelain or combinations 255482005 R-40491 Left upper segment (qualifier At location of left laterality and superior value) 255496004 R-4049E Right lower segment (qualifier At location (or vessel branch as in pulmonary value) vein) of right laterality and inferior 255499006 R-404A0 Right upper segment (qualifier At location (or vessel branch as in pulmonary value) vein) of right laterality and superior 246464006 R-42019 Function (observable entity) Any function or property that is not mainly morphologic or structural, including both measurable and observable features and physiologic actions 264068005 R-4214B Left lower segment (qualifier At location of left laterality and inferior value) 312004007 R-42E61 Retrograde direction (qualifier The state of reverse blood flow through a value) valve or orifice 125681006 S-11033 Single person (finding) Not currently married 33553000 S-11040 Widowed (finding) An unmarried person whose spouse has died 44667005 T-02660 Skin structure of hand, Skin region including some skin of finger AND including finger (body some additional non finger skin structure) 9385004 T-03660 Subcutaneous tissue structure Subcutaneous tissue including some tissue of hand, including finger (body of finger AND some additional non finger structure) tissue 84157002 T-11039 Structure of epiphyseal line The location of the epiphyseal growth plate (body structure) subsequent to its ossification 108372004 T-12762 Entire tarsal bone (body Any bone that is part of the tarsus structure) 91739007 T-13007 Endomysium (body structure) Fine connective tissue sheath around a muscle fiber 122504000 T-15624 Manubriosternal synostosis The connection between the manubrium and (body structure) sternum that has progressed from a symphysis to bony union (synostosis) 122497003 T-17441 Flexor tendon of wrist (body Tendons involved in flexing the wrist joint, structure) excluding flexor tendons that pass through the wrist that flex the fingers

CONCEPTID SNOMEDID FULLY SPECIFIED NAME DEFINITION 6553002 T-21370 Inferior nasal turbinate Shell-shaped structure of lateral inferior nasal structure (body structure) cavity, including bone and covering mucous membrane 60962000 T-21380 Middle nasal turbinate Shell-shaped structure of lateral middle nasal structure (body structure) cavity, including bone and covering mucous membrane 65289004 T-21390 Superior nasal turbinate Shell-shaped structure of lateral superior nasal structure (body structure) cavity, including bone and covering mucous membrane 33415007 T-21391 Supreme nasal turbinate Shell-shaped structure of lateral nasal cavity structure (body structure) above the superior nasal turbinate, including bone and covering mucous membrane 3377004 T-21420 Structure of agger nasi (body Ridge on the lateral internal nasal wall due to structure) the ethmoidal crest of the maxilla 81040000 T-44000 Pulmonary artery structure Includes pulmonary trunk, left and right main (body structure) pulmonary arteries, and all their branches 128261004 T-44004 Mediastinal pulmonary artery Includes pulmonary trunk and left and right (body structure) main pulmonary arteries 69105007 T-45010 Carotid artery structure (body One of the common carotid, internal carotid, structure) or external carotid arteries 38809004 T-48300 Structure of vein of thorax Vein located within the thorax (body structure) 91539005 T-48501 Structure of right pulmonary One of the great vessels draining venous vein (body structure) blood from the right lung 27706005 T-48502 Structure of left pulmonary One of the great vessels draining venous vein (body structure) blood from the left lung 122972007 T-48581 Pulmonary venous structure Any vein draining the lungs, including (body structure) pulmonary veins proper and their tributaries 128553008 T-49215 Structure of antecubital vein A vein located in the antecubital fossa (body structure) 51289009 T-50100 Digestive tract structure (body Entire digestive tract including mouth, structure) esophagus, stomach, and intestines 122865005 T-50101 Gastrointestinal tract structure Esophagus, stomach, small intestine, and (body structure) large intestine together as a single entity 62834003 T-50110 Upper gastrointestinal tract Esophagus, stomach, and duodenum structure (body structure) 5668004 T-50120 Lower gastrointestinal tract Jejunum, ileum, colon, rectum, and anal canal structure (body structure) 34810001 T-51010 Structure of vestibule of mouth The part of the oral cavity external to gums (body structure) and teeth and internal to cheeks and lips 71617008 T-51020 Structure of oral cavity proper The part of the oral cavity internal to the teeth (body structure) and bounded posteriorly by the palatoglossal arch

CONCEPTID SNOMEDID FULLY SPECIFIED NAME DEFINITION 47975008 T-53130 Structure of root of tongue The part of the tongue that is on the floor of (body structure) the mouth, and is not covered by mucous membrane 47975008 T-53130 Structure of root of tongue The pharyngeal part of the tongue, forming (body structure) the anterior wall of the oropharynx 3100007 T-54026 Clinical crown of tooth (body Portion of tooth exposed above gums, the part structure) above the clinical root 11326003 T-54061 Structure of coronal pulp of Part of the pulp of tooth that is within the tooth (body structure) crown portion of the pulp cavity 38954004 T-545A1 Carnassial tooth structure Tooth adapted to shear flesh (body structure) 68028003 T-56500 Crop (body structure) Dilated part of esophagus for food storage in birds 118652008 T-58049 Crypt of Lieberkühn (body Denotes the pits or crypts, but not the glands structure) that lie beneath them 3789000 T-58140 Enteroendocrine cell (cell) Endocrine cell of the gut 128180007 T-59261 Pelvic appendix (body Appendix which is oriented posteriorly and structure) inferiorly in the pelvic cavity 122489005 T-70001 Urinary system structure Organs of urine formation and secretion (body structure) 49549006 T-A0050 Visual system structure (body The eye, ocular adnexa, afferent visual structure) pathways, efferent visual pathways, and pupil innervation pathways 1231004 T-A1110 Meninges structure (body The three membranes that surround the brain structure) and spinal cord, consisting of the dura mater, arachnoid, and pia mater. The pia and arachnoid in combination are referred to as the leptomeninges. 35764002 T-A1600 Brain ventricle structure (body The four ventricles of the brain, including the structure) two lateral ventricles, the third ventricle, and the fourth ventricle 35328001 T-A9814 Structure of hepatic plexus An unpaired autonomic plexus that is part of (body structure) the celiac plexus that lies on the hepatic artery and its branches in the liver 82200002 T-A9815 Structure of splenic plexus An autonomic plexus that is a subdivision of (body structure) the celiac plexus that accompanies the splenic artery 64157005 T-A9816 Structure of gastric plexus Autonomic plexi that are part of the celiac (body structure) plexus that lies on the greater and lessor curvatures of the stomach 2504000 T-A9817 Structure of pancreatic plexus An autonomic plexus that is a subdivision of (body structure) the celiac plexus and accompanies the pancreatic arteries

CONCEPTID SNOMEDID FULLY SPECIFIED NAME DEFINITION 49412003 T-A9818 Adrenal plexus (body An autonomic plexus that is a subdivision of structure) the celiac plexus that accompanies the adrenal artery 48563009 T-A9819 Structure of renal plexus An autonomic plexus that is a subdivision of (body structure) the celiac plexus that accompanies the renal artery 21684005 T-A981A Structure of ureteral plexus An autonomic plexus that is derived from the (body structure) celiac plexus, more specifically renal and hypogastric plexi, that accompanies the ureteric artery to the ureter 86064000 T-A981B Structure of testicular plexus An autonomic plexus that is a subdivision of (body structure) the aortic plexus, or derived from it, that accompanies the testicular artery 15398002 T-A981C Structure of ovarian plexus An autonomic plexus that is a subdivision of (body structure) the aortic plexus, or derived from it, that accompanies the ovarian artery 53224005 T-A9820 Superior mesenteric plexus An autonomic plexus that branches from the structure (body structure) aortic plexus, that sends nerves to intestines and with the vagus forms subserous, myenteric, and submucous plexus 4150005 T-A9821 Celiac nervous plexus An autonomic plexus that is a superior structure (body structure) subdivision of the aortic plexus that runs anterior to the aorta at the level of the celiac trunk T12; contains celiac ganglia and most visceral afferents pass though it 74636004 T-A9822 Structure of aorticorenal A part of the celiac ganglion that is ganglia (body structure) semidetached and contains sympathetic neurons that innervate the kidney 79869003 T-A9830 Inferior mesenteric plexus An autonomic plexus that branches from the structure (body structure) aortic plexus, that sends nerves to descending colon, sigmoid, and rectum along the path of the inferior mesenteric artery 24981001 T-A9831 Structure of superior rectal An autonomic plexus that branches from the plexus (body structure) inferior mesenteric plexus; accompanies superior rectal artery to rectum 69854003 T-A9840 Structure of Auerbach's plexus A subdivision of the enteric plexus that lies (body structure) within the tunica muscularis of the intestinal tract 8595004 T-A9841 Structure of Meissner's plexus Part of the enteric plexus situated in the (body structure) intestinal submucosa 68305005 T-A9842 Structure of iliac plexus (body Autonomic plexus derived from the aortic structure) plexus, accompanying iliac arteries 34109009 T-A9843 Structure of femoral plexus An autonomic plexus accompanying the (body structure) femoral artery and derived from the iliac plexus

CONCEPTID SNOMEDID FULLY SPECIFIED NAME DEFINITION 47881004 T-A9850 Inferior hypogastric plexus An autonomic plexus formed by the junction structure (body structure) of the hypogastric nerve and the splanchnic nerve on each side; supplies pelvic viscera 53892006 T-A9851 Structure of hypogastric Nerves in the pelvis that connect the superior nerves (body structure) hypogastric plexus to the inferior hypogastric plexus 13559005 T-A9860 Structure of superior A continuation of the aortic plexus that leads hypogastric plexus (body to the right and left hypogastric nerves structure) 26701009 T-A9861 Structure of pelvic ganglia Sympathetic and parasympathetic ganglia (body structure) within pelvic plexi 17630002 T-A9862 Medial rectal plexus (body A subdivision of inferior hypogastric plexus, structure) maybe derived from it, that supplies nerves to the rectum 69079004 T-A9864 Prostatic sympathetic plexus Autonomic plexus that runs through the (body structure) capsule of the prostate and is derived from the inferior hypogastric plexus, and supplies the cavernous nerves of the erectile tissue of penis 4905007 T-A9866 Structure of uterovaginal Autonomic plexus with ganglia derived from plexus (body structure) inferior hypogastric plexus, that supplies uterus, vagina, ovary, erectile tissue of vestibule, and urethra 2044003 T-A9867 Structure of vaginal nerves Nerves running from uterovaginal plexus to (body structure) vagina that are both sympathetic and parasympathetic 81036009 T-A9868 Structure of vesical plexus An autonomic plexus derived from inferior (body structure) hypogastric plexus to supply sympathetic nerve fibers to urinary bladder, ureter, ductus deferens, and seminal vesicle 36364006 T-A9869 Structure of cavernous nerves Two nerves that supply sympathetic and of penis (body structure) parasympathetic innervation to vascular structures of corpus cavernosum, stimulating erection; derived from prostatic plexus 43671000 T-A986A Structure of cavernous nerves Nerves that supply sympathetic and of clitoris (body structure) parasympathetic innervation to erectile tissue of clitoris; derived from uterovaginal plexus 56190005 T-AA003 Structure of external axis of A line segment connecting anterior pole of eyeball (body structure) cornea to posterior pole of sclera 86588008 T-AA008 Structure of muscular fascia Fascia enclosing the extrocular muscles of eyeball (body structure) 24736005 T-AA00B Structure of soft tissues of Soft tissues enclosed within orbital region orbit (body structure) 26386000 T-AA079 Vitreous cavity structure (body The eye cavity that contains the vitreous structure)

CONCEPTID SNOMEDID FULLY SPECIFIED NAME DEFINITION 47538007 T-AA081 Vitreous body structure (body Composite structure of hyaluronic acid gel structure) within a stromal network of collagen fibrils 19359003 T-AA083 Hyaloid canal structure (body A canal that runs from optic disc to lens that structure) contains the hyaloid artery in the fetus 30110007 T-AA084 Structure of hyaloid fossa A depression of the anterior surface of the (body structure) vitreous body where the lens fits 76729009 T-AA100 Fibrous tunic of eye structure Outer coating of eyeball; has parts cornea and (body structure) sclera 27941003 T-AA101 Structure of anulus tendineus Orbital structure; a fibrous ring that is the communis (body structure) origin of the rectus muscles 31808004 T-C4310 Entire intrapulmonary lymph Lymph node within the lung node (body structure) 65690001 T-C4340 Structure of paratracheal Lymph node along the trachea; may be in lymph node (body structure) either the thorax or the neck 11899006 T-C4365 Structure of esophageal lymph Lymph node along the esophagus, may be in node (body structure) either the mediastinum or the neck 113343008 T-D0060 Body organ structure (body An anatomical structure that consists of the structure) maximal set of organ parts so connected to one another that together they constitute a self-contained unit of macroscopic anatomy, distinct both morphologically and functionally from other such units. Together with other organs, an organ constitutes an organ system or a body part. An organ is divisible into organ parts but not organs (examples: femur, biceps, liver, heart, aorta, sciatic nerve, ovary). 118760003 T-D0066 Entire viscus (body structure) A large organ in the thorax, abdomen, or pelvis 71905009 T-D1209 Infrapalpebral fold structure The sulcus (furrow) below the lower eyelid (body structure) 122861001 T-D1217 Sublingual space (body A potential space in the floor of the mouth; the structure) part of the submandibular space above the mylohyoid muscle 122498008 T-D1219 Submaxillary space structure A potential space of the floor of the mouth; (body structure) part of the submandibular space below the mylohyoid muscle 122499000 T-D121A Submental space (body A potential space of the floor of the mouth; structure) the medial part of the submaxillary space 122500009 T-D121B Masticator space (body A potential space containing the pterygoid and structure) masseter muscles 49928004 T-D1602 Structure of anterior portion of Neck anterior to the vertebral column, neck (body structure) including pharynx, larynx, and anterior surface 16982005 T-D2220 Shoulder region structure The body part defined by the shoulder joint (body structure) and its surrounding structures

CONCEPTID SNOMEDID FULLY SPECIFIED NAME DEFINITION 29836001 T-D2500 Hip region structure (body The body part defined by the hip joint and structure) surrounding structures, including the region from the iliac crest to the thigh 8389004 T-D6242 Structure of obstetrical canal The birth canal; consists of uterine cervix, (body structure) vagina, and vulva 53120007 T-D8000 Upper limb structure (body Upper extremity, including shoulder, arm, structure) forearm, wrist, and hand 40983000 T-D8200 Upper arm structure (body Upper extremity between shoulder and elbow structure) 76248009 T-D8300 Entire elbow region (body The body part defined by the elbow joint and structure) surrounding structures 8205005 T-D8600 Wrist region structure (body The body part defined by the wrist joint and structure) surrounding structures 61685007 T-D9000 Lower limb structure (body Lower extremity, including hip, thigh, leg, structure) ankle, and foot 83038001 T-D9040 Femoral region structure Anterior region of the thigh (body structure) 72696002 T-D9200 Knee region structure (body The body part defined by the knee joint and structure) its surrounding structures 30021000 T-D9400 Lower leg structure (body Lower extremity from knee to ankle structure) 54134001 T-F1200 Extraembryonic membranes The membranes which surround the embryo structure (body structure) but are not involved in formation of the embryo itself

Appendix J

SNOMED CT Allowed Attributes and Values

Topics: Note:

• Defining Attributes by Hierarchy Domain and range for attributes is covered in depth in the SNOMED and Domain CT User Guide. • Allowable Ranges Attributes connect concepts together and build relationships. They are the bridges between SNOMED CT’s main hierarchies – e.g., Clinical finding and Procedure – and supporting hierarchies like Organism, Substance, and Body structure. The hierarchies that an attribute can be applied to are sometimes referred to as the attribute’s “domain.” Each attribute can take values only from a particular value hierarchy. For example, values for the FINDING SITE attribute must come from the Acquired body structure or Anatomical structure hierarchies. The set of allowable values are sometimes referred to as the attribute’s “range.” Example: Pneumonia has FINDING SITE Lung structure. In this example, the attribute FINDING SITE is allowable for a concept in the Clinical Finding hierarchy such as Pneumonia. The value Lung structure is a valid value for this attribute since it is in the Anatomical structure hierarchy.

Defining Attributes by Hierarchy and Domain

The following table lists the top-level hierarchies for which there are defining attributes. Not all hierarchies in SNOMED CT have defining attributes. They were developed in the priority areas first. The highest priority was to develop defining attributes that would be useful for aggregated analysis of outcomes, decision support, knowledge-based practice guidelines, etc. in a clinical setting. Therefore, defining attributes in SNOMED CT were first assigned to those hierarchies where retrieval of clinical data is most useful and relevant: procedure, finding, and situation with explicit context. Concepts in other hierarchies can be primitives and still serve as the values of attributes for the concept definitions of the main hierarchies. Some domains are not top-level hierarchies, and some top-level hierarchies are not domains. Each item in the Hierarchy column refers to the top-level hierarchy where the attribute applies. Some of these do not actually apply at the very top of the hierarchy, but are restricted to a domain defined lower down. Some of them apply to more than one top-level hierarchy. Each item in the Attribute column refers to a single attribute that resides in the Attribute hierarchy.

Table 35: Defining Attributes by Top-Level Hierarchy

HIERARCHY ATTRIBUTE Body structure Laterality Clinical finding After Associated morphology Associated with Causative agent Clinical course Due to Episodicity Finding informer Finding method Finding site Has definitional manifestation Has interpretation Interprets Occurrence Pathological process Severity

HIERARCHY ATTRIBUTE Situation with explicit context Associated finding Associated procedure Finding context Procedure context Subject relationship context Temporal context Event After Associated with Causative agent Due to Occurrence Pharmaceutical / biologic product Has active ingredient Has dose form Physical object Has active ingredient Has dose form

HIERARCHY ATTRIBUTE Procedure Access Component Direct device Direct morphology Direct substance Has focus Has intent Has specimen Indirect device Indirect morphology Measurement method Method Priority Procedure device Procedure morphology Procedure site Procedure site - Direct Procedure site - Indirect Property Recipient category Revision status Route of administration Scale type Surgical Approach Time aspect Using device Using access device Using energy Using substance Specimen Specimen procedure Specimen source identity Specimen source morphology Specimen source topography Specimen substance

Table 36: Top-Level Hierarchies That Have No Defining Attributes

HIERARCHY ATTRIBUTE Attribute none Environments and geographical locations none Observable entity see draft of new model Organism see draft of new model Physical force none Qualifier value none Social context none Special concept none Staging and scales none Substance see draft of new model

Each attribute has a specific domain to which it applies; in many cases these domains are simply the same as the top-level hierarchies, as listed in parentheses after the domain name. In other cases, there is a more restrictive domain. In the following table, the left-hand column names the specific domain, and the right hand column the defining attributes. Some of these attributes (marked with an asterisk in the table below) are allowed only in close-to-user form. These are used for user-level composition, and are not applied directly as defining attributes in the distributed form (or in normal forms).

Table 37: Allowed Attributes by Domain

DOMAIN (HIERARCHY) ATTRIBUTE Administration of substance via specific route Route of administration (procedure) Anatomical structure (body structure) Laterality Part of

DOMAIN (HIERARCHY) ATTRIBUTE Clinical finding (finding) After Associated morphology Associated with Causative agent Clinical course Due to Episodicity Finding informer Finding method Finding site Has interpretation Interprets Laterality* Occurrence Pathological process Severity Disorder (finding) Has definitional manifestation Drug delivery device (physical object) Has active ingredient Has dose form Evaluation procedure (procedure) Component Has specimen Measurement method Property Scale type Time aspect Event (event) After Associated with Causative agent Due to Occurrence Finding with explicit context - descendents only Associated finding (finding) Finding with explicit context - self and descendents Finding context (finding)

DOMAIN (HIERARCHY) ATTRIBUTE Pharmaceutical / biologic product (product) Has active ingredient Has dose form Procedure (procedure) Access Direct device Direct morphology Direct substance Has focus Has intent Indirect device Indirect morphology Method Priority Procedure device Procedure morphology Procedure site Procedure site - Direct Procedure site - Indirect Recipient category Revision status Using device Using access device Using energy Using substance Procedure with explicit context - descendents only Associated procedure (procedure) Procedure with explicit context - self and descendents Procedure context (procedure) Situation with explicit context (situation) Subject relationship context Temporal context Specimen (specimen) Specimen procedure Specimen source identity Specimen source morphology Specimen source topography Specimen substance Surgical procedure (procedure) Surgical Approach

Table 38: Historical Relationships by Domain

DOMAIN HISTORICAL REALATIONSHIP Ambiguous Concept MAYBE A Duplicate Concept SAME AS Erroneous Concept REPLACED BY WAS A Inactive Reason Not Stated Concept REPLACED BY WAS A Limited Status Concept WAS A Moved From Elsewhere Concept MOVED FROM Moved To Elsewhere Concept MOVED TO Outdated Concept REPLACED BY WAS A Pending Move Concept MOVED TO

Allowable Ranges

The following table contains the allowable Values (Ranges) that can be applied to each Attribute. Note that each item in the Attribute column refers to a single concept that resides in the Attribute hierarchy.

ATTRIBUTE RANGE

ACCESS Surgical access values 309795001 (<=)(< Q)

AFTER Clinical Finding 404684003 (<<) Procedure 71388002 (<<)

ASSOCIATED FINDING Clinical finding 404684003 (<=)(< Q) Event 272379006 (<=)(< Q) Observable entity 363787002 (< Q only) Link assertion 416698001 (< Q only) Procedure 71388002 (< Q only)

ASSOCIATED MORPHOLOGY Morphologically abnormal structure 49755003 (<<)

ASSOCIATED PROCEDURE Procedure 71388002 (<=)(< Q) Observable entity 363787002 (< Q only)

ATTRIBUTE RANGE ASSOCIATED WITH Clinical Finding 404684003 (<<) Procedure 71388002 (<<) Event 272379006 (<<) Organism 410607006 (<<) Substance 105590001 (<<) Physical object 260787004 (<<) Physical force 78621006 (<<) Pharmaceutical/biologic product 373873005 (<< Q only) SNOMED CT Concept 138875005 (==)

CAUSATIVE AGENT Organism 410607006 (<<) Substance 105590001 (<<) Physical object 260787004 (<<) Physical force 78621006 (<<) Pharmaceutical/biologic product 373873005 (<< Q only) SNOMED CT Concept 138875005 (==)

COMPONENT Substance 105590001 (<=)(< Q) Observable entity 363787002 (<=)(< Q) Cell structure 4421005 (<=)(< Q) Organism 410607006 (<=)(< Q)

CLINICAL COURSE Courses 288524001 (<=)(< Q)

DIRECT DEVICE Device 49062001 (<<)

DIRECT MORPHOLOGY Morphologically abnormal structure 49755003 (<<)

DIRECT SUBSTANCE Substance 105590001 (<<) Pharmaceutical/biologic product 373873005 (<<)

DUE TO Clinical Finding 404684003 (<=) Event 272379006 (<=)

EPISODICITY Episodicities 288526004 (<=)(< Q)

FINDING CONTEXT Finding context value 410514004 (<=)(< Q)

ATTRIBUTE RANGE

FINDING INFORMER Performer of method 420158005 (<<) Subject of record or other provider of history 419358007 (<<)

FINDING METHOD Procedure 71388002 (<=)

FINDING SITE Anatomical or acquired body structure 442083009 (<<)

HAS ACTIVE INGREDIENT Substance 105590001 (<<)

HAS DEFINITIONAL MANIFESTATION Clinical finding 404684003 (<<)

HAS DOSE FORM Type of drug preparation 105904009 (<<)

HAS FOCUS Clinical finding 404684003 (<<) Procedure 71388002 (<<)

HAS INTENT Intents (nature of procedure values) 363675004 (<=)

HAS INTERPRETATION Findings values 260245000 (<<)

HAS SPECIMEN Specimen 123038009 (<=)(< Q)

INDIRECT DEVICE Device 49062001 (<<)

INDIRECT MORPHOLOGY Morphologically abnormal structure 49755003 (<<)

INTERPRETS Observable entity 363787002 (<<) Laboratory procedure 108252007 (<<) Evaluation procedure 386053000 (<<)

LATERALITY Side 182353008 (<=)

MEASUREMENT METHOD Laboratory procedure categorized by method 127789004(<=)

METHOD Action 129264002 (<<)

OCCURRENCE Periods of life 282032007 (<)

PATHOLOGICAL PROCESS Autoimmune 263680009 (==) Infectious process 441862004 (<<)

PRIORITY Priorities 272125009 (<=)(< Q)

ATTRIBUTE RANGE

PROCEDURE CONTEXT Context values for actions 288532009 (<=)(< Q)

PROCEDURE DEVICE Device 49062001 (<<)

PROCEDURE MORPHOLOGY Morphologically abnormal structure 49755003 (<<)

PROCEDURE MORPHOLOGY DIRECT Morphologically abnormal structure 49755003 (<<)

PROCEDURE MORPHOLOGY INDIRECT Morphologically abnormal structure 49755003 (<<)

PROCEDURE SITE Anatomical or acquired body structure 442083009 (<<)

PROCEDURE SITE DIRECT Anatomical or acquired body structure 442083009 (<<)

PROCEDURE SITE INDIRECT Anatomical or acquired body structure 442083009 (<<)

PROPERTY Property of measurement 118598001 (<=)(< Q)

RECIPIENT CATEGORY Person 125676002 (<<) Family 35359004 (<<) Community 133928008 (<<) Donor for medical or surgical procedure 105455006 (<<) Group 389109008 (<<)

REVISION STATUS Primary operation 261424001 (<<) Revision-value 255231005 (<<) Part of multistage procedure 257958009 (<<)

ROUTE OF ADMINISTRATION Route of administration value 284009009 (<<)

SCALE TYPE Quantitative 30766002 (<<) Qualitative 26716007 (<<) Ordinal value 117363000 (<<) Ordinal or quantitative value 117365007 (<<) Nominal value 117362005 (<<) Narrative value 117364006 (<<) Text value 117444000 (<<)

SEVERITY Severities 272141005 (<=)(< Q)

ATTRIBUTE RANGE

SPECIMEN PROCEDURE Procedure 71388002 (<)

SPECIMEN SOURCE IDENTITY Person 125676002 (<<) Family 35359004 (<<) Community 133928008 (<<) Device 49062001 (<<) Environment 276339004 (<<)

SPECIMEN SOURCE MORPHOLOGY Morphologically abnormal structure 49755003 (<<)

SPECIMEN SOURCE TOPOGRAPHY Anatomical or acquired body structure 442083009 (<<)

SPECIMEN SUBSTANCE Substance 105590001 (<<)

SUBJECT RELATIONSHIP CONTEXT Person 125676002 (<=)(< Q)

SURGICAL APPROACH Procedural approach 103379005 (<=)(< Q)

TEMPORAL CONTEXT Temporal context value 410510008 (<=)(< Q)

TIME ASPECT Time frame 7389001 (<=)(< Q)

USING ACCESS DEVICE Device 49062001 (<<)

USING DEVICE Device 49062001 (<<)

USING ENERGY Physical force 78621006 (<<)

USING SUBSTANCE Substance 105590001 (<<)

Meaning of Allowable Values (Range) notations:

(<<) this code and descendants, (<) descendants only, (<=) descendants only (stated) except for supercategory groupers, (==) this code only, (< Q) descendants only when in a qualifying relationship, (< Q only) descendants only, and only allowed in a qualifying relationship.

Appendix K

Glossary

Topics: This glossary is intended to be an informative source of reference relating to various terms used in this and other documents connected with • A SNOMED Clinical Terms. • B • C • D • E • F • H • I • K • L • M • N • O • P • Q • R • S • T • U • W

Active Concept A Concept that is intended for active use. This is determined by the ConceptStatus. Concepts with status value “Current” (0) are always regarded as active. Concepts with status “Pending Move” (11) are regarded as active if the Concept is not yet accessible in the new target Namespace. See also Inactive Concept on page 209.

Active Description A Description that is intended for active use. This is determined by a combination of the DescriptionStatus, the DescriptionType in the Language or Dialect in use and the ConceptStatus of the associated Concept. Descriptions are active when the following conditions apply: • Associated with an Active Concept, • AND DescriptionStatus “Current” (0) or “Pending Move” (8) • AND DescriptionType not unspecified (0) in a chosen Language/Dialect See also Inactive Description on page 209.

Base Subset A Subset used as a starting point for the Subset Definition of another Subset.

Canonical form A table that contains the Canonical form expressions for all SNOMED CT Concepts. This table contains some (but not all) of the attributes present in the Relationships Table. It only contains the Defining characteristics required to distinguish a Concept from its most proximate Primitive supertype Concepts. The set of “IS A” subtype Relationships excludes Relationships to Fully defined (non-primitive) Concepts and includes instead appropriate additional Relationships to the most proximate supertypes.

Canonical Table A table that contains the Canonical form expressions for all SNOMED CT Concepts. This table contains some (but not all) of the attributes present in the Relationships Table. It only contains the Defining characteristics required to distinguish a Concept from its most proximate Primitive supertype Concepts. The set of “IS A” subtype Relationships excludes Relationships to Fully defined (non-primitive) Concepts and includes instead appropriate additional Relationships to the most proximate supertypes.

ChangeType A field in the Component History Table that indicates the nature of a change to a Component made in a specified release of SNOMED CT.

CharacteristicType A field in the Relationships Table that indicates whether a Relationship specifies a defining characteristic, a qualifying characteristic, a historical relationship, or an additional non-defining characteristic. See Table 11: CharacteristicType Values on page 84.

Check-digit The check-digit is the final (rightmost) digit of the SNOMED CT Identifier (SCTID). It can be used to check the validity of SCTIDs. Clinical information systems can use the check-digit to identify SNOMED CT codes that have been entered incorrectly (typo errors, etc). It is calculated using the algorithm described in Check-digit computation on page 132.

Child/Children See Subtype on page 219.

Clinical Terms Version 3 (CTV3) One of the source terminologies, along with SNOMED RT, that were used to develop SNOMED CT. CTV3 is UK Crown Copyright, distributed by the United Kingdom National Health Service (NHS), and is integrated into SNOMED CT. Also known as “Version 3 of the Read Codes.”

Component Refers to any item identified by an SCTID in the main body of SNOMED CT, or in an authorized Extension. The partition identifier indicates the type of component referred to by that SCTID. Each Component is a uniquely identifiable instance of one of the following: • Concept • Description • Relationship • Subset • Subset Member • Cross Map Set • Cross Map Target • History Component

ComponentId A general term used to refer to the primary identifier of any SNOMED CT Component. ComponentIds include ConceptIds, DescriptionIds, RelationshipIds, SubsetIds, CrossMapSetIds and TargetIds. All ComponentIds follow the form of the SCTID specification.

Component History A record of an addition or change in the status of a SNOMED CT Component in a particular Release Version. Each item of Component History is represented by a row in the Component History Table.

Component History Table A data table consisting of rows each of which represents an item of Component History. The Component History Table is part of the History Mechanism. See Component History Table on page 115.

Concept An ambiguous term. Depending on the context, it may refer to: • A clinical idea to which a unique ConceptId has been assigned.

• The ConceptId itself, which is the key of the Concepts Table (in this case it is less ambiguous to use the term "concept code"). • The real-world referent(s) of the ConceptId, that is, the class of entities in reality which the ConceptId represents (in this case it is less ambiguous to use the term "meaning" or "code meaning").

ConceptId A SNOMED Clinical Terms Identifier (code) that uniquely identifies a Concept (meaning). For a full explanation of how this identifier is structured, see The SNOMED Clinical Terms Identifier (SCTID) on page 120. Example: For the meaning named Pneumonia (disorder), the ConceptId is 233604007.

ConceptId1 A field in the Relationships Table and Canonical Table that refers to the first of two related Concepts. The first Concept is defined or qualified by a Relationship to the second Concept.

ConceptId2 A field in the Relationships Table and Canonical Table that refers to the second of two related Concepts. The second Concept defines or qualifies the first Concept.

ConceptStatus A field in the Concepts Table that specifies whether a Concept is in current use. Values include “current”, “duplicate”, “erroneous” “ambiguous” and “limited”.

Concepts Table A table that includes all SNOMED CT concept codes. Each concept code is represented by a single row. For the structure of the table see Concepts Table on page 74.

Concept equivalence Equivalence is the state of two SNOMED CT concept codes or post-coordinated expressions having the same meaning. Concept equivalence can occur when a post-coordinated expression has the same meaning as a pre-coordinated concept code; or when two different post-coordinated expressions have the same meaning.

Context-specific characteristic A Relationship to a target Concept that provides information about the source Concept that is true at a particular time or within a particular country or organization. Contrast with Defining characteristic and Qualifying characteristic. Referred to in CTV3 as a ‘Fact’.

ContextId A field in the Subsets Table that specifies the context within which a Context Concept Subset or Context Description Subset is valid.

Context Concept Subset A Subset used to specify the Concepts that form part of a context-domain.

Context Description Subset A Subset used to specify the Descriptions that form part of a context-domain.

Context Domain A context-domain is a set of values that are, or may be, used in an identifiable logical setting in an application, protocol, query or communication specification. A context-domain may be very broad (e.g. procedures or diagnoses) or very narrow (e.g. procedures performed by a specialty or possible values for a field in specific message).

Core Tables See SNOMED CT Core Tables on page 217.

Cross Map A Cross Map is a reference from a Concept code to a Cross Map Target. Each Cross Map is represented as a row in the Cross Maps Table. It links a single SNOMED CT concept code to one or more codes in a target classification (such as ICD-9-CM) or terminology. A Concept code may have a single Cross Map or a set of alternative Cross Maps.

Cross Maps Table A data table consisting of rows each of which represents a Cross Map. See Cross Maps Table on page 101.

Cross Map Set A set of Cross Maps that together provide a valid way of mapping some or all SNOMED CT Concepts to a specified Target Scheme. Alternative Cross Map Sets may exist for the same Target Scheme, if business rules or guidelines alter the appropriateness of particular mappings to that scheme. Each Cross Map Set is represented as a row in the Cross Map Sets Table.

Cross Map Sets Table A data table consisting of rows each of which represents a Cross Map Set. See Cross Map Sets Table on page 98.

Cross Map Target A code or set of codes in a Target Scheme that together represent an appropriate mapping from a clinical statement expressed using SNOMED CT. Some Cross Map Targets may be derived from two or more associated statements and in these cases the combination can be expressed as a set of associated rules. Each Cross Map Target is represented as a row in the Cross Map Targets Table.

Cross Map Targets Table A data table consisting of rows each of which represents a Cross Map Set. See Cross Map Targets Table on page 103.

CTV3 See Clinical Terms Version 3 (CTV3) on page 204.

CTV3ID A five-character code allocated to a meaning or term in Clinical Terms Version 3 (CTV3, previously known as Read Codes). Each row in the SNOMED CT concepts table has a field for the corresponding concept code from CTV3.

Data migration Steps taken to enable legacy data to be accessible as part of a system that uses SNOMED CT. Options for Data migration include actual conversion of the data or provision of methods for accessing the data in its original form.

Defining characteristic A Relationship to a target Concept that is always true from any instance of the source Concept. Example: “‘PROCEDURE SITE’ = ‘Liver’” is a Defining characteristic of the Concept ‘Liver biopsy’. Contrast with qualifying characteristic and context-specific characteristic. Referred to in CTV3 as an ‘Atom’.

Descendants All subtypes of a concept, including subtypes of subtypes. For example, if a concept has four children, then descendants = those children plus all the concepts that are descended from those four children. See also Subtype on page 219.

Description A human-readable phrase or name (Term) associated with a particular SNOMED CT concept code. Each of the descriptions in SNOMED CT is given a separate row in the Descriptions Table. Each Description is assigned a unique DescriptionId and connects a Term and a Concept.

DescriptionId A SNOMED CT Identifier that uniquely identifies a Description. For a full explanation of how this identifier is structured, see The SNOMED Clinical Terms Identifier (SCTID) on page 120.

DescriptionStatus A field in the Descriptions Table that specifies whether a Description is in current use. Values include “current”, “duplicate”, “erroneous” “inappropriate” and “limited”.

Descriptions Table A data table consisting of rows, each of which represents a Description. For the structure of the table see Descriptions Table on page 77.

DescriptionType A field in the Descriptions Table that specifies whether a Description is a Fully Specified Name, Preferred Term, or Synonym. The DescriptionType is language dependent and may be changed by applying a Language Subset. It may be “undefined” in the released Descriptions Table in which case the Description is not used unless an appropriate Language Subset is applied.

Dialect A language modified by the vocabulary and grammatical conventions applied to the language of a particular geographical or cultural environment.

Dualkey A key used to facilitate textual searches of SNOMED CT that consists of the first three letters of a pair of words in a Description. All possible pairs of words in each Description may be paired irrespective of their relative position in the Description. Dualkeys are represented as a row in the Dualkeys Table.

Dualkey Table A table in which each row represents a Dualkey. See Word Search Tables – Summary on page 57.

Duplicate Term A Term that occurs in several Active Descriptions. Duplicate Terms are valid in SNOMED CT since the intention is to provide natural terms used by clinicians rather than to apply formalized phraseology. The formalized form is provided by the Fully Specified Name and these are not permitted to be duplicated. Although Duplicate Terms can be identified by string matching, a Duplicate Terms Subset is specified to indicate the presence and likely priority of duplicates when undertaking a search.

Duplicate Terms Subset A Subset Type that identifies Duplicate Terms and allows a priority to be specified between these for use in searches.

Equivalence See Word Equivalents, Phrase equivalence and Concept equivalence.

Excluded Word A word that in a given language is so frequently used, or has so poor a discriminating power, that it is suggested for exclusion from the indices used to support textual searches of SNOMED CT. Excluded Words are represented as a row in the Excluded Words Table

Excluded Words Table A data table in which each row represents an Excluded Word. See Word Search Tables – Summary on page 57.

Expression A structured combination of one or more concept identifiers used to express an instance of a clinical idea. An expression containing a single concept identifier is referred to as a pre-coordinated expression. An expression that contains two or more concept identifiers is a post-coordinated expression. The concept identifiers within a post-coordinated expression are related to one another in accordance rules expressed in the SNOMED CT Concept Model. These rules allow concepts to be: • combined to represent clinical meanings which are subtypes of all the referenced concepts, e.g. "tuberculosis" + "lung infection" • applied as refinements to specified attributes of a more general concept, e.g. "asthma" : "severity" = "severe" See SNOMED CT Abstract Models and Representational Forms.

Extension A data table or set of data tables that is created in accordance with the structures and authoring guidelines applicable to SNOMED CT. An extension is ordinarily edited, maintained and distributed by an organization other than the IHTSDO. Components in extensions are identified using extension SCTIDs, which are structured to ensure that they do not collide with other SCTIDs, and can be traced to an authorized originator.

Extra-Concept A Concept distributed as part of an Extension.

Extra-Description A Description which is distributed as part of an Extension. An Extra-Description may apply a Term to an SCT Concept or to an Extra-Concept.

Extra- Relationship A Relationship between two Concepts distributed as part of an Extension. An Extra-Relationship may relate SCT Concepts and/or Extra-Concepts.

Extra-Subset A Subset distributed as part of an Extension. The members of an Extra-Subset may include SNOMED CT-Concepts, Extra-Concepts, SNOMED CT- Descriptions and Extra-Descriptions.

Fully defined See Sufficiently defined on page 219.

Fully Specified Name A term unique among active Descriptions in SNOMED CT that names the meaning of a Concept code in a manner that is intended to be unambiguous and stable across multiple contexts.

Historical Relationship A Relationship that refers from an Inactive Concept to an Active Concept that duplicates, corrects, replaces or disambiguates it. Note that Historical Relationships are used in a way similar to References for Descriptions. However, as part of the Relationships Table they are more readily accessible for computation and retrieval of legacy data.

History Mechanism The history mechanism is the information distributed with SNOMED CT designed to track the history of changes to its logic definitions and descriptions. The history mechanism is supported by two distribution tables: • Component History Table • References Table

Inactive Concept A Concept that is not intended to be actively used. This is determined by the ConceptStatus. Concepts with status values other than “Current” (0) and “Pending Move” (11) are regarded as inactive. Concepts with status “Pending Move” (11) are regarded as inactive if the Concept is accessible in the new target Namespace as of the release date. Inactive Concepts remain in SNOMED CT to support legacy data recorded when the Concepts were in active use. See also Active Concept on page 203.

Inactive Description A Description that is not intended to be actively used. This is determined by a combination of the DescriptionStatus, the DescriptionType in the Language or Dialect in use and the ConceptStatus of the associated Concept. Descriptions are inactive if one or more of the following apply: • Associated with an Inactive Concept, • OR DescriptionStatus not “Current” (0) or “Pending Move” (8) • OR DescriptionType unspecified (0) in a chosen Language/Dialect Inactive Descriptions remain in SNOMED CT to support legacy data recorded when these Descriptions were in active use. See also Active Description on page 203.

InitialCapitalStatus A field in the Descriptions Table that specifies whether the capitalization of the first character is significant. If the value of this field is “1” then the first character should remain either in upper or lower case as released. Otherwise the case of the first character may be changed to suit its context in a sentence.

International Release The collection of terminology components, related works and resources that are maintained by the IHTSDO and are regularly made available to all Member countries.

IsPrimitive A field in the Concepts Table that indicates whether a Concept is Primitive or Fully defined.

IS A The RelationshipType that defines a supertype-subtype. Relationship between two Concepts. Usually expressed as subtype “IS A” supertype. For Example, Blister with infection IS A Infection of skin.

Keyword A field containing a potential search text in one of the WordKey Tables or a word excluded for key generation in the Excluded Words Table.

Kind-of-Value The nature of a value that may be associated with a Concept. For example, the concept "systolic blood pressure reading" can label a numeric value. The Kind-of-Value that it labels is a pressure.

Language For purposes of SNOMED CT translations, a language is a vocabulary and grammatical form that has been allocated an ISO639-1 language code. See also Dialect on page 207.

LanguageCode A field that indicates the Language and, optionally, Dialect applicable to a row in the Subsets Table, Descriptions Table or to an Excluded Words Table.

Language Subset SNOMED CT can be translated into virtually any human language or dialect. These translations attach new language-specific terms as descriptions of existing concept codes and may also use existing descriptions if translation is not necessary. A language subset is a set of references to the descriptions that are members of a language edition of SNOMED CT. Additionally, data in the language subset specifies the DescriptionType of each description (Fully Specified Name, Preferred Term or Synonym).

LinkedId A field in the Subsets Table.

MapAdvice A field in the Cross Maps Table, may contain human-readable advice on mapping.

MapConceptId A field in the Cross Maps Table containing the identifier of the Concept that is the subject of the map.

MapOption A field in the Cross Maps Table, which specifies the order in which Cross Maps are tested for automated processing of cross mapping rules.

Mapping Mechanism A set of data structures for representing cross-links to other terminologies and classifications. The Mapping Mechanism data structures are distributed as three tables: • Cross Map Sets Table • Cross Maps Table • Cross Map Targets Table

MapPriority A field in the Cross Maps Table that specifies which Cross Maps are most likely to apply to the associated Concept. The value 0 indicates a default map.

MapRule A field in the Cross Maps Table that may contain a computer processable representation of a rule that determines when this map should be used.

MapSetId A SNOMED CT Identifier that uniquely identifies a Cross Map Set.

MapSetName A field in the Cross Map Sets Table that names that Cross Map Set.

MapSetRealmId A field in the Cross Map Sets Table that indicates the Realm in which a set of Cross Maps is applicable.

MapSetRuleType A field in the Cross Map Sets Table that indicates whether any computer processable rules are present in the associated Cross Maps or Cross Map Targets and, if so, what form of expression is used to represent these rules.

MapSetSchemeId A field in the Cross Map Sets Table which identifies the classification or coding-scheme that is the target of a Cross Map Set.

MapSetSchemeName A field in the Cross Map Sets Table that contains the plain text name of the classification or coding-scheme that is the target of a Cross Map Set.

MapSetSchemeVersion A field in the Cross Map Sets Table that identifies the version of the classification or coding-scheme that is the target of a Cross Map Set.

MapSetSeparator A field in the Cross Map Sets Table that contains a character that acts as a separator between target codes in the Cross Map Targets Table.

MapSetType A field in the Cross Map Sets Table that indicates whether the Cross Maps associated with this Cross Map Set are all simple one to one maps or include, one to many and/or choices of alternative maps.

MapTargetId A field in the Cross Maps Table, which refers to the TargetId of a row in the Cross Map Targets Table that contains a target scheme mapping for a specified Concept.

MemberId A field in the Subset Members Table, which refers to the ComponentId of the Concept, Description or other Component that is a member of a specified Subset.

MemberStatus A field in the Subset Members Table, which indicates the inclusion, exclusion, priority or order of an identified Subset Member in a specified Subset.

Migration See Operational migration, Data migration and Predicate migration.

Moved Elsewhere A Status value applicable to a Component that has been moved to another Namespace. Concepts or Descriptions may be moved from an Extension to the SNOMED CT core, from the core to an Extension or between one Extension and another. Moves occur if responsibility for supporting the Concepts changes to another organization.

Namespace/Namespace Identifier A Namespace is a virtual block of identifiers allocated for creating Extensions to SNOMED CT. The Namespace Identifier is a seven digit number that identifies the Namespace and is used as part of each Extension SCTID. See Specification for Namespace within the SCTID on page 62. When an organization creates an extension to SNOMED CT, the new components in the extension need to be identified as part of that particular organization's extension. IHTSDO allocates a Namespace Identifier to the organization which then uses it to form its Extension SCTIDs. Most SCTID's issued by IHTSDO for the International Release are from the core namespace, as determined by the partition identifier portion of the SCTID, and do not use a Namespace identifier.

National Health Service (NHS) - UK Located in the United Kingdom, the National Health Service partnered with the College of American Pathologists in the development of SNOMED CT. The particular part of the NHS with responsibility for SNOMED CT has changed over the years. Some of these include the Coding and Classification Centre (CCC), the NHS Information Authority (NHS IA), and Connecting for Health (CfH).

Namespace Concept A Concept that exists to represent a SNOMED CT Namespace-identifier. All Namespace Concepts are direct subtypes of the Concept “Namespace Concept” which is a subtype of the Top-Level Concept “Special Concept”. Namespace Concepts are used as the target of Historical Relationships and References when a Component is moved from one Namespace to another.

Navigation The process of locating a Concept by traversing Relationships or Navigational links. For example, moving from a supertype Concept to more refined Concepts, from a specific Concept to a more general Concept or from a Concept to its Defining characteristics. Navigation Links allow navigation to follow intuitive routes through SNOMED CT even where there are no direct supertype or subtype Relationships.

Navigation Concept A Concept that exists only to support Navigation. A Navigation Concept is not suitable for recording or aggregating information. All Navigation Concepts: • Are direct subtypes of the concept “Navigational Concept” • Have not other supertype or subtype Relationships • Are linked to other Concepts only by Navigational Links

Navigation Link An association between two Concepts that supports Navigation between Concepts. Navigation Links generate a hierarchy which has three distinct differences from the subtype hierarchy defined by “IS A” Relationships this hierarchy: Does not effect the semantic definitions of Concepts; Specifies a display order Concepts within a set of Concepts linked to a common parent. Navigation Links are distributed as a Navigation Subset. Alternative Navigation Subsets may be specified and applied to vary the navigational hierarchy to meet the needs of particular groups of users.

Navigation Subset A Subset that specifies sets of Navigation Links between Concepts.

Operational migration Steps taken to enable an organization that either used a previous coding scheme (or no clinical coding scheme) to make use of SNOMED CT.

Partition identifier A pair of digits that indicate whether an SCTID identifies a Concept, Description, Relationship, Subset, History, or Extension component. The partition-identifier consists of the second and third digits from the right of the SCTID. See Partition-identifier on page 123.

Pending Move A Status value applicable to a Component that is thought to belong in a different Namespace but which is maintained with its current SCTID while awaiting addition to the new Namespace. A new Concept and associated Descriptions may be added with this Status where a missing SNOMED CT Concept is urgently required to support the needs of a particular Extension. Existing Concepts can also use this status when it is recognized that they should be moved to another namespace (organization) or to the core namespace. See also Moved Elsewhere on page 212.

Phrase equivalence Two words or phrases with a similar meaning. For example, “renal calculus” and “kidney stone”. See Word Equivalents.

Post-coordination Representation of a clinical meaning using a combination of two or more concept identifiers is referred to as a post-coordination. Some clinical meanings may be represented in several different ways. SNOMED CT technical specifications include guidance for transforming logical expressions to a common canonical form. Example: SNOMED CT includes the following concepts:

Fracture of bone (conceptId=125605004) FINDING SITE (conceptId= 363698007) Bone structure of femur (conceptId= 181255000)

SNOMED CT also includes a pre-coordinated concept for this disorder: Fracture of femur (conceptId= 71620000) It is possible to represent "fracture of femur" in different ways:

71620000 (pre-coordinated expression) and 125605004 : 363698007 = 181255000 (post-coordinated expression)

Pre-coordination Pre-coordination refers to an approach to representing a meaning that relies on a single concept code that is created and distributed prior to incorporation into a data recording system. Often this means that the code is included in the International Release by IHTSDO, but other organizations can also create pre-coordinated codes. Including commonly used concept meanings as pre-coordinated codes can make the terminology easier to use. SNOMED CT also allows the use of post-coordinated expressions to represent a meaning by using a combination of two or more concept identifiers. For examples see Post-coordination on page 214.

Predicate migration Steps taken to enable pre-existing data retrieval predicates (including queries, standard reports and decision support protocols) to be converted or utilized in a system using SNOMED CT.

Preferred Term The Term that is deemed to be the most clinically appropriate way of expressing a Concept in a clinical record. Preferred Term is one of the three types of terms that can be indicated by the DescriptionType field.

Primitive An expression, which may be just a single concept code, is primitive when its logic definition does not sufficiently express its meaning so that its subtypes can be computably recognized. A concept code's logic definition is made up of its defining relationships to other concept codes, via attributes and IS A relationships. Primitive concept codes also do not have the defining relationships that would be needed to computably distinguish them from their parent or sibling concepts. For example, if the Concept “Red sports car” is defined as [is a=car] + [color=red] this is Primitive but the same definition applied to the Concept “Red car” is sufficiently defined.

Qualifying characteristic An attribute-value relationship associated with a concept code to indicate to users that it may be applied to refine the meaning of the code. The set of qualifying relationships provide syntactically correct values that can be presented to a user for post-coordination. Example: “‘Revision status’ = ‘First revision’” is a possible qualifying characteristic of ‘Hip replacement’. A qualifying characteristic is contrasted with a defining characteristic. It is referred to in CTV3 as a ‘Qualifier’.

Read Code (5-byte) A five-character code allocated to a concept of term in CTV3. Note that codes allocated in Read Codes Version 2 and the Read Codes 4-Byte Set are also included in CTV3. In the case of 4-byte codes the original code is prefixed by a full stop (‘.’).

Read Codes 4-Byte Set The first version of the clinical coding scheme developed by Dr James Read. The Read Codes 4-Byte Set is UK Crown Copyright distributed by NHS and integrated into SNOMED CT.

Read Codes Version 2 The second version of the clinical coding scheme developed by Dr. James Read. Read Codes Version 2 is UK Crown Copyright distributed by the NHS and integrated into SNOMED CT.

Realm A sphere of authority, expertise, or preference that influences the range of Components required, or the frequency with which they are used. A Realm may be a nation, an organization, a professional discipline, a specialty, or an individual user.

RealmId A field in the Subsets Table that identifies the Realm within which the specified Subset is applicable.

Realm Concept Subset A Subset of Concepts applicable to a particular Realm.

Realm Description Subset A Subset of Descriptions applicable to a particular Realm.

Realm Relationship Subset A Subset of Relationships applicable to a particular Realm (for future use).

Reason A field in the Component History Table which provides a text description of the reason for a change in the Status of a Component.

Reference An association between a non-current SNOMED CT Component and a current Component that duplicates it, replaces it or is related to it. Each Reference is represented by a row in the References Table.

ReferencedId A field in the References Table that identifies the current Component which replaces it or is duplicated by a non-current Component.

References Table A data table consisting of rows each of which represents a Reference between an inactive Component and a Component that was active for the release in which the first was made inactive. The References Table is part of the History Mechanism.

ReferenceType A field in the References Table that indicates whether a specified non-current Component was replaced by, duplicated by, similar to or an alternative form of the referenced current Component.

Refinability A field in the Relationships Table, which indicates whether it is permissible to refine the value of a Defining characteristic or qualifying characteristic to represent a more refined Concept.

Relationship An association between two Concepts (each identified by a ConceptId). The nature of the association is indicated by a RelationshipType. Each Relationship is represented by a row in the Relationships Table.

RelationshipId A SNOMED CT Identifier that uniquely identifies a Relationship. RelationshipID is the key of the Relationships Table. Each row in the Relationships Table represents a relationship triplet (ConceptID1 RelationshipType - ConceptID2).

Relationships Table A data table consisting of rows, each of which represents a Relationship.

Relationship Group Relationships, for a concept that are logically associated with each other. The RelationshipGroup field in the Relationships Table is used to group these rows together for a concept. For example, where a particular type of prosthesis is inserted a joint, the Defining characteristics describing the prosthesis type would be in one group whereas those describing the location or laterality of the joint would be in another group.

Relationship Type The nature of a Relationship between two Concepts. Relationship Types are represented in SNOMED CT by Concept codes. In the Relationships Table, the RelationshipType field contains the ConceptId for the concept in SNOMED that forms the relationship between two other concepts (ConceptID1 and ConceptID2). For defining and qualifying relationships, the Relationship Type is an Attribute code. RelationshipType should not be confused with CharacteristicType. See Table 11: CharacteristicType Values on page 84.

ReleaseVersion A field in the Component History Table which indicates the SNOMED CT release in which a Component was added or changed.

Release Version An identifiable set of SNOMED CT tables distributed on or after a particular date for use in SCT Enabled Applications. Each Release Version is referred to by the ISO format date of which this set of files was distributed (or was scheduled for distribution). Thus release version "20030131" refers to the version released on January 31, 2003.

Retired Concept A Concept that has been made inactive with no reason specified. Concepts that are no longer current should be called “non-current” or “inactive” rather than “retired.” (See Inactive Concept.)

Root Concept The single concept code that is at the top of the SNOMED CT Concepts hierarchy.

Root Metadata Code The single concept code that is at the top of the Metadata Concepts hierarchy.

SCT-Concept SCT-Description SCT-Relationship SCT-Subset SCT-History A Concept, Description, Relationship, or Subset distributed by the IHTSDO as part of SNOMED CT. The prefix "SCT-" is used only where it is necessary to distinguish clearly between elements distributed by the IHTSDO and Extensions (denoted by the prefix "Extra-"). For further information refer to the glossary entries for the unprefixed names.

SCT Enabled Application A software application designed to support the use of SNOMED CT.

SNOMED® An acronym for the Systematized Nomenclature of Medicine originally developed by the College of American Pathologists.

SNOMEDID A field in the Concepts Table that contains the SNOMED RT identifier for the Concept.

SNOMED Clinical Terms SNOMED CT® The clinical terminology maintained and distributed by the IHTSDO, created as a result of the merger of SNOMED RT and Clinical Terms Version 3.

SNOMED CT Core Tables Refers to the SNOMED CT Concept, Relationship and Description Tables.

SNOMED CT Derivative Documentation, subsets, cross-mappings, extensions, and other files.

SNOMED CT Identifier (SCTID) A unique integer identifier applied to each SNOMED CT component (Concept, Description, Relationship, Subset, etc.). The SCTID can include an item identifier, namespace identifier, a check-digit and a partition identifier. It does not always include a namespace identifier. See The SNOMED Clinical Terms Identifier (SCTID) on page 120.

SNOMED International SNOMED International is the version of SNOMED® that was first released in 1993 and which, as version 3.5 released in 1998, was the immediate predecessor of SNOMED RT. SNOMED International was also the name of the organization (now SNOMED Terminology Solutions) within the College of American Pathologists that was responsible for SNOMED CT until the transfer of the terminology to the IHTSDO in 2007.

SNOMED Reference Terminology (SNOMED RT) The latest version of SNOMED® prior to the collaborative effort to develop SNOMED Clinical Terms. One of the source terminologies, along with CTV3, used to develop SNOMED CT. SNOMED RT was sponsored by the College of American Pathologists (CAP).

Status The Status of a Component indicates whether it is in current use and, if not, provides a general indication of the reason that it is not recommended for current use. The Status of a Concept is referred to as ConceptStatus and the Status of a Description is referred to as DescriptionStatus.

Subset A group of Components (e.g. Concepts, Descriptions or Relationships) that share a specified common characteristic or common type of characteristic. Subsets represent information that affects the way the Components are displayed or otherwise accessible within a particular realm, specialty, application or context.

SubsetId A SNOMED CT Identifier that uniquely identifies a Subset.

SubsetName A field in the Subsets Table that contains a human readable name for the Subset.

SubsetOriginalId A field in the Subsets Table that identifies the first version of the Subset on which this Subset is based. For the first version of a Subset the SubsetOriginalId and SubsetId fields contain the same value. For each subsequent version the Subset Version is incremented and a new SubsetId is allocated but the SubsetOriginalId field retains the same value in all versions.

Subsets Table A data table consisting of rows each of which represents a Subset.

Subset Definition A series of clauses that specifies the nature of a Subset and determines its membership. A Subset Definition is an alternative form of representation applicable to many Subsets. See also Subset Definition File.

Subset Definition Clause A statement that refers directly or indirectly to one or more Concepts, Descriptions or Relationships and indicates whether the referenced item(s) should be removed from or added to a specified Subset. In the case of additions to a Subset the clause also specifies the MemberStatus to be assigned to those additions.

Subset Definition File A file containing a series of clauses that define the nature and membership of a Subset. The Subset Definition File is an XML document that contains the Subset Definition for a single Subset. A Subset Definition File can be used to generate the appropriate Subsets Table row and Subset Members Table rows to represent a Subset. Therefore applications need not support this alternative form of Subset representation.

Subset Member A Concept, Description, Relationship or another Subset that is part of a specified Subset.

Subset Members Table A data table consisting of rows each of which refers to a single Subset Member.

Subset Type, Type of Subset An indication of the type of component that may be a member of a Subset.

Subset Version A version number assigned to a particular release of a Subset.

Subtype A specialization of a concept, sharing all the definitional attributes of the parent concept, with additional defining characteristics. For example, bacterial infectious disease is a subtype of infectious disease. Bacterial septicemia, bacteremia, bacterial peritonitis, etc. are subtypes of bacterial infectious disease (and infectious disease as well). Subtype is sometimes used to refer to the concepts in a hierarchy that are directly related to a parent concept via the “IS A” relationship. In this usage, it is distinguished from “descendants” which explicitly includes subtypes of subtypes.

Sufficiently defined A concept is sufficiently defined if its logic definition is sufficient to computably recognize (automatically subsume) all its subtypes. The logic definition must also differentiate the concept from its immediate supertype(s). A concept which is not sufficiently defined is primitive. For example, if the concept “Red car” is defined as [is a=car] and [color=red] it is sufficiently defined but the same definition applied to the Concept “Red sports car” is primitive.

Synonym A Term that is an acceptable alternative to the Preferred Term as a way of expressing a Concept. Synonyms allow representations of the various ways a concept may be described. Synonyms and Preferred Terms (unlike FSNs) are not necessarily unique. More than one concept might share the same Preferred term or Synonym.

TargetAdvice A field in the Cross Map Targets Table that may contain human readable advice on the circumstances in which this Cross Map Target is applicable.

TargetCodes A field in the Cross Map Targets Table that contains one or more codes or identifiers in the target scheme or classification. If there is more than one Target Code they are separated by a separator specified in the associated row of the Cross Map Sets Table.

TargetId A SNOMED CT Identifier that uniquely identifies a Cross Map Target.

TargetRule A field in the Cross Map Targets Table that may contain computer processable rules specifying the circumstances in which this Cross Map Target is applicable.

TargetSchemeId A field in the Cross Map Targets Table that identifies the target coding scheme or classification to which this Cross Map Target applies.

Target Code A code or other identifier within a Target Scheme.

Target Scheme A terminology, coding scheme or classification to which some or all SNOMED CT Concepts are cross-mapped. Mappings from SNOMED CT to a Target Scheme are represented by one or more Cross Map Sets.

Term A text string that represents the Concept. The Term is part of the Description. There are multiple descriptions per Concept.

Terminology server Software that provides access to SNOMED CT (and/or to other terminologies). A Terminology server typically supports searches and Navigation through Concepts. A server may provide a user interface (e.g. a browser or set of screen controls) or may provide low-level software services to support access to the terminology by other applications. See the SNOMED CT Technical Implementation Guide.

Top-Level Concept Code A Concept Code that is directly related to the Root Concept Code by a single Relationship of the Relationship Type "IS A". All Concept Codes (except for metadata concepts) are descended from at least one Top-Level Concept Code via at least one series of Relationships of the Relationship Type "IS A".

Top-Level Metadata Code A Concept Code that is directly related to the Root Metadata Code by a single Relationship of the Relationship Type "IS A". All Metadata Concept Codes are descended from at least one Top-Level Metadata Concept Code via at least one series of Relationships of the Relationship Type "IS A".

Unicode A standard character set, which represents most of the characters used in the world using a 16-bit encoding. Unicode can be encoded in using UTF-8 to more efficiently store the most common ASCII characters.

UTF-8 A standard method of encoding Unicode characters in a way optimized for the ASCII character set. UTF-8 is described in Unicode UTF-8 encoding on page 129.

UTF-16 A standard method of directly encoding Unicode using two bytes for every character. See also UTF-8 on page 220.

WordBlockNumber A field in the Word Equivalents Table, which links together several rows which have an identical or similar meaning.

WordKey Table A data table relating each word used in SNOMED CT (other than Excluded Words) to the Descriptions. See Word Search Tables – Summary on page 57.

WordRole A field in the Word Equivalents Table, which specifies the usual usage of this word, abbreviation or phrase, or the usage in which it has a similar meaning to the text in one or more other rows of the table that share a common WordBlockNumber.

WordText A field in the Word Equivalents Table, which contains a word, phrase, acronym or abbreviation that is considered to be similar in meaning to the text in one or more other rows of the table that share a common WordBlockNumber.

WordType A field in the Word Equivalents Table, which specifies whether this row contains a word, phrase, acronym or abbreviation.

Word Equivalent A word or abbreviation that is stated to be equivalent to one or more other words, phrases or abbreviations for the purposes of textual searches of SNOMED CT. Word Equivalents and Phrase equivalents are represented as rows in the Word Equivalents Table.

Word Equivalents Table A data table in which each row represents a Word Equivalent. See Word Equivalents on page 57.

Input value (without check-digit)
Value with check-digit
Result of check