...
The application has a flexible searching architecture in the background that allows additional searching algorithms to be implemented and incorporated into the application. By default, three choices are offered:
ATOM STANDARD - tuned to be the most useful search for general concept browsing. The background algorithm is complex and out-of-scope to fully document here. By default, this is configured to find only “active” concepts.
NLP - originally designed for NLP work, EXACT - this is does a more-or-less “exact-ish” search (when not considering whitespace normalizing for whitespace, some stop words, and punctuation)
NGRAM - useful for when you’re not sure of the spelling of something, or not sure whether the terminology uses noun-like or adjective-like language to label concepts (e.g. “cervical” vs “cervix”).
SNOMED - this only shows when browsing SNOMED terminologies and is a pass-through to the search API of the SNOMED International browser at browser.ihtstdotools.org. It can be used to return concepts in the same way that browser would.
If you encounter unexpected search results under certain circumstances, let us know! We’re always looking to refine and improve the searching algorithms and understand different use-cases require different approaches.
Lucene Searching “Tricks”
The “ATOM” “STANDARD” search handler also allows for use of “lucene syntax” within the query, where if you understand the underlying data model - you can tune searches to specific aspects of the content. Here are some examples of queries making use of the Lucene syntax:
local:true- Performs a search for ONLY locally created content.heart AND active:false- performs a search for inactive concepts matching the word “heart” (note the “active only” checkbox will have to be deselected).attributes:CUI=C0412010- performs a search for concepts in the selected terminology associated with the UMLS CUI C0412010Other examples will be provided in the future - as will more documentation on the complete indexing model.
...
< 71388002 | Procedure | : has_indirect_procedure_site = <<64033007 | Kidney structure |- Procedures with a direct procedure site of “kidney” or any of it’s descendants.< 71388002 : has_indirect_procedure_site = <<64033007- Same as the query above, but with the name portions removed.< 71388002 : 405814001 = <<64033007- Same as the query above, but using the SNOMEDCT_US concept id for the relationship name instead of the metadata label.^723264001 | Lateralizable body structure reference set |- members of the “Lateralizable body structure reference set”^723264001 | Lateralizable body structure reference set | AND << 362837007 | Entire cell |- members of that refset that are also descendants (or self) of “Entire Cell”<< I11 | Hypertensive heart disease |- an ECL expression used with ICD10CM to find I11 and all of it’s descendants.* : MAPPING=B20- an (enhanced) ECL expression used to find concepts with mappings to a particular code (e.g. in this case SNOMED concepts with B20 as an ICD10 code)Other examples will be provided in the future - as will more documentation on the complete model of what ECL is supported
...
Atoms - Individual names (and associated metadata) that are synonymous with the concept’s underlying conceptual “meaning”.
In brackets is show the term type, the language, and any label related to where the synonym came from.
Term types of INDEX_SY reflect generated or manually added synonyms.
Atoms themselves may have attributes (or properties) which can be seen by expanding the “plus” icon next to each entry.
...
Subsets - Shown in the report are the subsets that the focus concept is a member of. Conceptually, subsets are collections of concept codes from a terminology that are labeled and used for a specific use-case.
This examples shows the concept belonging to two anatomy related subsets.
...
Maps - Organized into “sets”, these can be thought of as cross-terminology relationships. A way of linking codes in one terminology to codes in another.
This example shows a concept with a number of maps to ICD10CM.
The links can be clicked and will load the corresponding concept into the view.
...
Relationships - (relationships from this concept). The display includes flags for whether
Inverse Relationships are relationships to this concept from the indicated concept.
The green “D” flags indicate that the relationship is part of the logical definition of the concept (e.g. part of the necessary and sufficient conditions)
The green
numbers indicate the SNOMEDCT “relationship group”
The next label is the high-level relationship type (mousing over it will provide more info). This corresponds to the UMLS REL field.
The longer label is the more detailed relationship type (e.g. “has_finding_site”). This corresponds to the UMLS RELA field.
The longer labels can be used in ECL queries in place of the concept ids for those relationships (this is particularly useful when using ECL with non-SNOMED terminologies).
Some concepts have large number of relationships - so remember clicking the header collapses the view to prevent the need for massive scrolling.
...
.