Practically all analytical processes are driven by database queries. A database query is a machine readable question presented to a database in a predefined language.
Unlike other code systems, which either have no hierarchy or a hierarchy that is fully represented within the code (e.g. H65.9), just retrieving the SNOMED CT codes recorded in a patient record does not fully utilize the analytics capabilities of SNOMED CT. To get the most benefit from using SNOMED CT in patient records, one must be able to not only query the records themselves, but also query SNOMED CT.
In this section, we describe how record and terminology queries can work together to perform powerful queries over SNOMED CT enabled data.
The query language used to query a set of patient records is usually dependent on the type of database used to store the patient records. For example:
Relational databases may be queried using SQL (Structured Query Language)
Object-oriented databases may be queried using OQL (Object Query Language)
RDF databases may be queried using SPARQL (SPARQL Protocol And RDF Query Language)
XML databases may be queried using XQuery (XML Query Language)
OLAP databases may be queried using MDX (Multidimensional Expressions)
However, some query languages support logical queries that are independent of the application, programming languages, system environment and storage models - for example, AQL (Archetype Query Language) and EQL (EHR Query Language). These languages instead focus on queries based on the relevant information models (called 'archetypes').
To get the most benefit from using SNOMED CT in patient records, however, one must be able to not only query the records themselves, but also query SNOMED CT.
One way of achieving this is to include a list of all possible SNOMED CT codes that are required within the query. For example, to find the patients with a Respiratory system disorder, one could include every individual code that is a descendant of 50043002 |disorder of respiratory system| (around 3000 codes) within the patient record query. Using SQL, this would look like:
SELECT DISTINCT PatientID FROM ProblemList
WHERE Code IN (140004, 181007, 222008, 490008, 517007, 599006, 652005, 663008, etc)
However, this creates a lengthy query that is difficult to both validate and maintain. In some cases, it may also be too long to be accepted by the query engine.
Another approach would be to use a subset of respiratory system disorders, and load these into a separate table – for example:
SELECT DISTINCT PatientID FROM ProblemList
WHERE Code IN (SELECT * FROM RespiratorySystemDisorders)
However, it may not be scalable to create a new table for each terminology query that is required.
A third approach would be to use a transitive closure table to test the hierarchical relationship between each SNOMED CT code and 50043002 |disorder of respiratory system|. For example,
SELECT DISTINCT PatientID FROM ProblemList PL
INNER JOIN SNOMEDTransitiveClosure TC ON TC.SourceId = PL.Code
WHERE TC.TargetId = 50043002
However, to support a more advanced style of query that utilizes the full capabilities of SNOMED CT, SNOMED CT query languages or API calls must be embedded within the patient record query languages. For example, the following queries use the SNOMED CT Expression Constraint Language embedded within a SQL query.
SELECT DISTINCT PatientID FROM ProblemList
WHERE Code IN (< 50043002 |disorder of respiratory system| )
SELECT DISTINCT PatientID FROM ProblemList
WHERE Code IN (<< 404684003 |clinical finding|:
363698007 |finding site| = << 39057004 |pulmonary valve structure|,
116676008 |associated morphology| = << 415582006 |stenosis|)
SNOMED International is developing a consistent family of computable languages to support a variety of use cases involving SNOMED CT, including querying and defining intensional subsets. The SNOMED CT family of computable languages will include:
Compositional Grammar – for defining SNOMED CT expressions
Expression Constraint Language – for constraining a set of possible expressions
Query Language – for querying over SNOMED CT content
Template Languages – using the other languages with slots that may be filled at a later time
SNOMED CT compositional grammar, which provides a common foundation for all the SNOMED CT computable languages, was adopted as an international standard in 2010. In 2014, the first version of the SNOMED CT expression constraint language was then published. The SNOMED CT template languages and query language are currently under development and will be made available in the near future.
Both the SNOMED CT Expression Constraint Language and the SNOMED CT Query Language can be used to define queries against SNOMED CT content.
The SNOMED CT Expression Constraint Language is a formal language used to represent SNOMED CT Expression Constraints. A SNOMED CT Expression Constraint is a computable rule that can be used to define a bounded set of clinical meanings represented by either precoordinated or postcoordinated expressions. SNOMED CT Expression Constraints allows a set of clinical meanings to be defined using hierarchical relationships, attribute values, reference set membership, and other features such as cardinality, conjunction, disjunction and exclusion. For example, the following expression constraint represents the set of clinical findings, which have both a finding site of 'pulmonary valve structure' (or a subtype of 'pulmonary valve structure') and an associated morphology of 'stenosis' (or a subtype of 'stenosis').
<< : = << , = <<
The SNOMED CT Query Language is a formal language used to represent SNOMED CT Queries. This language is based on the same features as the SNOMED CT Expression Constraint Language, with the addition of SNOMED CT specific filters. These filters allow the author of the query to restrict the results based on the version of SNOMED CT being used and the value of SNOMED CT's release file fields (e.g. definitionStatus, characteristicType, languageCode, term and typeId). Additional keywords are also provided (e.g. preferredTerm, fullySpecifiedName) to simplify the use of common filter combinations. For example, the following SNOMED CT query finds all fully defined diseases which have a preferredTerm (in the GB English language reference set) that contains the substring "heart".
<< 64572001 |disease| {{ definitionStatus = 900000000000073002 |defined|,
preferredTerm = "* heart* ", languageRefSet = 900000000000508004 |GB English| }}
B2i's Snow Owl Terminology Server (see case study) supports the execution of SNOMED CT queries using a precursor to the SNOMED CT Expression Constraint Language (referred to as 'Extended SNOMED CT Compositional Grammar' or 'ESCG').
An Application Programming Interface (API) for a SNOMED CT enabled terminology server can be used to request the execution of SNOMED CT searches and queries. Using a terminology server API, record management systems are able to effectively access terminology services without re-implementing their functionality in every system.
A number of commercial terminology servers offer proprietary APIs that enable SNOMED CT search and query, including Dataline's SnAPI solution and B2i's Snow Owl Terminology Server (case study 2.5). An example of a script which uses the B2i's Snow Owl API to execute a SNOMED CT query is shown below:
Standardized APIs for terminology services are also available. In particular, HL7's Common Terminology Services 2 (CTS 2) provides a standardized API that supports access to terminology servers that may contain a variety of code systems, including SNOMED CT.
import com.b2international.snowowl.scripting.services.EscgEvaluatorService def escgQuery = """ <<404684003|Clinical finding| : 246454002|Occurrence| = 255399007|Congenital|, 370135005|Pathological process|=<<263680009|Autoimmune| def escgEvaluator = new EscgEvaluatorService() //initialize a service for evaluating a query def concepts = escgEvaluator.evaluate(escgQuery) //evaluate the query concepts.each { println "ID: ${it.id}, ${it.label}" } //prints the result to the console