SNOMED CT is a complex ontology; sophisticated browsers are required to make it understandable and useful. We identified 23 SNOMED CT browsers that have been developed, and inspected 17. We enumerate and provide test criteria for a 'master list' of 143 browsing features supported by at least one inspected browser; future work will determine which of these features are implemented by individual browsers. Only 5 features were common to all 17 browsers; 89 were found in less than one third of browsers. We recommend that a core set of browsing features be defined and harmonized across browsers, particularly for text-to-concept search operations.
SNOMED CT is a biomedical ontology and an associated terminology1. Formerly owned by the College of American Pathologists, it has been managed since April 2007 by the International Health Terminology Standards Development Organisation (IHTSDO), a not-for-profit international standards body. As distributed, it is a large, complex and evolving knowledge artifact. Sophisticated browsers must make that complexity accessible and understandable, and suppress distracting or unwanted detail2-3. A number of different SNOMED CT browsers have been constructed since it was first published. Some have been evaluated for a variety of use cases, including coding of clinical data4-8 and terminology evaluation and management9.
In this paper, we report interim results of a systematic inspection of some of these browsers. We enumerate a superset of browsing features, outline the variability with which these features are implemented in individual browsers, and consider the possible consequences of non-standardized browsing of a standardized terminology.
The core of a SNOMED CT release comprises three tables (sct_concepts, sct_descriptions and sct_relationships) collectively defining a compositional description logic ontology of the medical domain, and a lexicon of associated preferred or synonymous descriptions. The most recent international release (January 2008) contains 311,313 active concepts, 1,357,719 relationships between those concepts and 794,061 active descriptions.
Working deployments of SNOMED CT require additional or ancillary information linked to that core, usually provided by either the IHTSDO or a National Release Centre. Examples of such data include crossmaps to other clinical classifications (e.g. ICD10), definitions of subsets of concepts and/or their descriptions for navigational or localization purposes, and a history of changes between successive releases. The January 2008 IHTSDO release therefore comprised 21 discrete table components in addition to the 3 defining the core ontology. The April 2008 UK National Release, which builds on the January 2008 IHTSDO release, comprised 122 separate tables. In addition to this centrally provided additional content, it is also possible to link external data to the core or ancillary data sources. For example, crossmap target codes can be linked to their corresponding native rubrics or hierarchies.
The authors and their colleagues identified 23 different implementations of software10-28 offering SNOMED CT browsing capability – either embedded in larger application environments or available as standalone browsers. 16 of these10-23 were inspected as working software: CaTTS, CliniClue, CLIVE, EdBrowse, FDB Sphinx, HealthTerm, LexPlorer, Mycroft, NCI Terminology Browser, OntoBrowser, OpenKnoME, Protégé-OWL, SNOB, SnoFlake, the UMLS Rich Release Format (RRF) Browser and the Virginia Tech Browser. One additional feature was identified on a screen capture of the AxSys browser. AxSys, CLIVE, FDB Sphinx, HealthTerm and LexPlorer require user privileges to access; OntoBrowser and EdBrowse are unsupported inhouse prototypes. The remaining ten browsers are publicly available at zero cost. Both CliniClue and OpenKnoME require proprietary additional tooling to load SNOMED CT distribution files, although prebuilt CliniClue data is widely available. OpenKnoMe and OntoBrowser also require a proprietary terminology server.
The remaining 6 browsers not inspected24-28 were: proprietary software from Informatics inc, Ocean Informatics and Visual Read; a demonstrator browser/encoder developed within the NHS Common User Interface Project; Kermanog’s CLAW product17 based on SNOMED in ClaML (EN 14463) format; and Linköping University’s browser. These were excluded for reasons of time or lack of access.
Each browser was inspected by one author against an
emerging catalog of all features exhibited so far by at
least one previously inspected browser. Whenever the
choice was given to us, browsers were inspected
using content based on the July 3
The goal of each successive inspection was primarily to identify novel features implemented in the inspected browsers, for inclusion in a cumulative master catalog. The feature catalogue was iteratively organized by an emerging set of themes, and this resulted in a progressive systematization of the inspection process itself, with each theme considered in detail by turn. This iterative systematisation aided the process of new feature identification.
Where possible, operational definitions of new features were specified (reproduced in Tables 1-3). Subsequent inspections progressed by browsing or searching the Test Case column entry, and comparing the displayed result with the Expected Result column. Although previously inspected browsers were subsequently re-inspected for newly discovered features, work is underway to confirm the validity and reproducibility of inspecting individual browsers against the feature catalog. Individual browser scores are therefore not presented here.
RESULTS 143 different browsing features were identified across 17 inspected browsers. 6 further features occurred to the authors during the inspection process as being potentially useful, but were not found in any inspected browser. The combined set of 149 features are presented in the accompanying tables, organised under the 8 major themes outlined below.
Our preliminary summary results, based on partially validated individual browser inspections, suggest most browser featuresets are an arbitrarily selected and small subset of all 149 features available. On average, individual browsers implement only 40 features (Range 21-107, StDev=13), but only 22 of the 149 features were found in more than two thirds of all browsers inspected, of which only 5 were implemented in all inspected browsers (Search by ConceptID or by Exact string, display of a ConceptID, its linkage to a Description, and the text of that Description). 89 features were found in less than a third of all browsers, but 70 of these are found in at least two browsers. Overall, these results suggests that most possible browsing features have been implemented independently by several SNOMED browser developers, but they have yet to become ‘standard’ across most browsers.
A minimal requirement for a SNOMED CT browser is to give access to the data in the three core tables (concepts, relationships, descriptions). Table 1 lists the 22 fields from each of the three core tables that might be displayed by a browser.
Most browsers implement a concept-centric view of this core content, comprising one concept, its description(s), classification with respect to other concepts, and definition in terms of other concepts. This represents the minimum set of features required for the coding of clinical data and basic navigation. Some fields (e.g. ConceptStatus) appear in the source release data as coded numeric values whose interpretation is given only in SNOMED release documentation; most browser implementations display only the human readable interpretation of these codes and not also (or only) the numeric values as actually distributed.
Despite their ‘core’ nature, however, only three of the 22 related features were displayed by all browsers inspected: the Concept ID, a link to (at least one) description for a concept, and display of the text of linked descriptions. Description status and Initial Capital Status, Relationship ID and Refinability were each visible in only two or three browsers.
Non-Core: Ancillary, 3rd Party and Derived Data Advanced navigation and terminology maintenance work may require either additional data outside the core tables, or ‘derived’ views of the core data itself such as ‘reverse’ historical relationships (showing which inactive concepts point at the current browser focus concept as their replacement). Table 1 lists the ‘derived’ views found across the inspected browsers. A complete set of SNOMED core and ancillary linked data is large and complex. Further, it changes with each biannual release. To reflect this configuration and versioning complexity, some browsers report exactly which versions of which release components are loaded, alert users when they are browsing non-current data, and support concurrent browsing of multiple release versions for direct discovery or comparison of changed content. We found display of non-core data, and data from more than one release, to be the exception rather than the rule. Pointers from inactive concepts to their active replacement, and the set of concepts using the browser focus concept in their definition, are accessible in less than half of all browsers; all other ancillary, 3rd party or derived data browsing functions are present in less than one third of all browsers and usually only in two or three.
Following from consideration of what data a browser displays is how it displays it. Additionally, the navigability of this data must be considered. Table 2 lists the visualization and navigation features encountered in the inspected browsers.
Most browsers implement some form of graphical tree browser, displaying the browser focus concept in the context of SNOMED’s multiaxial subsumption hierarchy. Some off-the-shelf tree controls, however, are unsuitable for displaying trees with very many levels and very many siblings at the same level, such as SNOMED CTs subsumption hierarchy. Those showing the hierarchy always exploded from the root node downward (e.g. the NCI Terminology Browser and Protégé) are particularly unwieldy; those that do not detect very large sibling sets before attempting to display them can lead to very long refresh times. Other visualization features observed include: sorting and grouping of components within concept definition or synonym sets, diacritic and superscript rendering, and typographic or colour coding of text. Most browsers employ web browsing paradigms for navigation, with use of hyperlinks to refocus the browser on arbitrary concepts, as well as back/forward navigation. Bookmarked ‘favourites’, or a ‘home’ concept, however, were rarely observed.
The overall experience of working with a browser is influenced by a range of more generic user interface features, listed inTable 2. These include: the ability to transiently or persistently configure a custom view on the wealth of SNOMED related information, e.g., to occupy less of the desktop real estate; copy-and-paste or drag-and-drop of selected information either within the browser environment or into external applications, and the availability of an API allowing browser interface components to be instantiated and controlled by 3rd party software (a functionality distinct from the notion of a terminology services API per se).
Table 3 lists the range of features observed by which SNOMED CT is searched against a user-entered text string in order to identify candidate SNOMED ConceptIDs as possible entry points for subsequent visualization and navigation. These different search features observed may be further analysed into: · lexical expansion of the original user search string in order to increase recall · semantic or metadata filtering of the set of candidate concepts returned by a query, in order to increase precision · collation and sorting of filtered results, so that the user may find (or be certain of not finding) the required concept In general, SNOMED CT searching functionality in most browsers is impoverished and idiosyncratic. Although 37 different query expansion, filtering and collation features were observed across all browsers, thirteen of the browsers implemented less than 10 of them - and rarely the same set. 27 searching features were implemented in less than a third of all browsers inspected, of which 5 were unique to one browser. Browsers differ in which features are on by default, which must be explicitly specified, and which can be, or by default are, combined in Boolean combinations. Not all strip trailing spaces; some default to an exact string match whilst others assume wildcarding unless specifically overridden. Where a search expression contains multiple words or tokens, few browsers support complex query logics such as requiring some tokens to be present and others not.
To demonstrate the effect of these differences, all browsers were used in their default configuration to search against the same string: ‘ear catheter’. Six browsers found no matches. A further six found only 72683003 Removal of catheter from middle ear, and its two descendants. SNOB returned eleven matches, including 72683003 but also 232199004 Inflation of Eustachian tube using balloon. The latter has no directly associated descriptions containing either ‘ear’ or ‘catheter’ but instead is returned because it has at least one ancestor with at least one description matching ‘ear’, and a separate ancestor with a description matching ‘catheter’. The UMLS RRF Browser returned sixty-six matches.
Unlike traditional clinical terminologies, SNOMED CT can be ‘postcoordinated’ - dynamically extended by anybody, subject to certain ontological rules. Most trivially, this manifests as the option to qualify anatomical sites by a Laterality attribute and Sidedness value. Exposing SNOMED CT only as a static corpus significantly diminishes its expressivity. Further, a large part of the content – e.g. all Qualifier, and Linkage Concepts - is easily misunderstood outside the context of postcoordination.
The rules governing postcoordination are complex but compliance with them is a prerequisite for dynamic classification of the expressions so built. A dedicated postcoordinated expression building and validating interface is therefore highly desirable, but we found only five browsers that implement one. Three of these additionally implement some limited part of the rules and conventions. However, although compliance with the rules has limited value outside the context of dynamic classification, no browser inspected currently provides that function.
SNOMED CT contains many content errors and omissions. Empowering end users to log and report content errors offers a ‘social computing’ route to expand SNOMED CT’s quality assurance capacity. However, only one inspected browser directly integrates content bug logging and reporting.
Accessing data vs. browsing. In seeking to review ‘browser’ technologies, we excluded command line or other direct SQL interfaces on the data tables. Although most browsers hide the raw data tables from the user, at least one explicitly provides a route to it. Whether ‘display’ of data by this route should pass or fail our core data theme tests is debatable.
Configurability. A minority of the features identified are orthogonal or graded values of one property. For example, whether a given hierarchy browser sorts sibling concepts randomly, alphabetically by description, or numerically by ConceptID are orthogonal values of a ‘sibling sort’ function. Although in theory it is possible to imagine a browser configurable to any one of the three, individual hierarchy display instances can only implement one at a point in time. In practice, all inspected browsers implement only one of these options throughout. Operational test criteria. Differences between the browsers, particularly their default treatment of search strings, confounded attempts to specify tests that would work equally across all of them. Many of the tests specified in Tables 1-3 must be interpreted to take account of issues such as whether exact or wildcard string matching is assumed.
Absence of standard search features. The observed differences in text-to-concept search implementations have a striking effect on browsing experience. Further work to characterize this phenomenon is required. Future work. We are currently validating the testing of specific browsers against the catalog of features. The quantitative results reported here are preliminary but confirm the authors’ original motivation for the experiment: currently available SNOMED CT browsers are very different and often suboptimal. We do not propose that all SNOMED CT browsers must always implement all the features we identify; further research is required to determine which features are required for specific use cases, but the prior existence of a master feature catalog such as we present here is a prerequisite for that research. Many of the features seem likely to be common across use cases, particularly text-to-concept search operations. We recommend that a core set of searching and browsing features be defined and harmonized across tools, so that a standard terminology is not transformed into multiple different objects by virtue of idiosyncratic and limited browsing experiences.
Acknowledgments This research was supported by the Intramural Research Program of the National Institutes of Health (NIH), National Library of Medicine (NLM) and by NHS Connecting for Health. Thanks to Drs Malcolm Duncan and Christopher Wroe for their assistance.