One approach to analytics using SNOMED CT is to construct subsets of SNOMED CT identifiers, which are applicable to a specific clinical purpose, and to test the codes recorded in patient records to check for membership in the appropriate subset. Subsets of SNOMED CT identifiers may either be defined extensionally or intensionally.

Extensionally defined subsets are those in which each concept is individually enumerated. They are usually manually constructed and maintained, and can therefore be labor intensive and error prone. For example, one might construct a subset of kidney disease codes including 36171008 |glomerulonephritis|, 71110009 |hydrocalycosis| and 42399005 |renal failure|.

Intensionally defined subsets are those which are automatically populated (or expanded) based on a machine processable query. For example, one might construct a subset of kidney disease codes using the results of the query "<< 90708001 |kidney disease|" (i.e. descendants or self of 90708001 |kidney disease|). The query used to define an intensional subset may utilize SNOMED CT's hierarchical relationships, attribute values, descriptions, and membership in other intensionally or extensionally defined subsets. For more information about SNOMED CT query languages, which may be used to define intensional subsets, please refer to the section about Database Queries.

Example

A subset containing types of 58437007 |tuberculosis of meninges| may be defined extensionally as follows:

With the help of the SNOMED CT hierarchy, this same subset can be defined intensionally as: << The expansion of an intensional subset defined using this query is the same as the extensionally defined subset shown above.

Using a lexical query, it is also possible to intensionally define a subset of 'tuberculosis of meninges' findings. However, the results of purely lexical queries are not as reliable. For example, using the query: << {{ term = ".tuberculosis.*meninges." }} the following expansion can be calculated:

As can be seen, the results of this lexical query only includes 3 of the possible 4 values from the previous subset. In other cases, lexical queries may incorrectly find concepts which are not appropriate to the subset. It is therefore recommended that lexical queries are avoided in the definition of intentional subsets. However, they do serve a useful purpose in identifying candidates for an otherwise manually crafted subset.

Subsets of SNOMED CT may be defined locally as a flat list of concept identifiers, or as an independent query specification. However, where wider distribution and/or version control is required over these subsets, SNOMED CT reference sets offer the ideal solution.

Extensional subsets are commonly defined in SNOMED CT using a Simple reference set - however an Ordered reference set or Annotation reference set can be used if additional information needs to be recorded for each member of the subset. Intensional subsets are defined in SNOMED CT using a Query specification reference set. A Query specification reference set allows a serialized query to define the membership of a subset of SNOMED CT components. It also specifies the extensional reference set into which the results of executing the query are generated. Intensional reference sets are preferred in many circumstances as they enable their membership to be automatically recomputed over new versions of SNOMED CT.

Subsets can be created using the following methods, either alone or in any combination:

• Manual inclusion, using search and browse methods

• Existing subset, used as a starting point for further manual inclusion and update

• Lexical queries, to identify candidate members, followed by manual verification and update

• Hierarchical queries, to identify descendants of a given concept (e.g. descendants of <73211009 |diabetes mellitus|)

A number of vendor products, such as Apelon and B2i Healthcare allow users to create customized extensional and intensional subsets of SNOMED CT. Other vendor products, such as the Cambio COSMIC® Electronic Patient Record system, Caradigm's population health solutions, Cerner's data warehousing solution and Epic's decision support and reporting tools use subsets of SNOMED CT to support their analytics services.

SNOMED CT offers a number of analytics techniques, which are not possible using other coding systems. SNOMED CT's hierarchical design improves upon the purely lexical query capabilities of free text lists or 'flat' controlled vocabularies. For example, a purely text based query for 'kidney disease' will not return the kidney disease 'glomerulonephritis'. Purely mono-hierarchies, however, limit querying to a single grouping of each code. For example, using a mono-hierarchy 'tuberculosis of the lung' must be assigned a code which makes it either a kind of 'lung disease' or a kind of 'tuberculosis' – however it cannot be both. Using SNOMED CT's polyhierarchy 'tuberculosis of the lung' can be represented as both a kind of 'lung disease' and a kind of 'tuberculosis'. The inclusion of other attribute-based defining relationships and the ability to represent SNOMED CT using OWL 2 EL enables additional Description Logic techniques for classifying and querying SNOMED CT. Extending these capabilities even further, it is possible to use Description Logic techniques across both the terminology and the structure of the patient records in which the codes are stored. Finally, in some specific use cases such as billing, reimbursement and statistics where double counting must be avoided, clinically recorded SNOMED CT codes can be used to map into more general statistical classifications, such as ICD (International Classification of Diseases).

In this section, we describe how the following analytics techniques can be used to support analytics over SNOMED CT enabled data. The techniques described include:

• Subsets – for example, find the patients with a diagnosis in the set of 'kidney disease codes'

• Subsumption – for example, find the patients with a diagnosis that is a subtype (or self) of 'kidney disease'

• Using defining relationships – for example, find the patients whose diagnosis has a finding site of 'kidney structure' (or a subtype of 'kidney structure')

• Description logic over terminology – for example, find the patients whose diagnosis is associated (directly or indirectly) with the 'Streptococcus pyogenes organism'

• Description logic over terminology and structure – for example, find the patients with a family history of heart disease (where this may either be recorded as 275120007 |family history: cardiac disorder| or recorded in a 'Family History' section on a form as 56265001 |heart disease|)

• Using statistical classifications – for example, to meet national reporting guidelines using ICD (International Classification of Diseases)

In practice, a query language may combine a number of these techniques in the same syntax. With the possible exception of the last two approaches, these SNOMED CT query techniques should then be embedded within an EHR query to ensure that the semantic context of the surrounding patient record is taken into account.

Determining whether one concept (or expression) is a kind of another concept (or expression) is the fundamental capability enabled by SNOMED CT. For example, answering the question 'Which patients have an infectious disease?' involves finding all the patients with any kind of infectious disease (e.g. viral pneumonia, tuberculosis).

Subsumption occurs when one clinical meaning is a subtype of another clinical meaning, and testing for this is called 'subsumption testing'. If clinical meaning X is a subtype of clinical meaning Y, then Y is said to 'subsume' X and X is 'subsumed by' Y.

Subsumption testing between concepts is represented using a stated or implied |is a| relationship. For example, 75570004 |viral pneumonia| is a 40733004 |infectious disease| and therefore 40733004 |infectious disease| subsumes 75570004 |viral pneumonia|, and 75570004 |viral pneumonia| is subsumed by 40733004 |infectious disease|.

Subsumption testing between expressions tests to see if the candidate expression (often recorded in a patient record) is subsumed by a predicate expression (typically part of the query being run across the patient record). For example:

75570004 |viral pneumonia|

40733004 |infectious disease|:
363698007 |finding site| = 39607008 |lung structure|

In this case, the candidate expression is subsumed by the predicate expression.

Subsumption testing can be represented using the SNOMED CT Expression Constraint Language using the '<' (descendantOf) or '<<' (descendantOrSelfOf) operators. For example, the expression constraint:

is satisfied by any expression that is subsumed by 40733004 |infectious disease|.

There are a variety of ways to implement subsumption testing. These are summarized in the Implementation sub-section below.

A typical example using subsumption would be an audit within a hospital, reviewing all patients with an infectious disease. In this scenario, the following simple query could be executed to find all the patients whose health record contains a diagnosis that is subsumed by the concept 40733004 |infectious disease|:

If the health records contained the following data:

Then this query would return the following list of patients:

• 634711 (because 415353009 |rotavirus food poisoning| is a subtype of 40733004 |infectious disease|)

• 158775 (because 40468003|hepatitis A| is a subtype of 40733004 |infectious disease|)

• 889125 (because 75570004 |viral pneumonia| is a subtype of 40733004 |infectious disease|)

Note that patient 456872 would not be returned by this query as neither 22298006 |myocardial infarction| or 195967001 |asthma| are subtypes of 40733004 |infectious disease|.

Rapid and efficient computation of whether a concept |is a| subtype descendant of another concept is essential for testing subsumption between expressions. A variety of approaches exist for testing subsumption. When the candidate and predicate expressions are both precoordinated concepts, subsumption testing can use the published relationships from the SNOMED CT release files. Approaches for testing subsumption between precoordinated concepts include:

In this approach, every possible sequence of |is a| relationships are recursively tested from the candidate concept until the predicate concept is reached or until all possible paths have been exhausted.

In this approach, flags are added to each concept to indicate the set of high-level concept nodes of which that concept is a subtype. A concept can only subsume concepts that include the same set of high-level concept flags. This reduces the number of tests that need to be performed to recursively test the subtype relationships.

In this approach, a database is used which supports the recursive testing of a chain of hierarchical relationships.

In this approach, a depth first tree walk is performed that applies an incremental number to each concept. A second tree walk then allocates one or more branch number ranges to each concept, which contains the number of all of their descendants.

In this approach, a comprehensive list of all supertypes of each concept is created by recursively traversing all |is a| relationships and adding each stated and inferred subtype relationship to a table.

In this approach, a description logic reasoner (e.g. Snorocket, ELK, Fact++) is used to determine whether one concept is subsumed by another.

In most environments, the recommended approach is to either use a precomputed transitive closure table or a description logic reasoner. However, where disk capacity or distribution bandwidth are limiting factors, branch numbering provides an efficient alternative approach. For more information on these approaches, please refer to Subtype search scope restriction in the SNOMED CT Terminology Services Guide.

When either the candidate expression (in the patient data) or the predicate expression in the query are postcoordinated (or both), techniques based on description logic are needed to perform subsumption testing. Approaches for testing subsumption between postcoordinated expressions include:

In this approach, the predicate expression is transformed to short normal form and the candidate expression is transformed to long normal form. The two normal form expressions are then tested for subsumption by checking that each focus concept in the predicate expression subsumes at least one focus concept in the candidate expression, each attribute group in the predicate expression subsumes at least one attribute group in the candidate expression and each ungrouped attribute in the predicate expression subsumes at least one attribute in the candidate expression.

In this approach, a description logic reasoner (e.g. Snorocket, ELK, Fact++) is used to determine whether one expression is subsumed by another.

Where available, the recommended approach is to use a description logic reasoner to calculate subsumption between expressions. However, comparing normal form expressions provides an alternative approach when a reasoner is not available. For more information on these approaches, please refer to Query Expressions in the Practical Guide to Postcoordination.

A number of vendor products use the SNOMED CT hierarchy to support subsumption testing in their analytics services, including the Cerner Millennium Terminology (CMT) package and Epic's decision support and reporting tools. Terminology servers that provide the ability to perform subsumption testing include B2i Healthcare's Snow Owl® terminology server. The UK Terminology Centre's Data Migration Workbench also uses subsumption testing in its query tool, and its case mix and caseload trends analysis tools.

When performing analytics over patient data, an appreciation for the semantics represented in both the terminology and the information model is required. Different information models can use different amounts of precoordination in the terminology, and the same semantics can be represented using different information structures. By using description logic over both the terminology and the information structures, a consistent representation of the meaning of data can be achieved, irrespective of whether this meaning is captured in the data values or in the model itself.

Example

Consider for example the two alternative ways of recording family history. The green rectangles represent the logical structure of the information model and the blue rectangles represent the concept identifiers that are used to populate this information model in the patient record.

The information model on the left uses a heading of 'Family history' to indicate that the named problem refers to a family history of that problem. The information model on the right uses the terminology value to indicate that the problem refers to a family history instance.

When querying over data, which may be collected in either format, both the semantics of the information model and the semantics of the data instances must be considered. One way of achieving this is to use an 'expression template' to convert all data instances into a Description Logic representation, and use this to reason over the data. The following figure shows an example of an expression template that could be used to create a SNOMED CT expression for each of the data instances. Please note that the orange parallelograms represent 'slots' which are subsequently populated with the value of the named data element (e.g. '$Problem').

When the data instances are used to populate the templates, the following two expressions are created:

These expressions may then be compared using a DL reasoner to discover that the first expression is subsumed by the second, or queried using a semantic query language to allow the two data representations to be analyzed in a consistent way.

Description Logic techniques, such as those described in section about Description Logic Over Terminology, can be used to reason over both the terminology and the information model. In addition to translating SNOMED CT to OWL 2, OWL 2 representations of the information model are also created using 'templates' that include 'slots' which are then filled with the patient record instance values. DL reasoners, such as Snorocket, ELK and FACT++, and semantic query languages, such as SPARQL, can then be used over both the terminology and the information model in a consistent way.

Kaiser Permanente is collaborating with Oxford University to investigate ways of performing complex queries efficiently across extremely large numbers of patient records using scalable parallel processing and description logic reasoners. In this project, the analysis is being performed over an OWL-RL representation of the patient data, which incorporates both the terminology and the structure of the information.

SNOMED CT's semantics are based on Description Logic (DL). This enables the automation of reasoning across SNOMED CT, and subsequently the implementation of more powerful analytics operations than is possible using most other approaches. In addition to the subsumption and defining relationship testing described in the previous approaches, DL reasoners and query engines are able to utilize a number of additional logic-based techniques including:

• Property chaining

A property chain is a rule that allows you to infer the existence of a property from a chain of properties. For example, "x has parent y" and "y has parent z" implies "x has grandparent z" (which may be written as "|has parent|ο |has parent|→|has grandparent|). The current release of SNOMED CT includes the property chain:

363701004 |direct substance| ο 127489000 |has active ingredient|

→ 363701004 |direct substance|

However, more property chains may be added in local implementations if required.

SNOMED CT attributes are used to represent a characteristic of the meaning of a concept. There are more than 50 attributes in SNOMED CT, which can each be used as the 'type' of a defining relationship, including:

• 363698007|finding site|

• 116676008|associated morphology|

• 246075003|causative agent|

• 363704007|procedure site|

• 260686004|method|

• 272741003|laterality|

• 127489000|has active ingredient|

The SNOMED CT Concept Model provides rules about how these attributes can be used. Some database queries use the rules from the SNOMED CT Concept Model to match concepts based on the value of their defining relationships.

The following figure illustrates the execution of a query to retrieve a set of findings which have a benign tumor morphology. The query is executed by finding those concepts with an 'associated morphology' relationship with the value 'benign neoplasm'. In this example, the concepts 'benign tumor of kidney', 'benign neoplasm of bladder' and 'benign tumor of lung' are found to have the required defining relationship value.

In the following figure the same set of concepts are shown analyzed with the intention to identify those which have a finding site of kidney. In this example, the concepts 'renal cyst', 'benign tumor of kidney' and 'renal abscess' are found to have the required defining relationship value.

If the queries from the following figures are combined, then the query will return those concepts which are benign tumors of the kidney (see Figure above). In this case, the concept 'benign tumor of kidney' is the only concept found to have the required defining relationship values.

In most cases, these queries would be designed to return concepts with an associated morphology of 'benign neoplasm' or any subtype of 'benign neoplasm (e.g. 'angiomyolipoma'), and a finding site of 'kidney' or any subtype of 'kidney' (e.g. 'papillary duct of kidney', or 'upper pole, left kidney'). This query could be expressed using the Expression Constraint Language as:

When executed against the January 31st 2015 international edition of SNOMED CT, this query would return the following 12 concepts:

A query, which constrains the defining relationships of matching clinical meanings to specific values can either be represented informally using a set of attribute value pairs, or represented more formally using a machine processable language (e.g. the SNOMED CT Expression Constraint Language).

Approaches to implement such a query include:

• Using the distributed relationships

In this approach, the distributed Relationship file is used directly to compare the target value of each defining relationship with the required attribute value in the query. This approach may be combined with a subsumption testing approach (e.g. transitive closure table) to enable subtypes of the required attribute value to also be matched.

• Comparing normal form expressions

In this approach, the query is represented as a predicate expression containing the constrained attribute values, and the short normal form of this predicate expression is tested for subsumption against each candidate expression (as per the normal form subsumption test).

• Using a Description Logic Reasoner

In this approach, a description logic reasoner (e.g. Snorocket, ELK, Fact++) is used to determine whether each candidate expression is subsumed by the query (represented by a predicate expression).

Many organization-wide implementations of SNOMED CT, such as Kaiser Permanente's HealthConnect EHR and the Danish National Medication Decision Support System, are taking advantage of SNOMED CT's definitional attributes to support advanced analytics.

A number of vendor products are also supporting analytics over SNOMED CT's defining relationships, including Apelon's Distributed Terminology System, B2i Healthcare's SnowOwl terminology server, and Cerner's Semantic Search tool.

Clinical terminologies and classifications serve different but complementary purposes and both are an important part of the healthcare environment. There are therefore some situations in which it is necessary to map SNOMED CT codes to a classification, such as ICD-9 or ICD-10, for analytics or reporting purposes. The differences between the two holds the key to their distinct purpose.

A classification is a hierarchical organization of terms that allows aggregation into categories which can be counted and compared. A statistical classification is mono-hierarchical which means that each code in the hierarchy is classified underneath a single code in the level above. This avoids codes being counted twice because they are grouped into two distinct groupings (i.e. double counting), but means that arbitrary decisions must be made as to where codes are grouped. For example, the ICD-10 code J12 |viral pneumonia, not elsewhere classified| is classified under "Diseases of the respiratory system", but is not classified under "Certain infectious and parasitic diseases". Therefore, a query that asks "Is J12 a respiratory disease?" will return "Yes", while a query that asks "Is J12 an infectious disease?" will return "No".

Unlike clinical terminologies, classifications also explicitly enumerate 'known unknowns' (e.g. 'not otherwise specified (NOS)' and 'not elsewhere classified (NEC)'); they often use a single code to represent several closely related but clinically distinct entities (e.g. H65.9 represents 'allergic otitis media', 'exudative otitis media', 'mucoid otitis media' and others); and they are often presented in the form of coding manuals with rigid, well defined rules of use. Classifications emphasize coding discipline (rather than expressivity). This is helpful for driving formal billing and reimbursement. The lower number of codes also makes assigning prices to each code tractable (e.g. using either ICD-9, ICD-10, or one of the Diagnosis Related Group systems). Classifications are also deployable in low tech environments, including paper or simple spreadsheet based systems.