When performing data analytics over clinical data, it is important to understand the interdependency between the terminology and the structural information model. For example, it is not sufficient to find a diagnosis of 56265001 |heart disease|, and make the assumption that the patient has heart disease. Instead, the surrounding information model must be considered to discover whether this is, for example, a confirmed diagnosis for the patient themselves, a suspected or preliminary diagnosis for the patient, or perhaps a family history of heart disease in the patient's paternal grandfather. Contextual or qualifying information about a code may appear in a variety of places, including:

• Within the information model – for example, a section heading titled "Family History"

• In the same coded data element – for example, precoordinated as "394886001|suspected heart disease|" or postcoordinated as "56265001 |heart disease|: 408729009 |finding context| = 415684004|suspected|"

• In a separate coded data element – for example, Diagnosis = 56265001 |heart disease|, Type = 148006 |preliminary diagnosis|

By understanding where and how this contextual or qualifying information is represented, more appropriate queries can be created.

When the same semantics may be represented in both the information model and the terminology, there is also a risk of ambiguity as to how these two representations should be combined. This is clearly demonstrated by models in which both the information model and the terminology can represent 'negation' or 'absence'. Does the combination of 'negation' in the information model and 'absence' in the terminology indicate:

• Double negative,

• Redundant restatement of the negative, or

• Additional emphasis of the negative?

It is important in these situations to have clear rules about how the semantics in the information model and the terminology should be combined.

The challenge often becomes even greater when heterogeneous data sources are integrated. When different information models represent the same semantics using different combinations of structure versus terminology, retrieval and reuse may miss similar information. To avoid false negatives or false positives in the query results, the integration and/or analytics processes must resolve these differences.

For example, in the figure below, the system on the left uses the 'Family history' structural heading to indicate that the selected disease is a family history, while the system on the right precoordinates this within the terminology. When integrating or querying across these data sources, these semantics need to be harmonized to ensure accurate queries can be performed.

Even when the same information model is used, different systems may populate this model with differing levels of precoordination. For example, the three clinical systems shown below each collect data about a 'suspected lung cancer' diagnosis in a different way. For this reason, when given a common data model, different systems may populate this in different ways. When this occurs, queries must be careful to consider all possible representations of the data, to ensure that contextual and qualifying information about each code is correctly interpreted.

SNOMED CT is in the unique position to be able to resolve many of these challenges, using the techniques described in sections Description Logic Over Terminology and Description Logic Over Terminology and Structure. For example, SNOMED CT enables the computation of equivalence and subsumption between alternative representations of data. For example, the postcoordinated expression : = (which can be represented either in a single data element or using two separate data elements for 22253000 |pain| and 56459004 |foot|) can be automatically determined to be equivalent to the precoordinated concept 47933007 |foot pain| (stored in a single data element).

Some cases exist, however, where SNOMED CT is not currently able to automatically establish equivalence. These cases primarily relate to concepts for which the SNOMED CT concept model does not yet fully model their meaning. For example, the two approaches for representing a 'twin pregnancy' shown below are currently not able to be computed as equivalent using SNOMED CT.

The SNOMED CT concept model continues to be extended to support equivalence and subsumption testing within an increasing number of hierarchies of SNOMED CT.

This section discusses some of the challenges which should be considered when performing analytics over clinical data. Most of these challenges result from the fundamental nature of health record information, and therefore exist irrespective of the code system used. Many of these challenges are able to be mitigated using the unique features of SNOMED CT. The challenges fall into four broad categories:

• Reliability of patient data

• Terminology / information model boundary issues

• Concept definition issues

• Versioning

SNOMED CT offers significant advantages, compared to other code systems, in both performing powerful clinical analytics, and in mitigating many of these challenges.

A new version of the International Edition of SNOMED CT is regularly released (currently every month). The release of National extensions typically follows their own release cycle and have processes established to align with the version of the International Edition on which it depends.

When a longitudinal health record is populated with clinical data over a number of years, it is quite possible that the following may occur:

1. SNOMED CT concepts that were active at the time of recording have since been made inactive

2. SNOMED CT concepts that were primitive at the time of recording have since been defined

3. Reference sets that were used to populate pick lists may have changed

4. The SNOMED CT Concept Model that was used to construct expressions may have changed

To mitigate these versioning issues, SNOMED CT provides the following:

1. For each new version of the SNOMED CT International Edition (released in Release Format 2 -RF2), a set of Snapshot files (containing the most recent version of every component that has ever been released in SNOMED CT), and a set of Full files (containing every version of every component that has ever been released in SNOMED CT). From these files, implementers can choose to create a delta view to support the incremental adaption to new versions of SNOMED CT, or alternatively load a complete current snapshot of SNOMED CT content (with or without old versions). When longitudinal clinical records containing inactive concepts are queried, all prior descriptions and relationships of these inactive concepts can still be queried using these snapshot files. SNOMED CT's RF2 distribution files also record the reason that each inactive component was inactivated, using 'historical association' reference sets.

2. SNOMED CT is maintained on the principle that every SNOMED CT concept identifier should retain its semantic integrity over time, even when its logical definition changes. The semantics of a SNOMED CT concept is established through its Fully Specified Name, and all changes to a concept's defining relationships are intended to improve the machine-readable processing of these semantics. That said, it is possible if required to determine what the logical definition of a concept was at any prior point in time using a Full release of SNOMED CT.

While SNOMED CT is the most comprehensive clinical terminology in the world, containing an extensive set of logic-based definitions which enable a broad range of powerful analytics, some challenges still exist, including:

• Logical versus vernacular

• Minimum sufficient sets

High-quality data collection is imperative to the quality and accuracy of analytics results, irrespective of the terminology used. Whether the focus is decision support, business intelligence, research, or a mixture of all three, data quality is critical. High-quality information is not the consequence of collecting as much data as possible. Instead, it is the product of intentionality and process design.

The factors that may impact the quality of patient data include:

• The design of user interfaces used to capture data

Clinical user interfaces should be designed to make it as easy as possible to find the most appropriate code, and as difficult as possible to enter the wrong code. There are a variety of ways to improve the ease and effectiveness of data entry using SNOMED CT – such as searching over all synonyms, confirming the selected concept using the preferred term or fully specified name, ordering value lists effectively using an ordered reference set, searching using navigation hierarchies, and constraining data entry using subsets.

These techniques can also help to reduce data entry errors by prohibiting invalid input, helping the user to understand the correct meaning of the code selected, and ordering value lists in a clinically safe order (e.g. ordering medications by strength, rather than alphabetically).

• Use of diagnostic criteria to standardize data capture

Diagnostic criteria and their application tends to vary widely according to care setting, patient status and healthcare professional. The consistent ascertainment and recording of even common diagnoses, such as asthma and myocardial infarction is often non-trivial. High quality prospective research studies require that diagnostic criteria for the condition being studied are understood, rigorously applied and accurately documented. In routine clinical practice doing this for potentially thousands of diagnoses in dozens of care settings is normally infeasible. Divergence and inconsistencies in criteria for diagnosis capture can undermine the validity of any conclusions which may be drawn from analytics. SNOMED CT mitigates this issue by allowing the query author to choose a reliable aggregating concept from SNOMED CT's extensive content.

• Consistency of data capture with analytics requirements

Pick lists and constraints should be consistent with both clinical data collection needs and analytic requirements and these should never be in conflict. The presence or absence of particular concepts in value sets within different applications can cause data collection to be inconsistent. SNOMED CT mitigates this by allowing the query author to choose a reliable aggregating concept.

• Loss of meaning during data transformations

Clinical data often undergoes a number of structural transformations and code mappings prior to data analytics being performed, during the process of preparing the data for messaging and/or loading into a data warehouse. In each of these transformations, care must be taken to ensure that the quality of the process is high, and that there is no incremental shift in the clinical meaning of the data. For example, mapping local codes to an alternate code system using non-equivalence maps (e.g. narrow to broad or broad to narrow) will change the clinical meaning of these codes to some degree. Any changes that effect the clinical meaning of the data may have an impact on the quality of data analytics. SNOMED CT helps to mitigate this by supporting the representation of equivalence maps, which can be used when the use case requires.