SNOMED Core Structures NAHLN January 2005 Las Vegas, NV.

Slides:



Advertisements
Similar presentations
Copyright © 2001 College of American Pathologists Presentation Objectives By the end of this presentation you should know: –The content of the 3 core SNOMED.
Advertisements

SNOMED Core Structures 2 nd AAHA Software Vendors Summit – April 21, 2009.
© 2002 by Prentice Hall 1 SI 654 Database Application Design Winter 2003 Dragomir R. Radev.
BUSINESS DRIVEN TECHNOLOGY Plug-In T4 Designing Database Applications.
Describing Process Specifications and Structured Decisions Systems Analysis and Design, 7e Kendall & Kendall 9 © 2008 Pearson Prentice Hall.
Chapter 3 Data Modeling Copyright © 2014 McGraw-Hill Education. All rights reserved. No reproduction or distribution without the prior written consent.
Database Systems: Design, Implementation, and Management Eighth Edition Chapter 4 Entity Relationship (ER) Modeling.
3/5/2009Computer systems1 Analyzing System Using Data Dictionaries Computer System: 1. Data Dictionary 2. Data Dictionary Categories 3. Creating Data Dictionary.
Introduction to the ABAP Data Dictionary
Lecturer: Sebastian Coope Ashton Building, Room G.18 COMP 201 web-page: Lecture.
The Relational Model System Development Life Cycle Normalisation
Maintenance Modifying the data –Add records –Delete records –Update records Modifying the design –Add fields into tables –Remove fields from a table –Change.
Chapter 9 Describing Process Specifications and Structured Decisions
Entity Relationship Diagrams Basic Elements and Rules.
Introduction to XLink Transparency No. 1 XML Information Set W3C Recommendation 24 October 2001 (1stEdition) 4 February 2004 (2ndEdition) Cheng-Chia Chen.
Agenda for Week 1/31 & 2/2 Learn about database design
Introduction to Databases CIS 5.2. Where would you find info about yourself stored in a computer? College Physician’s office Library Grocery Store Dentist’s.
The Relational Database Model. 2 Objectives How relational database model takes a logical view of data Understand how the relational model’s basic components.
Copyright © Cengage Learning. All rights reserved.
Chapter 4 Relational Databases Copyright © 2012 Pearson Education, Inc. publishing as Prentice Hall 4-1.
1 Chapter 2 Reviewing Tables and Queries. 2 Chapter Objectives Identify the steps required to develop an Access application Specify the characteristics.
Database Systems: Design, Implementation, and Management Eighth Edition Chapter 3 The Relational Database Model.
3 1 Chapter 3 The Relational Database Model Database Systems: Design, Implementation, and Management, Seventh Edition, Rob and Coronel.
Establishing Table Structures Chapter 7 Database Design for Mere Mortals.
Introduction to XML This material is based heavily on the tutorial by the same name at
Chapter 4 Relational Databases Copyright © 2012 Pearson Education 4-1.
3/18/19990© 1999, Health Level Seven, Inc. Introduction: Vocabulary domains Marital Status –single (never married) –married –divorced –separated “Vocabulary”
Managing SNOMED in your system. 2 nd AAHA Software Vendors Summit – April 21, 2009.
Chapter 3 The Relational Model Transparencies Last Updated: Pebruari 2011 By M. Arief
Karen Gibson.  Significant investment in eHealth is underway  Clinical records: ◦ Not only a record for the author ◦ Essential to inform the next person.
Profiling Metadata Specifications David Massart, EUN Budapest, Hungary – Nov. 2, 2009.
THE RELATIONAL DATA MODEL CHAPTER 3 (6/E) CHAPTER 5 (5/E) 1.
Lecture 7 Integrity & Veracity UFCE8K-15-M: Data Management.
HTTP Extension Framework Name: Qin Zhao Id:
Discovering Computers Fundamentals Fifth Edition Chapter 9 Database Management.
The Relational Database Model
1 The Relational Database Model. 2 Learning Objectives Terminology of relational model. How tables are used to represent data. Connection between mathematical.
© 2011 Pearson Education, Inc. Publishing as Prentice Hall 1 Chapter 2: Modeling Data in the Organization.
9/7/2012ISC329 Isabelle Bichindaritz1 The Relational Database Model.
MIS 327 Database Management system 1 MIS 327: DBMS Dr. Monther Tarawneh Dr. Monther Tarawneh Week 2: Basic Concepts.
(Spring 2015) Instructor: Craig Duckett Lecture 10: Tuesday, May 12, 2015 Mere Mortals Chap. 7 Summary, Team Work Time 1.
3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.
Part4 Methodology of Database Design Chapter 07- Overview of Conceptual Database Design Lu Wei College of Software and Microelectronics Northwestern Polytechnical.
+ Information Systems and Databases 2.2 Organisation.
3 1 Chapter 3 The Relational Database Model Database Systems: Design, Implementation, and Management, Seventh Edition, Rob and Coronel.
Database Systems: Design, Implementation, and Management Eighth Edition Chapter 3 The Relational Database Model.
The relational model A data model (in general) : Integrated collection of concepts for describing data (data requirements). Relational model was introduced.
©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart 4-1 Relational Databases.
VTSL Enhancing the AAHA & AAEP Diagnostic Subsets 2013 Talbot Symposium Jeff R. Wilcke DVM, MS, DACVCP; Julie M. Green DVM, MS; Suzanne L. Santamaria DVM,
Introduction to the ABAP System. Slide 2 The Data Browser Allows us to look at the underlying table contents Use transaction code SE16.
©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart 4-1 Relational Databases.
Chapter 3 The Relational Database Model. Database Systems, 10th Edition 2 * Relational model * View data logically rather than physically * Table * Structural.
SNOMED CT Vendor Introduction 27 th October :30 (CET) Implementation Special Interest Group Tom Seabury IHTSDO.
FROM ONE NOMENCLATURES TO ANOTHER… Drs. Sven Van Laere.
1 The Relational Data Model David J. Stucki. Relational Model Concepts 2 Fundamental concept: the relation  The Relational Model represents an entire.
Understanding the Value and Importance of Proper Data Documentation 5-1 At the conclusion of this module the participant will be able to List the seven.
Canadian SNOMED CT® Extensions Challenges & Lessons learned Presentation to Implementation SIG October 2012 Presented by Linda Parisien and Beverly Knight.
Modeling data in the Organization
SNOMED Core Structures RF2
Dr Linda Bird, IHTSDO Implementation Specialist
Logical Database Design and the Rational Model
UNIFIED MEDICAL LANGUAGE SYSTEMS (UMLS)
Tables and Their Characteristics
Lecture 2 The Relational Model
Chapter 3 The Relational Database Model
A bit more about Read Codes and SNOMED CT
Copyright © Cengage Learning. All rights reserved.
Chapter 11 Describing Process Specifications and Structured Decisions
Database Systems: Design, Implementation, and Management
Presentation transcript:

SNOMED Core Structures NAHLN January 2005 Las Vegas, NV

SNOMED Core

Concepts Table Each row in this table represents a medical 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.

SNOMED Core A concept is described by the term (string) in 2-n descriptions At least the Fully Specified Name (FSN) + Preferred Term Each description refers to (only) 1 concept.

SNOMED Core A concept is the source of 1-n relationships (except the root concept). A concept is the target of 1-n relationships. A concept represents the type of relationship. A relationship refers to 3 concepts: a source, a target, and a relationship type.

Terminology of Terminology Concept embodiment of a particular meaning embodiment of a particular meaning Really a “virtual” element in the system Really a “virtual” element in the system The string in concepts table is a member of the related list of descriptions. The string in concepts table is a member of the related list of descriptions.Description Any string used to represent a concept Any string used to represent a conceptRelationship (in SNOMED) an object – attribute – value triple connecting two concepts through an attribute (in SNOMED) an object – attribute – value triple connecting two concepts through an attribute Relationships in SNOMED are explicit rather than implicit (as was the case in SNOMED III) Relationships in SNOMED are explicit rather than implicit (as was the case in SNOMED III)

Concepts Table Fields Key Fields ConceptIdThe unique SNOMED Clinical Terms Identifier for this Concept. Data Fields ConceptStatusThe status of a Concept indicates whether it is in active use and, if not, indicates the reason for withdrawal from current use. FullySpecifiedNameA unique phrase that describes a Concept in a way that is intended to be unambiguous. CTV3IDThe Read Code for this Concept. SNOMEDIDThe current SNOMED identifier for this Concept. IsPrimitiveIndicates whether a Concept is Primitive or Fully defined by its current set of Defining characteristics.

Relationships Table Key Fields RelationshipIdThe unique SNOMED CT Identifier of this Relationship. Data Fields ConceptId1The unique SNOMED CT Identifier of the Concept which is the source of this Relationship. RelationshipTypeThe unique SNOMED CT Identifier of the Concept which represents the type of relationship between the related Concepts. ConceptId2The unique SNOMED CT Identifier of the Concept which is the target of this Relationship. CharacteristicTypeAn indication of whether a Relationship specifies a defining characteristic of the source Concept or a possible qualifying characteristic of that Concept. RefinabilityAn indication of whether it is possible to refine the target Concept when this relationship is used as a template for clinical data entry. RelationshipGroupAn integer value that links together Relationships which are part of a logically associated Relationship group.

Concept -> Relationship Concept ID Relationship ID Concept ID Relationship Table Fracture (morphology) M Associated Morphology G-C Fracture of Femur DD Concept Name SNOMED ID SCT ID Concepts Table

Relationship Groups A mechanism for retaining relationships between definition “parts” Avoids relationship “nesting”

Relationship Groups Is aContusion to heart Is aOpen wound of trunk Group 1 Associated morphologyOpen wound Finding siteThoracic structure Group 2 Associated morphologyContusion - lesion Finding siteHeart structure Contusion to heart with open wound into thorax

Relationship and Characteristic Types RelationshipsType field is the concept code that specifies the attribute in the triple. CharacteristicType tells whether the relationship is: Defining (0) Defining (0) Qualifying (1) Qualifying (1) Historical (2 – history table only) Historical (2 – history table only) Additional (3 – for facts that cannot be defining) Additional (3 – for facts that cannot be defining)

Relationships - Refineability Indicates whether the target concept can be further refined when the relationship is used in a clinical template Not refineable (0) Not refineable (0) Optional (2) Optional (2) Mandatory (3) Mandatory (3) Not our problem just now.

Descriptions Table Key Fields DescriptionIdThe unique SNOMED CT Identifier for this Description. Data Fields DescriptionStatusThe status of a Description indicates whether it is in active use and, if not, indicates the reason for withdrawal from current use. ConceptIdThe unique SNOMED CT Identifier of the associated Concept. (Foreign key to Concepts Table). TermThe text of a Term used to describe the associated Concept. InitialCapitalStatusAn indication of whether the capitalization status of the first character of the Term is significant. DescriptionTypeAn indication of whether the Term is the Fully Specified Name, Preferred Term or Synonym for the Concept to which this Description applies. LanguageCodeAn indication of a Language or Dialect in which this Description is valid. The language or dialect subset ultimately defines the descriptions for each concept.

Concepts -> Descriptions D2-0007F Pneumonia (concept) 2 Synonym In Local Extension xxxxxxzzz11x 2 Synonym in NAHLN Extension xxxxxxyyy11x 2 Synonym in Core xxxxxx01x 1Pneumonia Pneumonia (Disorder) = “preferred” description (term) – preferred by SNOMED, perhaps not your users 2 = synonym (alternate) 3 = fully specified name

Component History Table (future use) Key Fields ComponentIDThe unique SNOMED CT Identifier for the changed Component. ReleaseVersionThe version of SNOMED CT in which this change was made. Data Fields ChangeTypeAn indication of the nature of the change. StatusThe status of this Component after the change. ReasonAn optional text Description of the reason for the change.

Historical Relationships Key Fields RelationshipIdThe unique SNOMED CT Identifier of this Relationship. Data Fields ConceptId1The unique SNOMED CT Identifier of the Concept which is the source of this Relationship. RelationshipTypeThe unique SNOMED CT Identifier of the Concept which represents the type of relationship between the related Concepts. ConceptId2The unique SNOMED CT Identifier of the Concept which is the target of this Relationship. CharacteristicTypeAn indication of whether a Relationship specifies a defining characteristic of the source Concept or a possible qualifying characteristic of that Concept. RefinabilityAn indication of whether it is possible to refine the target Concept when this relationship is used as a template for clinical data entry. RelationshipGroupAn integer value that links together Relationships which are part of a logically associated Relationship group.

Historical Relationships Allowed attribute values SAME AS (redundant) MAYBE A (ambiguous - 2 or more) REPLACED BY (major changes) WAS A (IS A no longer valid) MOVED TO (namespace change) MOVED FROM (namespace change)

SCTID 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 result of rules for the partition-identifier and check- digit, many integers within this range are not valid SCTIDs.

SCTID 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 be derived from the table in which a component is distributed. Partitioning the SCTID 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.

SCTID SCTID for centrally distributed component.

SCTID SCTID for a component in an extension.

SCTID Partition Values 00 A concept 01 A description 02 A relationship 03 A subset 04 A Cross Map set 05 A Cross Map target 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

Indexes Excluded words Description word key Concept word key Description dual key Concept dual key