Presentation on theme: "Jane Hunter Hafsa Qureshi. Jane Hunter M.Sc. eHealth candidate (part-time) Undergrad in Computer Engineering at McMaster Have also done an MBA."— Presentation transcript:
Jane Hunter Hafsa Qureshi
Jane Hunter M.Sc. eHealth candidate (part-time) Undergrad in Computer Engineering at McMaster Have also done an MBA at McMaster Working as a software developer at NCR where we are currently creating a Java development infrastructure for next generation banking products Married for 10 years as of June, no kids
Hafsa Qureshi M.Sc. eHealth candidate (full-time, thesis student) B.Sc. Health Informatics from University of Waterloo Trying to look for internship employment Recently married
Introduce SNOMED CT Show some of the uses of SNOMED Discuss some disadvantages of SNOMED
VocabulariesWhat is SNOMED CT?ExamplesDatabase TablesImplementing an Application with SNOMEDQuestions
Systematized Nomenclature of Medicine Clinical Terms SNOMED CT Medical Subject Headings MeSH Unified Medical Language System UMLS Logical Observation Identifiers Names and Codes LOINC Enhanced Canadian version of the 10th revision of the International Statistical Classification of Diseases and Related Health Problems ICD-10-CA -
Systematized Nomenclature of Medicine Clinical Terms controlled medical vocabulary licensed and supported by the International Health Terminology SDO provides a common language that enables a consistent way of indexing, storing, retrieving and aggregating clinical data across specialties and sites of care comprehensive, multi-lingual clinical terminology that provides clinical content and expressivity for clinical documentation and reporting
Medical Subject Headings Comprehensive controlled vocabulary for the purpose of indexing journal articles and books in the life sciences Created and updated by the United States National Library of Medicine (NLM) serves as a thesaurus that facilitates searching used by the MEDLINE/PubMed article database and by NLM's catalog of book holdings
Unified Medical Language System compendium of many controlled vocabularies in the biomedical sciences provides a mapping structure among these vocabularies and allows one to translate among the various terminology systems Comprehensive thesaurus and ontology of biomedical concepts provides facilities for natural language processing intended to be used mainly by developers of systems in medical informatics
Logical Observation Identifiers Names and Codes universal standard for identifying medical laboratory observations developed and is maintained by the Regenstrief Institute, a US non-profit medical research organization publicly available at no cost. include medical and laboratory code names, nursing diagnosis, nursing interventions, outcomes classification, and patient care data set.
International Statistical Classification of Diseases and Related Health Problems provides codes to classify diseases and a wide variety of signs, symptoms, abnormal findings, complaints, social circumstances, and external causes of injury or disease every health condition can be assigned to a unique category and given a code, up to six characters long
Why are there so many vocabularies?
Methods: assembled 1929 source concept records from a variety of clinical information records were coded in each scheme by an investigator and checked by the coding scheme owner. codings were then scored by an independent panel of clinicians for acceptability
Conclusion: No major terminology source can lay claim to being the ideal resource for a computer-based patient record. SNOMED is considerably more complete, has a compositional nature and a richer taxonomy. It suffers from less clarity, resulting from a lack of syntax and evolutionary changes in its coding scheme. READ has greater clarity and better mapping to administrative schemes, is rapidly changing and is less complete. UMLS is a rich lexical resource, with mappings to many source vocabularies. It provides definitions for many of its terms. However, due to the varying granularities and purposes of its source schemes, it has limitations for representation of clinical concepts within a computer- based patient record.
SNOMED CT is a clinical healthcare terminology a resource with comprehensive, scientifically- validated content essential for electronic health records a terminology that can cross-map to other international standards already used in more than fifty countries
Each year, avoidable deaths and injuries occur because of poor communication between healthcare practitioners. The delivery of a standard clinical language for use across the world's health information systems can therefore be a significant step towards improving the quality and safety of healthcare. SNOMED CT aims to improve patient care through the development of systems to accurately record health care encounters. Ultimately, patients will benefit from the use of SNOMED CT, for building and facilitating communication and interoperability in electronic health data exchange.
Consists of over a million medical Concepts The Concepts are arranged in a type or IS-A hierarchy For example means myocardial infarction (MI). For example, Viral pneumonia IS-A Infectious pneumonia IS-A Pneumonia IS-A Lung disease.
concepts are organized in hierarchies, from the general to the specific allows very detailed (“granular”) clinical data to be recorded and later accessed or aggregated at a more general level
Concepts may have multiple parents, for example Infectious pneumonia is also an Infectious disease. The Concept graph must be acyclic — a parent cannot be its own child.
From abscess to zygote, SNOMED CT includes more than 311,000 unique concepts. There are almost 800,000 descriptions in SNOMED CT, including synonyms that can be used to refer to a concept.
a “concept” is a clinical meaning identified by a unique numeric identifier (ConceptID) that never changes. formally defined in terms of their relationships with other concepts. give explicit meaning which a computer can process and query on. Every concept also has a set of terms that name the concept in a human-readable way. ConceptIDs do not contain hierarchical or implicit meaning. The numeric identifier does not reveal any information about the nature of the concept.
Concept descriptions are the terms or names assigned to a SNOMED CT concept “Term” in this context means a phrase used to name a concept A unique DescriptionID identifies a description Multiple descriptions might be associated with a concept identified by its ConceptID
Some of the descriptions associated with ConceptID : Fully Specified Name: Myocardial infarction (disorder) DescriptionID Preferred term: Myocardial infarction DescriptionID Synonym: Cardiac infarction DescriptionID Synonym: Heart attack DescriptionID Synonym: Infarction of heart DescriptionID Each of the above descriptions has a unique DescriptionID
Concepts are represented by a unique human- readable Fully Specified Name (FSN). Each concept has one unique FSN intended to provide an unambiguous way to name a concept. not necessarily the most commonly used for that concept Each FSN ends with a “semantic tag” in parentheses at the end of the concept to indicate the semantic category to which the concept belongs For example, Hematoma (morphologic abnormality) is a FSN that represents the description of what the pathologist sees at the tissue level Hematoma (disorder) is a FSN which indicates the concept that would be used to code the clinical diagnosis of a hematoma by a general practitioner.
Each concept has one Preferred Term meant to capture the common word or phrase used by clinicians to name that concept. For example, the concept Repair of common bile duct (procedure) has the Preferred term “Choledochoplasty” to represent a common name clinicians use to describe the procedure. Unlike FSNs, Preferred Terms are not necessarily unique Occasionally, the Preferred Term for one concept may also be a Synonym or the Preferred Term for a different concept. For example Cold sensation quality (qualifier value) has a preferred term of “Cold.” Common cold (disorder) also has a synonym of “Cold.” In both cases, “cold” represents a common clinical phrase used to capture the meaning of the FSN.
Synonyms represent any additional terms that represent the same concept as the FSN. are not required to be unique across concepts. Example: Some of the Synonyms associated with ConceptID which has the Fully Specified Name: Myocardial infarction (disorder) are: Synonym: Cardiac infarction DescriptionID: Synonym: Heart attack DescriptionID: Synonym: Infarction of heart DescriptionID:
there are about 1,360,000 links or semantic relationships between the SNOMED CT concepts relationships provide formal definitions and other characteristics of the concept
four types of relationships Defining characteristics are IS_A relationships and defining attributes. Qualifying characteristics are non-defining, qualifying attributes. constrains the possible values an implementer can select in assigning a qualifying characteristic to a concept Historical relationships relate inactive concepts to active concepts. For example, a concept may be inactivated because it is a duplicate. A “same-as” relationship would be created between the 2 concepts. Additional relationships are other non-defining characteristics For example, PART OF which is retained for backward compatibility with SNOMED RT.
Each concept in SNOMED CT is logically defined through its relationships to other concepts. Every active SNOMED CT concept (except the “SNOMED CT Concept” Root concept) has at least one IS_A relationship to a supertype concept. establish IS_A relationships with one or more defining concepts (called supertypes) and modeling the difference with those supertypes through defining attributes.
“Supertype-Subtype relationships” or “Parent- Child relationships.” IS_A relationships are the basis of the SNOMED CT’s hierarchies.
Attributes relate two concepts and establish the type of relationship between them. Example: Lumbar discitis (disorder) (a concept in the Clinical finding hierarchy) is related to concepts in the Body structure hierarchy through two attributes: FINDING SITE and ASSOCIATED MORPHOLOGY. Lumbar discitis (disorder) FINDING SITE Structure of lumbar intervertebral disc (body structure) ASSOCIATED MORPHOLOGY Inflammation (morphologic abnormality) The two attributes FINDING SITE and ASSOCIATED MORPHOLOGY and their assigned values provide definition for the concept Lumbar discitis (disorder).
Example: the concept Pneumonia (disorder) is characterized with the attribute FINDING SITE. Since pneumonia is a disorder of the lung, FINDING SITE has the value Lung structure (body structure). Pneumonia (disorder) FINDING SITE Lung structure (body structure)
Clinical finding/disorderProcedure/interventionObservable entityBody structurez OrganismSubstance Pharmaceutical/biologic product Specimen Special ConceptPhysical ObjectPhysical forceEvent Environment or geographical location Social contextStaging and Scales
Concepts in this hierarchy represent the result of a clinical observation, assessment or judgment, and include both normal and abnormal clinical states contains the sub-hierarchy of Disease. Examples of Clinical finding concepts: Clear sputum (finding) Normal breath sounds (finding) Poor posture (finding) Examples of Disease concepts: Tuberculosis (disorder) Non-Hodgkin's lymphoma (disorder)
The Event hierarchy includes concepts that represent occurrences (excluding procedures and interventions) Examples of Event concepts: Flood (event) Bioterrorisk attach (event) Earthquake (event)
This hierarchy contains such sub- hierarchies as Assessment scales and Tumor staging Examples of Assessment scales concepts: Glasgow coma scale (assessment scale) Stanford Binet intelligence scale (assessment scale) Examples of Tumor staging concepts: International Federation of Gynecology and Obstetrics (FIGO) staging Dukes staging system (tumor staging)
provides explicit links (cross maps) to health-related classifications and coding schemes in use around the world e.g. diagnosis classifications such as ICD-9-CM, ICD-O3, and ICD-10, as well as the OPCS-4 classification of interventions. Additional cross-maps are also under development or consideration Cross-maps facilitate reuse of SNOMED CT-encoded data for other purposes, such as reimbursement or statistical reporting
SNOMED CT is a multinational, multilingual terminology has a built-in framework to manage different languages and dialects The International Release includes a set of language-independent concepts and relationships available in US English, UK English, Spanish and Danish Currently translations into French, Swedish, Lithuanian, and several other languages planning to translate the standard into other languages
This 85 year ( year) old ( old) ( age) female ( female) was admitted via the emergency room ( emergency room admission) from the nursing home ( nursing home) with shortness of breath ( dyspnea), confusion ( onset of confusion), and congestion ( respiratory tract congestion). There was no history of ( no history of) fever ( fever) or cough ( cough) noted. Patient also has a history of ( history of) senile dementia ( senile dementia) and COPD ( chronic obstructive lung disease). Prior to ( before) admission ( admission – action), the patient was taking the following medications: Prednisone ( prednisone), Lasix ( furosemide), Haldol ( oral haloperidol), and Colace ( docusate). Patient has also been taking Lorazepam 0.5-mg tablet ( oral form lorazepam) 2x a day ( twice a day) as needed for anxiety ( anxiety). Patient is also noted to have a vitamin C deficiency ( ascorbic acid deficiency).
Is SNOMED too complicated?
SNOMED CT is distributed as a set of tab-delimited text files that can be imported into a relational database. the Concepts table, the Descriptions table, and the Relationships table, are commonly referred to as the “core” tables. The association of a set of Descriptions and a set of Relationships to each Concept is implemented using the ConceptID which is the primary or foreign key in the three tables
The Concepts Table contains all the concepts in SNOMED CT Primary Key Concept ID Foreign key to description table; serves to provide a human readable name for each concept Fully Specified Name Indicates whether a concept is in active use or retired Concept Status
This table relates the various terms used to name a single SNOMED CT concept. Primary key Descritption ID Fully specified name Preferred Term Synonym Description Type (Indicates type of description) Associates each description with a particular language or dialect Language Code
This table contains the relationships between SNOMED CT concepts. Primary Key Relationship ID Type of relationship Relationship Type First concept in the relationship Concept ID 1 “target” concept in the relationship Concept ID 2
The content of SNOMED CT evolves with each release. Drivers of these changes include changes in understanding of health and disease processes; introduction of new drugs, investigations, therapies and procedures; and new threats to health, as well as proposals and work provided by SNOMED partners and licensees. Changes designated as minor require only a history record to record the change. The history mechanism involves the following tables: Component History Table Component History References Table
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. The Subset Mechanism may be used to derive tables that contain only part of SNOMED CT Subsets are not necessarily mutually exclusive Subset mechanism involves the following tables: Subsets Table Subset Members Table
Cross Mappings enable SNOMED CT to effectively reference other terminologies and classifications. Each cross map matches SNOMED concepts with another coding scheme that is called the “target scheme.” Cross Mapping mechanism involves the following tables: Cross Map Sets Table Cross Maps Table Cross Map Targets Table
The International Health Terminology Standards Development Organization provides technical documentation for developing SNOMED compliant applications Technical Reference Guide – 166 pages Technical Implementation Guide – 211 pages Includes an appendix for working with HL7 (version 3)
All Version 3 products derive their semantic content from the RIM. Intermediary models are used to constrain the RIM for use in a particular specification. Domain Message Information Model (D-MIM), which constrains the portion of the RIM used by a committee in the derivation of all their messages. Refined Information Model (R-MIM), and a Hierarchical Message Definition (HMD) specify a set of Message Types. there will be several D-MIMs derived from the RIM; there will be several R-MIMs derived from each D-MIM; and there will be several HMDs derived from each R-MIM. SNOMED CT will typically apply these constructs to these intermediary models, rather than to RIM itself.
The RIM includes a new set of data types developed for use within the HL7 Version 3 family of standards. Data types that can carry ConceptIDs include: Coded with Equivalents (CE), which carries a code, the name of the coding scheme the code is drawn from, and a display name corresponding to the code; and allows synonyms to be transmitted – such as an HL7 code and its equivalent SNOMED code; Concept Descriptor (CD), which builds on the CE by supporting the post-coordination of codes (or, stated in another way, the combining of codes from a terminology to create a new concept).
RIM attributes of type CE or CD can also have a specified vocabulary domain. These domains can include HL7-defined concepts or can be drawn from HL7-recognized coding systems such as LOINC or SNOMED CT. Vocabulary domains have a coding strength that can be “Coded, No Extensions” (CNE), in which case the only allowable values for the field are those in the vocabulary domain; “Coded, With Extensions” (CWE), in which case values other than those in the vocabulary domain (such as local codes) can be used if necessary.
The vocabulary domain specifications stated in the RIM always refer to a complete vocabulary domain. at the RIM level there is no specialization based on realm of use or on the context and needs of a specific message. As RIM attributes are specialized to suit a specific message context, the domain of the attribute can be reduced (constrained) to reflect the specialization. A vocabulary domain that has been constrained to a particular realm and coding scheme (such as SNOMED CT) is called a “value set.”
Retrieve an HL7 V3 message A receiver of one or more HL7 messages will need to be able to extract the coded information in the message and aggregate it with concepts sent in other messages or with concepts stored in a data repository. The entire discussion of aggregation in this section assumes that valid and conformant HL7 messages are received.
Syntactic transformation Convert the concepts in the message into a “canonical form” (using a derived equivalence between HL7 RIM attributes and SNOMED CT relationship types). The use of guidelines and templates can constrain the inherent flexibility of an HL7 message, and can decrease the number of sub- steps required to perform a canonical transformation. Tightly coupled systems can take this into account, and establish bilateral agreements that will minimize message variability.
Aggregation Aggregate the various representations, all expressed in a common canonical form. Use techniques that query for the primary code AND the semantic properties of the concepts of interest.
What are the implications to system designers when they try and hide the use of SNOMED from the end user?
inforoute.ca/Documents/R2_ENGLISH%20SC%20Guide%20and%20S tandards%20Catalogue.pdf (Medical_Subject_Headings, International_Statistical_Classification_of_Diseases_and_Related_ Health_Problems, Unified_Medical_Language_System, LOINC, SNOMED_CT) Campbell JR, Carpenter P, Sneiderman C, Cohn S. Chute CG, Warren J. Phase II Evaluation of Clinical Coding Schemes: Completeness, Taxonomy, Mapping, Definitions, and Clarity. Journal of the American Medical Informatics Association. 1997;4: blobtype=pdf SNOMED Clinical Terms User Guide