Managing SNOMED

1. Managing SNOMED NAHLN January 2004 Las Vegas

2. Nomenclature Tasks • Do I know how you should do this? • NO!!!!!!

3. Nomenclature Tasks • Install nomenclature • Interface to terminology • Subsetting to enhance efficiency • Mapping from existing controlled vocabulary • Displaying preferred descriptions • System wide • User specific?????? • Message processing • Requests from users for concept addition • Updates (ongoing) • Queries

4. Interface options (Ferrari) • Data entry concept requests • Queries of LIMS data • Natural language interface? • Description logic approach Lims Server CIS Server Etc. “High Powered” Terminology Server • Advantages • Offload nomenclature from production system CPU / data storage • Single update with new release of nomenclature • Access to “all” at all times • Minimal SNOMED “pre-processing” • Disadvantages • Expense • Server • Terminology “software” • SNOMED functionality inadequate at this time. • Probably requires full time nomenclaturologist… 

5. Interface options (Chevy) • Store subsets (pick lists) in LIMS System • Query server • a complete copy of SNOMED • Your SNOMED “workshop” Lims Server “Low End” Terminology Server (Full copy of SNOMED) • Advantages • Terminology “operations” • Disadvantages • Several – many subsets • Subset updates as second step with new release (problematic if manual) • Somebody must build subsets

6. SNOMED Subset • “…a set of Concepts, Descriptions, or Relationships that are appropriate to a particular language, dialect, country, specialty, organization, user or context.” • “…simplest form, the Subset Mechanism is a list of SNOMED identifiers (SCTIDs).” • “…Mechanism may be used to derive tables that contain only part of SNOMED CT.”

7. Functional Sub-setting • We only need PORTIONS of SNOMED • DIFFERENT portions of SNOMED for various parts of LIMS. • Retain the ability to use ALL of SNOMED to search, retrieve, analyze data produced using sub-sets. • Be prepared to transfer (copy) from SNOMED to subset as needs change.

8. Existing Subset(s) • Non-human subset • This subset assists applications that desire to exclude concepts which are not human medical concepts (i.e., paw and fin). • Note that this is NOT a veterinary subset as that subset would include terms shared with humans such as brain and eye. • Pathology subsets (3) • CAP Cancer checklists • Allergen subsets

9. NAHLN Subsets? • SNOMED (-) hierarchies that are NOT of interest. • Someone has to decide what’s “not of interest” • Someone familiar with SNOMED should build the subsets • Desired functionality -> Subset the relationships? • It would be nice to have a Non-human-only subset • Organisms • Species • Breeds • Bacteria, viruses, parasites, etc. • Diseases of interest • Some portion of laboratory tests (classification scheme for LOINC?) • Reportable diseases (depending on jurisdiction)

10. Subsets

11. Veterinary SubsetsShared resource • We need to develop a “root” veterinary subset • Manual process (can’t be automated at this time). • Prune SNOMED to remove human ONLY content. • Prune SNOMED aggressively to remove excessive granularity. • Automated subsetting works on ALL SNOMED or the Veterinary subset.

12. Subsets All of SNOMED “Cardiovascular disease” subset Algorithm Vet Subset Cardiovascular Diseases Intersection = Veterinary Cardiovascular Diseases

13. Subset development (Ideal) • Build a complete Veterinary Subset of SNOMED • Veterinary subset a resource shared by the profession. • Managed by central “authority” • Distributed by SNOMED? • Use algorithm approaches to create “microsubsets”

14. NAHLN Extension(s)? • Conditions of husbandry • Probably should be core • Descriptions (more synonyms) • Local • Network-wide

15. ConceptID SET NewChildList = ConceptID SELECT Distinct ConceptID1 FROM RelationshipsTable WHERE RelationshipsType =116680003 AND ConceptID2 IN (Childlist) SET NewChildList = Returns from query APPEND returns from query to Childlist Returns? – Yes No Output Childlist Recursion for gathering all descendants of a concept. • Build subsets • breeds, species • all disorders • all cardiovascular disorders • etc. • Query for concept and all its specializations • everything that “ISA” respiratory disease.

16. TargetConceptID (Gather IsA parents) SELECT ConceptID2 FROM RelationshipsTable WHERE ConceptID1 = (TargetConceptID) AND RelationshipsType =116680003 (Gather non isa Children) SELECT ConceptID2, RelationshipType, RelationshipsGroup FROM RelationshipsTable WHERE ConceptID1 = (TargetConceptID) AND CharacteristicType = 0 AND NOT RelationshipsType =116680003 (Output) “List” a SNOMED definition ISA relationships always defining 116680003 = “ISA” Group by RelationshipsGroup CharacteristicType =0 is defining

17. Why map? • SNOMED is not optimized for data entry. • Your own local vocabulary may be the preferred data entry instrument. • Capture data via local term (description string) • Convert to SNOMED concept • Transmit to repository

18. SNOMED Maps • SNOMED provides a number of maps to nomenclatures of human interest • ICD-9 • ICD-10 • ICD-0 • LOINC (special case we MIGHT use) • SNOMED is source

19. Mapping • Mapping is directional • Largely the result of differing granularity between “target” and “source” • 1:1 – Concept is the same • Term may be identical or synonym – remember to distinguish on CONCEPT not on string • Narrow to Broad – Source concept is more specific than target • Broad to Narrow – Source concept is more general than target • Two maps may be needed for bi-directional functionality (unless entire map is 1:1)

20. Mapping for NAHLN • NAHLN Maps (e.g., CAHFS) will use local nomenclature as source, SNOMED as target • Map builder qualifications: • Understand structure of source and target • Understand content of source and target • IF the map is completely 1:1, the single map is bidirectional.

21. Mapping for NAHLN • 1:1 maps will represent a majority • Broad (source) to narrow (SNOMED) • Good argument that SNOMED needs more content • Narrow (source) to broad (SNOMED) • SNOMED may need/want the content • Map to a post-coordinated concept may be required

22. Post-coordination(for NAHLN mapping) • What is post-coordination? • Create a new concept by adding specificity to and existing SNOMED concept. • Source has: • “Acute pasteurella pneumonia” • Target (SNOMED) has: • “pasteurella pneumonia” • Create: • Pasteurella pneumonia + has course = acute

23. Post-coordination(for NAHLN mapping) • Where do you put your new creation? • Extend the concepts table (1 new) • Identifier outside of SNOMED itself (namespace mechanism) • Extend the “relationships table” • An extension (not part of core) • Processed as if it is part of the original table. Pasteurella pneumonia + has course = acute

24. SNOMED -> LOINC map? • SNOMED can be used to provide a categorization hierarchy for LOINC codes through the map. • Probably unnecessary unless vocabulary server approach is employed.

25. Species and Breeds • It is our INTENTION that the living organisms hierarchy should accurately reflect the current state of the art re: animal taxonomy. • Each entry has taxonomic rank identified in FSN • Relationship type 3 (additional) to support a relationship that identifies taxonomic rank.

26. Species and Breeds • Gather species and breeds • Select the root for the hierarchy • Perform recursive search for children • Identify taxonomic rank • Process string of FSN • Fact relationship • “has taxonomic rank” = breed (etc.)

27. Concept Addition • Users WILL discover concepts that are not present in the nomenclature • Licensed users can make requests to SNOMED directly • Channels have been established for timely addition.

28. Concept Addition • When we (AVMA Secretariat) receive a request for concept addition: • We confirm that the concept is really missing • Often there is a synonym present • Requested “description” can be added • We prepare a SNOMED-style definition for the concept • Concepts are added to the nomenclature by a veterinarian on SNOMED staff

29. Nomenclature Updates • New version of SNOMED scheduled for every 6 months. • Expect change rate to decline with time • NLM updating may be less frequent. • NLM updating will certainly lag behind SNOMED releases.

30. Nomenclature Updates • Retired Concepts • Concept “referral” mechanism • New Concepts • Retired Descriptions • New Descriptions • New relationships

31. Queries • Query full copy of SNOMED • Queries based on description have highest yield. • Indexes • Query portion that has been recorded?

32. SNOMED Extensions • Enable authorized organizations to add Concepts, Descriptions, Relationships and Subsets to complement those that are centrally maintained as the core content of SNOMED CT. • specialized terminology needs of an organization. • Extensions maintain unique identification across organizations for data transmission and sharing.

33. SNOMED Extensions • Distinguishable from the main body of SNOMED CT • in the thesaurus • 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.

34. Existing Extension(s) • US Drug extension • List of drugs marketed in the United States • UK Drug extension