1 / 26

SNOMED Core Structures

Gain insights into SNOMED Core concepts, descriptions, and relationships. Explore terminology, relationship groups, and historical aspects.

rwelliver
Download Presentation

SNOMED Core Structures

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. SNOMEDCore Structures NAHLN January 2005 Las Vegas, NV

  2. SNOMED Core

  3. 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.

  4. 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.

  5. 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.

  6. Terminology of Terminology • Concept • embodiment of a particular meaning • Really a “virtual” element in the system • The string in concepts table is a member of the related list of descriptions. • Description • Any string used to represent a concept • Relationship • (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)

  7. Concepts Table Fields

  8. Relationships Table

  9. Concepts Table SCT ID SNOMED ID Concept Name 71620000 DD-13100 Fracture of Femur 116676008 G-C504 Associated Morphology 72704001 M-12000 Fracture (morphology) Relationship Table Concept ID Relationship ID Concept ID 71620000 116676008 72704001 Concept -> Relationship

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

  11. Relationship Groups Contusion to heart with open wound into thorax

  12. 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) • Qualifying (1) • Historical (2 – history table only) • Additional (3 – for facts that cannot be defining)

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

  14. Descriptions Table

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

  16. Component History Table(future use)

  17. Historical Relationships

  18. 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)

  19. 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.

  20. 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.

  21. SCTID SCTID for centrally distributed component.

  22. SCTID SCTID for a component in an extension.

  23. SCTID Partition Values

  24. Indexes • Excluded words • Description word key • Concept word key • Description dual key • Concept dual key

More Related