Predictive medicine involves predicting the probability of disease and implementing measures to either prevent the disease altogether or significantly decrease its impact upon the patient. The outcomes of predictive medicine are often applied to the care of individual patients, but may also inform the deployment of resources to entire populations at high risk.

The goal of predictive medicine is to predict the probability of future disease so that healthcare professionals and the patient themselves can be proactive in implementing lifestyle modifications and increased physician surveillance, such as regular skin exams, mammograms, or colonoscopies. Predictive medicine changes the paradigm of medicine from being reactive to being proactive, and has the potential to significantly extend the duration of health and to decrease the incidence, prevalence and cost of diseases.

Much attention has been focused on the availability of genetic makers of vulnerability to specific illnesses. However the accurate capture of phenotypic (e.g. height and weight, blood pressure), environmental factors (e.g. smoking, alcohol consumption) and other lifestyle factors (e.g. exercise, nutrition, quality of life) is not to be overlooked. For example:

1. Patient is a smoker and has ischemic heart disease ? predict excess risk of myocardial infarction

2. Patient has BRCA1 gene and is a 40 year old woman ? predict (excess) risk of breast cancer

SNOMED CT can help to support predictive medicine by:

• Helping to identify clinical trial candidates

• Helping to analyze clinical data, such as family history, lifestyle and environmental findings, to improve predictive capabilities

• Providing a link between patient data and risk assessment rules, so that rules can be triggered based on subsumption of codes recorded in clinical data. For example, matching against patient records could be improved by defined the above rules as:

Risk: 22298006 |myocardial infarction| 2. Criteria: 412734009 |BRCA1 gene mutation positive| Risk: 254837009 |breast cancer|

Definition

The term 'analytics ' is used broadly in this document to describe the process of extracting useful information from healthcare data.

Most analytical processes are driven by database queries. A 'query' is a means for retrieving information from a database consisting of a machine readable question presented to the database in a predefined format. Queries are used to inform or contribute to a human-readable report or produce a machine-actionable response. A human-readable report may be a list of patients, a graph, historical or projected resource utilization figures, or a summary dashboard display. Machine-actionable responses may include populating an order for a new laboratory test, based on the results of a previous test, or placing an order to restock medical devices on a hospital ward.

Scope and Purpose

Full benefits of electronic health records only accrue with the implementation of effective retrieval and reuse of clinical information. The scope of analysis of health record data may cover:

• An individual patient, across time and/or care providers;

• An individual healthcare worker;

• Patient groups or cohorts, based on demographics, diagnoses, treatments or interventions;

• Enterprise groups, based on teams, wards, clinics, institutions or providers;

• Geographical groups, based on a local area, town, region or country.

The following figure illustrates the three main purposes of analytics with SNOMED CT. These are:

1. Clinical assessment and treatment;

2. Population monitoring; and

3. Research.

SNOMED CT may be used to support analytics that:

• Improves the care of individual patients by enabling:

  • Retrieval of relevant information that better supports clinicians in assessing the condition and needs of a patient

  • Clinical records to be integrated with decision support tools to guide safe, appropriate and effective patient care – for example, allergy checking and potential drug contraindications identified at the point of prescribing

Analytics with SNOMED CT may be deployed on a wide range of data sources as summarized in the table below. These data sources are also known as the 'substrate' of the analytics. Please note that data which is not natively coded using SNOMED CT may be transformed using one of the techniques described later in this guide. These techniques may be used to transform heterogeneous data recorded using free text or a variety of code systems into SNOMED CT, which can serve as a common reference terminology for analysis.

Direct and indirect substrates for SNOMED CT based analytics

There are a number of ways in which SNOMED CT can be used in systems to support analytics, including:

• Analyzing free text with clinical Natural Language Processing (NLP) techniques, which use SNOMED CT as a resource;

• Mapping coded clinical data from SNOMED CT to a classification, to enable analysis using the features of the classification;

• Querying clinical data using the machine-processable definitions of clinical concepts defined in SNOMED CT;

These approaches (and others) are described in more detail in the following chapters.

Electronic patient record systems typically require high performance, high reliability and no (or limited) downtime. Any operation that effects these key criteria need to be kept to an absolute minimum, so as not to disturb the clinical and documentation activities of busy clinicians.

Many analytics activities require large volumes of data to be processed, which may slow down or even 'lock out' clinical transactions that are being performed at the same time. For this reason, population-based analytics and clinical research is typically not performed directly on patient records in their native clinical system. Instead, analytics directly over 'live' patient records tends to be restricted to point of care analytics activities, such as historical summaries, clinical decision support and point of care reporting. These analytics activities tend to demand the most up to date data possible to ensure its accuracy. They also tend to only require data for a single patient, which can be efficiently accessed using a patient identifier index.

The following figure illustrates a simple architecture in which the data store for patient records is directly used for reporting and analytics purposes.

Clinical decision support systems (CDSS) are designed to assist clinicians at the point of care on decision making tasks. Examples of applications of clinical decision support include:

• Checking conformance with clinical guidelines and protocols

• Guide clinicians through complex care pathways

• Protect against errors in prescribing (e.g. drug-drug and allergy-drug contraindication checking)

• Highlight critical laboratory results

• Display clinical knowledge resources upon request, that are relevant to the given patient's diagnosis, symptoms, procedures or medications

Most CDSSs consist of three parts:

1. The knowledge base, with rules and guidelines – for example:

   1. IF drug = << 48603004 |warfarin| AND 77386006 |pregnant| THEN alert user

   2. IF drug has active ingredient = << 387494007|codeine| AND past history of 292055008 |codeine adverse reaction| THEN alert user

Using a combination of SNOMED CT techniques, including mapping, subsets, subsumption and defining relationships, SNOMED CT helps to support the inference engine in determining the appropriate rules to execute.

For example, Kaiser Permanente's HealthConnect system uses SNOMED CT to support efficient translation of its business rules into decision support rules. The National Board of E-Health in Denmark is developing a centralized decision support service based on the Danish SNOMED CT drug extension, which utilizes the hierarchical and defining relationships of SNOMED CT.

A number of commercial tools also use the capabilities of SNOMED CT to implement Clinical Decision Support. For example, Cambio's COSMIC tool binds GDL (Guideline Definition Language) rules to SNOMED CT concepts to support the triggering of appropriate rules. Allscript's Sunrise InfoButton™ feature provides relevant medical reference content to clinicians wherever patient care decisions are made, by using SNOMED CT encoded patient problem lists and medication data to query third-party medical content. The Epic system provides decision support alerts (called 'Best Practice Advisories'), which are able to use the SNOMED CT hierarchy to help define their criteria. And First DataBank delivers clinical decision support solutions linked to SNOMED CT, primarily to detect safety issues arising from certain combinations of medications, diagnoses and drug adverse reaction histories.

Trend analysis is the practice of collecting information and attempting to spot a pattern, or trend, in the information. Trend analysis often refers to techniques for extracting an underlying pattern of behavior in a time series, which would otherwise be partly or nearly completely hidden by noise.

Detecting changes of either incidence or prevalence of a particular disease, treatment, procedure or intervention over time has major utility for population health monitoring, prediction of demand and effective resource allocation at enterprise and national levels. One challenge that is encountered when analyzing routinely collected patient data for trends, is distinguishing minor changes in coding style from real changes in disease incidence. Simply counting the use of individual concept identifiers may be highly misleading. For example, a fall in the use of the code 22298006 |myocardial infarction| might reflect a shift to using more specific codes (such as 314207007 |non-Q wave myocardial infarction| or 304914007 |acute Q wave myocardial infarction|), rather than a reduction in the incidence of myocardial infarctions. Use of subsumption testing on SNOMED CT encoded data can enable higher level trend analysis to be performed over more specific coded data.

SNOMED CT's polyhierarchy allows trends to be analyzed from multiple perspectives. However, deciding which level of aggregation to use for trend analysis can be arbitrary. Novel approaches to this task are emerging as the demand for trend analysis over SNOMED CT enabled data increases.

The UK Data Migration Workbench, for example, includes a trend module which analyses the frequency with which individual SNOMED CT codes are used in the Electronic Patient Record (EPR) instance data, looking for those whose recording frequency has changed over the course of the data collection period. It also includes an Induce module, which performs a more sophisticated analysis of case mix and caseload trends within a clinical department. Instead of returning the most frequently used individual codes, the Induce module identifies the most frequently used types of codes. For example, an emergency department may use roughly 500 different SNOMED CT codes for a laceration in a particular anatomical location. While none of the site-specific codes may appear in a list of most common codes, the descendants of 312608009 |laceration| may collectively account for a significant part of the department's workload.

Clinical audit seeks to improve patient care and outcomes through systematic review of care against defined standards and the implementation of change. It informs care providers and patients where their healthcare services are doing well and where there could be improvements. The key component of clinical audit is that performance is reviewed (or audited) to ensure that what should be done is being done , and if not it provides a framework to enable improvements to be made.

Clinical audits can be performed in primary care facilities, individual clinics, hospitals, enterprises or jurisdictions. Audit can have major beneficial impacts in ensuring the consistent delivery of quality healthcare. The questions asked in audit are often chosen pragmatically according to local data collection practices. For example

• What proportion of patients invited to attend cervical screening did so?

• How many patents with ischemic heart disease are receiving appropriate drug treatments?

• Are all patients with diabetes mellitus reviewed within a stated time interval?

Current audit schemes use a combination of reporting against the classifications or questions specifically collected for audit purposes. SNOMED CT will facilitate an increase in such audits being able to collect some of the data by extracting data from the patient record thus reducing the additional burden of collection; it will also enable more a more accurate picture from say tertiary centers where some of their procedures may fall into the NOS or NEC classification and provide an unrepresentative comparison with other centers when the procedures are complex and innovative/new.

SNOMED CT is well suited to service the ad hoc requirements that emerge in clinical audit questions, using the techniques described before. Using the SNOMED CT codes recorded during care delivery can reduce the additional burden of data collection specifically for audit purposes. SNOMED CT may also facilitate more accurate audit results than classifications, by distinguishing between distinct concepts (e.g. clinical findings or procedures) which may fall into the 'Not Otherwise Specified' or 'Not Elsewhere Classified' categories in these classifications.

A number of vendor products, such as Cerner's PowerInsight® Data Warehouse, are able to support clinical audit using SNOMED CT enabled analytics tools.

IMO produces a medical terminology service for healthcare solutions, allowing over 2,500 hospitals and 350,000 clinicians to focus on patient care. IMO bridges the information gap between clinicians, coders, and patients in the US and internationally. IMO enable and support the accurate capture and preservation of clinical intent for clinical documentation, decision support, reimbursement, reporting, data analysis, research, and health education.'

IMO's clinical interface terminology is designed pragmatically to capture clinical intent at point of care. However it is also intended to enable and simplify the adoption of standard ontologies by vendor partners.

By choice, the editorial process requires all IMO interface terms to have one or many qualified maps to SNOMED CT. Clients can then use SNOMED CT to drive reporting, analytics, clinical decision support, and research.

The following examples demonstrate how IMO uses SNOMED CT for analytical purposes:

1. Helping patients find health professionals who have expertise or interest in specific areas of medicine. These areas include disorders, procedures, devices, medications, patient demographics, and medical specialties. These areas of expertise or interest include those that are self-reported by clinicians and those documented in clinical encounters. The search algorithms use hierarchies in SNOMED CT to retrieve and rank search results.

2. Helping clinicians use patient diagnoses and procedures documented at varying levels of granularity to find appropriate patient education materials using SNOMED CT is-a hierarchies.

3. Grouping together related clinical concepts in patient records for creating focused patient reports and driving clinical workflows.

4. Forming subsumption queries for cohort selection within patient data repositories and document libraries.

5. IMO uses natural language processing (NLP) to extract information coded in SNOMED CT from clinical narratives.

The UK Terminology Centre Data Migration Workbench (DMWB) is designed to support the NHS Primary Care Summary Care Record, Primary Care Systems of Choice and Data Migration programs. This tool demonstrates some of the properties and advanced uses of the data migration and mapping products published by the UKTC and the terminologies and classifications that they link.

The workbench uses SNOMED CT to perform novel and sophisticated analyses of patient data. It has immediate 'off the shelf' international utility despite the inclusion of the UK-only terminologies within the standard tool distribution.

The software contains SNOMED CT, Read Codes Version 2 and CTV3, maps between these and maps to ICD-10 International Edition (UK map not the same as the SNOMED International one) and OPCS Classification of Interventions and Procedures (OPCS-4). The Workbench modules support:

1. Searching and browsing the hosted code systems;

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

SNOMED CT plays a central role in many Apelon products and projects. Apelon tools feature navigation and visualization tools to support SNOMED CT in a variety of ways. Apelon also undertakes bespoke content development and consultancy work in healthcare and biomedicine using SNOMED CT.

The Apelon Terminology Development Environment (TDE) software was used by the College of American Pathologists to build and maintain the SNOMED CT International Edition prior to the formation of IHTSDO. Apelon software continues to be used by major healthcare organizations and some National Release Centers to maintain SNOMED CT extensions, maps and subsets.

The Apelon Distributed Terminology System (DTS) offers a variety of human and computer interfaces to navigate, visualize and query SNOMED CT. DTS allows users to create custom extensions to SNOMED CT and perform incremental description logic classification to ensure that the extensions are consistent with the base version of SNOMED CT. DTS permits navigation, and side-by-side comparison of concepts across multiple SNOMED CT versions. Features of Apelon DTS supporting analytics and data retrieval include:

Population-based analytics encompasses those analytics services that benefit entire populations, including trend analysis, public health surveillance, pharmacovigilance, care delivery audits and healthcare service planning. Population-based analytics contributes to public health programs by helping to identify health threats, inform public policy and manage healthcare resources.

Efficient healthcare delivery and service planning depends on high quality clinical data. Clinical data is typically scattered between multiple different healthcare providers using different clinical systems. Collating this information for analysis requires both standardized terminologies and common information models. Identifying relevant and useful facts in large volumes of collated data also requires this data to be accurate, meaningful and machine processable.

SNOMED CT supports population-based analytics in a number of ways. Firstly, it enables more accurate capture of clinical data by allowing it to be represented at the appropriate level of clinical detail. Secondly, it supports the integration of disparate clinical data sources by serving as a reference terminology into which free text and other code systems can be mapped. And thirdly, it enables more meaningful and powerful queries to be performed over the data using the descriptions, hierarchies and logic-based definitions of each concept.

Vendor products, which provide population health solutions include Caradigm's Intelligence Platform, Allscript's Clinical Quality Management and Clinical Performance Management tools, Cerner's PowerInsight® Data Warehouse and Epic's analytics and reporting suite.

In this section, we consider how user interfaces can be designed to harness the capabilities of SNOMED CT, and to make clinical querying more accessible to non-technical users. We describe both user interfaces for authoring queries, as well as user interfaces for viewing query results.

Egton Medical Information Systems (EMIS) began in the 1980s in a rural practice in Egton in North Yorkshire, United Kingdom. The founders, Dr Peter Sowerby and Dr David Stables, wrote the software and adopted the NHS Read Code system during the 1980s. A series of systems have since been deployed in over half of England's primary care practices. The latest product (EMIS Web) moved to a data center based architecture, thin client front end and built in secure web based patient access facilities.

EMIS software looks after the patient records of nearly 40 million people in the UK (30 million using EMIS Web). More than 2 in 3 of those patients can book appointments and order repeat medications online, and more than 1 in 3 can view their own medical record.

EMIS Web features significant advances in terminology use with EMIS adopting a phased approach to SNOMED CT. EMIS Web displays a familiar coding structure based on the construction of a Read Version 2 navigational hierarchy within SNOMED CT. The principle design objective has been to enable SNOMED CT within the clinical system to meet specific requirements, including:

• Supporting advanced decision support capabilities;

• Supporting interoperability within healthcare through the sharing of coded data;

• Supporting standards required in NHS General Practice Systems of Choice (e.g. the NHS mandates SNOMED CT coding within the National Summary Care Record service);

• Broadening the scope of terminology use to support the recording of encounters in disciplines such as dentistry and community healthcare;

• Supporting the mandatory requirement for the Electronic Prescription Service to natively use the UK SNOMED CT drug extension (i.e. NHS dictionary of medicines and devices, dm+d).

By using coded structured records and providing access to the specialist domain terminology available in SNOMED CT, EMIS has been able to extend the user base of EMIS Web by more than 20,000 new NHS users over the last year. These include practice nurses, community matrons, child health and mental health nurses, palliative care clinicians, diabetes specialists, physiotherapists and psychologists.

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

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.

Overview

First DataBank (FDB) were in the first wave of suppliers to recognize the potential of SNOMED CT and begin to integrate support for SNOMED CT into their existing clinical decision support solutions. Their primary use of SNOMED CT in the patient's electronic health record (EHR) is to detect safety issues arising from certain combinations of medications, diagnoses and drug adverse reaction histories. In 2006 FDB introduced support for products and packs encoded using the NHS SNOMED CT UK Drug Extension. In the following year FDB launched new modules within the Multilex drug knowledge base supporting Drug-Condition Checking and Drug Sensitivity (Allergy) checking for the SNOMED CT EHR.

System vendors implementing Multilex decision support within SNOMED CT-enabled medical record applications include CSC (Lorenzo system), EPIC and JAC in secondary care, and CSE Servelec (RiO system) in community/mental health. Currently only pre-coordinated expressions are supported by the live Multilex SNOMED CT based decision support solutions.

Drug-Condition Contraindication Checks

The contraindications module alerts the clinician when a medication proposed to treat a disorder is incompatible with another of the patient's disorders or clinical states. For example a beta blocker like propranolol might be prescribed to treat someone with high blood pressure. However if that patient also has asthma, their asthma might significantly worsen or a dangerous acute attack might be produced by the drug.

Thousands of such drug-condition contraindications exist and nearly all medications have at least one. Without point of care decision support, the clinician must rely on memory or search reference sources for each drug prescribed. Also there is a risk that a contraindicating condition may be in the record but unknown to the prescribing clinician.

In a SNOMED CT enabled EHR, both the drugs (e.g. ) and the conditions (e.g. ) are encoded.

Internally FDB maintain their own local ontology representing only those conditions relevant to prescribing decision support (e.g. asthma, gastric ulcer, heart disease, pregnancy). The items in this ontology are linked to SNOMED CT codes as required to support this (contraindication checking) use case. These SNOMED CT links range from the obvious, such as linking to FDB's 'asthma', to the more subtle, such as linking to FDB's 'pregnancy'.

FDB reviews the relevant SNOMED CT domains (i.e. , and ) for concepts applicable to drug-condition checking. The FDB linking tool uses the SNOMED CT hierarchy and a SNOMED CT derived transitive closure table to locate and suggest links from the FDB ontology to SNOMED CT concepts. Other SNOMED CT relationships also help find related concepts via the browser but discovery is mainly by clinical knowledge combined with description based searches assisted by the rich synonym content of SNOMED CT.

The sensitivities module alerts the clinician when a proposed drug for a patient is either stated in that patient's record to have caused a previous adverse reaction or when an adverse reaction has occurred to a similar drug and thus likely to elicit a similar adverse response. For example, a patient allergic to penicillin is likely to react to most other drugs containing a β-lactam ring in their molecular structures.

In a similar way to how FDB links SNOMED CT conditions to its own internal ontology, SNOMED CT concepts which suggest allergy or previous adverse reactions to a medication are also linked to an internal FDB ontology for representing medication ingredients. This ontology is designed specifically to support allergic and adverse reaction cross-reactivity.

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.

While there is a strong trend towards the direct coding of clinical data, the capture and retention of free text remains essential to record broader narratives about clinical history, physical examinations, clinical procedures and investigation results. Wider deployment of medical transcription technologies featuring speech recognition also add to the volume of free text in electronic format. Medical literature, clinical guidelines and published clinical research also remains largely in free text.

Natural Language Processing (NLP) is a linguistic technique that enables a computer program to analyze and extract meaning from human language. Clinical NLP, using SNOMED CT's concepts, descriptions and relationships, may be applied to repositories of clinical information to search, index, selectively retrieve and analyze free text. These techniques can be used to extract SNOMED CT encoded data from free-text patient records, and also support the retrieval of clinical knowledge documents.

It should be noted that while clinical NLP techniques have increased in sophistication over recent years, it is not possible to guarantee full accuracy or completeness using a computer-based algorithm. Spelling errors, grammatical errors, abbreviations, unexpected synonyms, unusual vernacular (i.e. local) phrases, and hidden contextual information continue to provide challenges that human intelligence is uniquely equipped to handle.

The example shown below in shows a free text section of a discharge summary that has been processed with clinical NLP to extract a set of potential SNOMED CT clinical findings and procedures. In order to ensure the correctness of this automatic encoding, the application should present this list of extracted codes to the user for confirmation, giving them the opportunity to refine, delete or append codes.

Allscripts released their first version of Vocabulary Management utilizing SNOMED CT in 2005. Since then Allscripts systems have been able to utilize SNOMED CT for clinical decision support and reporting. Allscripts uses a common terminology platform for all three electronic health record systems: Sunrise Clinical Manager™, Sunrise Acute Care™ and Sunrise Ambulatory Care™.

When a query is performed over a health record that requires clinical terminology, the terminology service always returns a SNOMED CT code. If the primary code stored in the health record is not SNOMED CT (e.g. ICD-9 or ICD-10), then the terminology service performs the mapping to SNOMED CT, saves the SNOMED CT code in the health record next to the original code (to make future queries more efficient), and returns the SNOMED CT code.

Allscripts Sunrise applications are able to link SNOMED CT to all orders, order form pick lists, observations pick lists and results.

Sunrise Clinical Manager integrates reference content from medical publishers into clinician workflow. The Sunrise InfoButton™ feature provides clinicians access to relevant medical reference content wherever patient care decisions are made, without requiring them to log into or visit another site. Sunrise InfoButton uses encoded patient problem lists and medication data elements to query third-party medical content selected by the clinician. Several healthcare reference content providers index their content using SNOMED CT. This enables the delivery of on-topic information without manual searching. Resources with SNOMED CT indexed content include Wolters Kluwer Clin-eguide which provides context-specific evidence on particular medical issues and diseases and Lexi-Comp, providing drug and drug-interaction information, diagnosis and disease management, formulary services, patient-education resources and clinical support 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.

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').

Clinical research is a branch of healthcare science that determines the safety and effectiveness of medications, devices, diagnostic products, and treatment regimens intended for human use. Clinical research may be used for the prevention, treatment, diagnosis or for relieving symptoms of a disease. In contrast to clinical practice, which applies established treatment regimes, clinical research collects evidence to extend knowledge and establish the value of novel treatments and other patient management practices.

Clinical research typically involves the analysis of data from well-defined and homogenous groups of patients with a specific disease, at a specific stage, receiving similar treatments and often without significant co-morbidities. The data may be captured prospectively or retrieved retrospectively.

SNOMED CT helps clinical research activities by assisting in the identification of clinical trial candidates, enabling the powerful analysis of trial data, supporting predictive medicine, and improving the effectiveness of semantic search over clinical knowledge.

In this section, we discuss three key aspects to clinical research that can benefit from the use of SNOMED CT: identification of clinical trial candidates, predictive medicine, and semantic search.

SNOMED CT can be used to assist the process of identifying clinical trial candidates for recruitment into formal clinical trials. Subsets of findings, procedures or medications can be used to filter trial candidates based on their clinical conditions or treatments. Subsumption techniques can be used to identify suitable candidates, irrespective of the level of granularity in which their clinical data is stored. SNOMED CT defining relationships can be used in a number of ways – for example, identifying patients with diseases of specific anatomical sites, with certain morphologies; patients who are taking medications with specific ingredients or dose forms; and patients who have had procedures on a specific body site.

Commercial tools, which can be used to support clinical research include Cerner's clinical research module (PowerTrials), which offers patient identification functionality.

Point of care analytics encompasses those analytics services that directly benefit individual patients and clinicians, including historical summaries, decision support and point of care reporting. These analytics tasks typically involve the summarization and mapping of patient data, and the linking of terminology with clinical knowledge artefacts.

Provide Feedback

Snow Owl is a clinical terminology platform developed by B2i Healthcare. The Snow Owl technology family is deployed in over 2,500 locations in 83+ countries worldwide. The Snow Owl® terminology server has been licensed by SNOMED International to form the basis of SNOMED International Terminology Server.

The Snow Owl® terminology server scales from a small kernel embedded in single-user products to n-tier clusters supporting hundreds of concurrent users. Clients can easily access and query SNOMED CT, LOINC, ATC, ICD-10, and dozens of additional terminologies via REST or Java APIs. Collaborative distributed authoring is also supported, including creating and maintaining local code systems, mapping between terminologies, and creating terminology subsets.

Terminology server features include:

• Extensive support for expression constraints and semantic queries, including Extended SNOMED CT Compositional Grammar and Groovy scripts.

Mapping data from clinical records encoded using non-SNOMED CT code systems to SNOMED CT for analysis may be considered when there is a requirement to produce:

• Management information for care service audit or delivery planning

• Statistical information for epidemiology

SNOMED CT is a clinically validated, semantically rich, controlled terminology. SNOMED CT is comprised of meaning-based concepts, human-readable descriptions and machine-readable definitions. SNOMED CT is used within electronic health records to support data capture, retrieval, and subsequent reuse for a wide range of purposes. SNOMED CT is also used to enable or enhance analysis of patient records and other clinical documents containing no original SNOMED CT content.

SNOMED CT hierarchies and formal concept definitions allow selective information retrieval to support analysis – from patient-based queries to operational reporting, public health reporting, strategic planning, predictive medicine and clinical research. As the SNOMED CT encoding of healthcare data increases, so too have the benefits being realized from analytics processes performed over this data.

The purpose of this document is to review current approaches, tools and techniques for performing data analytics using SNOMED CT and to share developing practice in this area. It is anticipated that this report will benefit members, vendors and users of SNOMED CT by promoting a greater awareness of both what has been achieved, and what can be achieved by using SNOMED CT to enhance analytics services.

This document presents different data approaches, tools, terminology techniques, query languages, data architectures and user interfaces that may be used in performing analytics using SNOMED CT. Analytics services considered include patient-based queries, operational reporting, the application and audit of evidence-based medical practice, strategic planning, predictive medicine, public health reporting and clinical research. The benefits and challenges of these approaches are also presented. The case study summaries describe a selection of SNOMED CT analytics projects and tools.

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.

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.

While the use of SNOMED CT for analytics does not dictate a particular data architecture, there are a few key options to consider. In this section, we describe the major categories of data architecture that may be used to perform analytics over SNOMED CT enabled patient data, including:

1. Analytics directly over patient records;

2. Analytics over data exported to a data warehouse;

This section includes brief reviews of a variety of projects which implement or support analytics over SNOMED CT enabled data.

We welcome additional input to this section and anticipate updates to this report as new information becomes available.

This playlist brings together all videos on searching and data capture using SNOMED CT from the SNOMED International Implementation Course. The videos introduce key concepts, practical implementation considerations, and real-world examples to help you understand how SNOMED CT can be applied to enable data analytics in health information systems.

Open playlist on YouTube:

👉

How to navigate the playlist in GitBook

When a YouTube playlist is embedded in GitBook, only one video is shown on the page at a time, but all playlist videos are still available.

As discussed in the Section about Substrates for Analytics, not all electronic health records represent clinical data using SNOMED CT. However, even when health records use free text or other code systems, it is still possible to use SNOMED CT for analytics over this data if the data is prepared appropriately. For example, Natural Language Processing can be used to encode free text data in SNOMED CT, subsequently enabling more sophisticated analytics to be performed. Similarly, clinical data using other code systems can be mapped into SNOMED CT to provide similar benefits.

In this section, we discuss these alternative ways of preparing clinical data for analytics using SNOMED CT.

Provide Feedback

A data warehouse is a central data store of integrated data from one or more disparate sources, used for reporting and data analysis. While operational systems are optimized for the preservation of data integrity and the speed of recording transactions, data warehouses are optimized for the high performance execution of queries.

The typical Extract-Transfer-Load (ETL) based data warehouse uses a staging layer to clean the extracted data and transform it into a homogeneous structure and standardized terminology. During this process, the techniques from Preparing Data for Analytics, such as mapping codes to SNOMED CT, can be used to prepare the data for analytics. The transformed data is then loaded into the data warehouse, and indexed, so that optimized analysis of the data can begin.

The benefits of using a data warehouse include:

• Data from multiple heterogeneous sources can be integrated to enable consistent querying over data from all sources

• The operational clinical system does not suffer performance degradation when running large analytics queries over historical data

• The data quality can be improved by cleaning the data, and mapping non-SNOMED CT codes to SNOMED CT

• The data can be restructured to optimize query performance

The following figure illustrates an architecture in which the patient record data is extracted from its operational data store and loaded into a data warehouse for reporting and other analytics purposes.

Commercial data warehousing solutions that support SNOMED CT include Cambio's COSMIC Intelligence, Cerner's PowerInsight Data Warehouse (PIDW) and Cerner's Health Facts Data Warehouse.

When it comes to reporting needs, the preference of most clinicians is to 'collect once and use many times'. SNOMED CT enables this goal to be achieved by allowing data to be captured at the appropriate level of detail and then queried at the same or less detailed level. SNOMED CT supports point of care reporting requirements using any (or all) of the SNOMED CT analytics techniques described before, including subsets, subsumption, defining relationships and description logic. Examples of point of care reporting requirements may include:

• Helping clinicians remember preventative services (reminders)

• Identifying patients with care gaps and risk factors

• Monitoring patient compliance with prescribed treatments

• Reporting clinical data to registries, such as cancer, stroke, and infectious disease registries

• Billing and reimbursement

When supporting a reporting requirement in which double counting must be avoided (such as statistical reporting, administrative reporting, billing, or reimbursement), SNOMED CT codes can be mapped to statistical classifications (such as ICD-9 and ICD-10).

When the source data uses a coding system without the same reporting capabilities as SNOMED CT, or when a variety of coding systems are used, coded data can be mapped into SNOMED CT to support the reporting requirements.

When a SNOMED CT enabled query over patient records is executed, the results of this query can be visualized in a number of ways, including tables, charts, scatter diagrams and colored epidemiology maps. While some of these results visualization techniques can be used with any coding system, others are able to utilize the unique features of SNOMED CT in powerful ways.

For example, the following figure shows a report produced by Cerner's data warehouse query tool. This tool uses a simple graphical interface which directly creates powerful reports using the SNOMED CT hierarchy content. The screenshot shows a report of attendances with diagnoses which are a descendant of the SNOMED CT concept 417746004 |traumatic injury|.

SNOMED CT's rich polyhierarchy provides a vast number of potential 'aggregators' for analytics, and possible views of SNOMED CT encoded data. This polyhierarchy can be exploited by visual exploratory data analysis tools to enable the visual inspection of complex datasets.

For example, the NHS have been using the Gephi open-source network analysis and visualization software, to explore SNOMED CT encoded renal datasets.

The first representation below shows a projection of all concepts directly coded in the patient data, with the node size reflecting the frequency of each code. 36689008 |acute pyelonephritis| has a high frequency in the data and is therefore represented by a big node, while 254915003 |clear cell carcinoma of kidney| has a low frequency in the data and is therefore represented by a small node.

Using a simple concentration algorithm, which aggregates subsumed concepts up to a given threshold, the representation below is achieved. In this representation, the size of the purple nodes reflects the frequency of each code plus its subtypes, the size of the blue nodes reflects the frequency of each code's subtypes, and the size of the red nodes reflects the frequency of each code on its own. This enables trends to be visually detected – for example, 36171008 |glomerulonephritis| and 36171008 |acute pyelonephritis| - even when the frequency of these concepts themselves is relatively low.

Innovative data visualization and analysis tooling is expected to become much more widespread as the powerful capabilities of SNOMED CT content are increasingly utilized.

Caradigm is a joint venture between Microsoft and GE Healthcare, which is dedicated to population health management. Caradigm's cornerstone product is the Intelligence Platform. This platform can connect over 295 types of source systems, including Allscripts, Athenahealth, Cerner, Epic, GE, McKesson and Meditech. Data from disparate systems within one or more healthcare organizations is collected, normalized and standardized to enable applications to leverage this data in a unified and consistent way.

Caradigm's solutions provide explorative, comparative, predictive and guided elements aimed at analyzing the disparate data and driving the insight that is gained into action. Caradigm's three main solution areas are:

• Healthcare analytics (including clinical, operational and financial analytics);

• Coordination management; and

• Wellness promotion and patient engagement.

Some of Caradigm's customers use SNOMED CT natively in their clinical systems, while others use natural language and other code systems. In order to aggregate data from disparate sources, it must first be standardized by mapping into a common code system. Code systems used to standardize the disparate data include SNOMED CT, ICD-9 and ICD-10. By standardizing the data, users are able to leverage the analytics tools - for example, to understand trends within different diagnoses, to look at a comprehensive list of everything that has happened to a patient in a longitudinal patient record, and to support care management by displaying the different diagnoses or problems of a patient in a consistent manner.

Caradigm currently implements an approach to SNOMED CT based analytics using clinical value sets. These value sets are developed manually by a team of clinical analysts for topics such as diabetes and heart disease. Clinical users are then able to create queries in a user friendly interface, which allows them to (for example) define cohorts built on criteria such as age, gender, specific diseases, conditions, medication or other treatments. These queries are then converted behind the scenes into SQL statements which are executed against a SQL Server database and return records containing data in the selected clinical value sets.

Caradigm also has Natural Language Processing (NLP) tools, which are able to extract and encode data, such as problems and medications, from natural language notes within documents such as discharge summaries and radiology reports.

As part of their strategic roadmap, Caradigm are exploring ways to enhance the capabilities of their tooling platforms by leveraging the architecture of the terminology sets that they are using for analytics. In particular, they are planning to start utilizing the hierarchical and non-hierarchical relationships of SNOMED CT to enable more powerful query capabilities and to extend NLP processing options.

The 3M Healthcare Data Dictionary (HDD) is a controlled medical vocabulary server. The HDD has been continuously expanded and maintained for over 15 years, both as a standalone product and embedded within several of 3M's core products and services. The 3M HDD enables mapping and management of medical terminologies, integration of content and standardization of healthcare data. The 3M Healthcare Data Dictionary incorporates a selection of standard healthcare terminologies, including (but not limited to) SNOMED CT, LOINC, RxNorm, ICD-9-CM and ICD-10-CM.

Concepts in the HDD are grouped and organized using both hierarchical and non-hierarchical relationships. One of the hierarchical relationships in the HDD is SNOMED CT's 'is a' relationship which allows users to programmatically use and analyze SNOMED CT concepts captured at various levels of granularity. The analytics capabilities of the HDD are also extended through the use of other relationship types.

Data Warehousing

The content within the HDD makes a key contribution to analytics in several settings. For example one large academic research institution uses the HDD to integrate over 100,000 medication concepts from disparate systems for comprehensive data assimilation. Many of the medication concepts are mapped to RxNorm codes and linked through a 'has ingredient' relationship to SNOMED CT codes.

The 3M HDD has a knowledge base and poly-hierarchical structure that defines the relationships between each clinical drug.The following figure shows the relationships that exist for Ramipril including the links to SNOMED CT content, which can be used to query the data warehouse. The knowledge base allows the hospital's researchers to customize their searches by various levels of granularity and organize their clinical content into meaningful relationships.

The HDD supports researchers in performing data mining by:

• Extracting and mapping clinical metadata using a streamlined, systematic approach;

• Translating diverse clinical terminologies using a coded medical vocabulary;

Pharmacovigilance is the collection, detection, assessment, monitoring and prevention of adverse effects with pharmaceutical products. It is concerned with identifying the hazards associated with pharmaceutical products and minimizing the risk of any harm that may come to patients. An important part of pharmacovigilance is postmarketing surveillance, which monitors the safety of a pharmaceutical drug or medical device after it has been released on the market. Since drugs are approved on the basis of clinical trials, which involve relatively small numbers of people, postmarketing surveillance plays an important part in further refining, confirming or denying the safety of a drug in the general population.

Pharmacovigilance uses a number of data sources to assess and monitor the safety of licensed drugs, including clinical trial data, medical literature, spontaneous reporting databases, prescription events, electronic health records, and patient registries. Data mining of large volumes of clinical data can be used to highlight potential safety concerns. However, current mechanisms to analyze this data is often both costly and insensitive.

The availability of large datasets of richly encoded SNOMED CT data within longitudinal healthcare records can greatly assist pharmacovigilance. Where SNOMED CT is not used natively to capture clinical data, free text narrative and other code systems may be mapped to SNOMED CT to support a homogeneous approach to querying across diseases, signs and symptoms, lab results, medications, devices, procedures, allergies, adverse reactions, body sites and substances. SNOMED CT's polyhierarchy and defining relationships, which provide links between these domains provide a rich source of meaning-based information across which queries can be performed.

Many drug regulatory authorities and pharmaceutical companies currently use the Medical Dictionary for Regulatory Activities (MedDRA) to classify adverse drug events. MedDRA is an international standard adverse event classification used from pre-marketing through to post-marketing activities. However, as MedDRA was not designed to support routine clinical data collection, its penetration into clinical systems is limited. Therefore mapping from SNOMED CT to MedDRA would enable both styles of analysis and reporting to be performed from the same clinical data. The UK Medicines and Healthcare products Regulatory Agency (MHRA) is working (with input from the MedDRA Maintenance and Support Services Organization) to develop a mapping from a subset of SNOMED CT to MedDRA for this purpose.

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.

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|)

A Virtual Health Record (VHR) provides a virtual view of heterogeneous data sources, using a common data model. In contrast to the data warehousing approach in which heterogeneous data is extracted, transformed and stored in a homogeneous form, the VHR approach does not require clinical data to be extracted from existing data stores. Instead, logical queries are defined in terms of a common data model and then transformed into a set of physical queries which can each be executed locally on an individual data store. The following figure illustrates an architecture which supports querying over a VHR.

The process of transforming the logical query into separate physical queries may involve translating:

• The Query Language – from a common query language to the local data store's native query language

• Data Model References – from the common data model to the local data model

• Terminology References – from the standard terminology to the local code system

For example, if the user poses the following SQL query, written in terms of the VHR's common data model, to select those patients with a diagnosis that is a subtype of 40733004 |infectious disease|:

SELECT patient_id FROM Health_Records

WHERE diagnosis IN (<40733004 |infectious disease|)

This query may be translated into the following 3 queries for local execution on each data store:

Data Store A:

Patient_record/patient_id[@diagnosis=typeOf(INF)]

Data Store B:

SELECT id FROM EHR NATURAL JOIN DSummary

WHERE discharge_diagnosis IN (descendantsOf (40733004)

Data Store C:

SELECT patient FROM record

WHERE diag IN (<40733004)

Similarly, when the query results are returned by each data store, these need to be transformed and mapped into the common data model and then combined for presentation to the user.

The VHR approach provides an alternative architecture to a data warehouse for integrating heterogeneous systems. It is most commonly used when copying clinical data into a data warehouse is not possible (e.g. due to legislative requirements), or when the currency of the data is imperative. The challenges with this approach lie with the potential complexity of the transformations required. The implementation of this approach is considered to be a type of heterogeneous distributed database.

Building on the capabilities of its CLiX Clinical Natural Language Processing (CNLP) platform, Clinithink has created a solution to enable the analysis of healthcare data sourced directly from clinical narrative called CLiX ENRICH. This technology can be integrated into existing healthcare solutions to process any relevant narrative and encode the key clinical elements – medications, diagnoses, procedures, symptoms and findings – using SNOMED CT. These features can then be queried using powerful, user-definable SNOMED CT queries to present structured data in a form that can be easily consumed by existing BI platforms.

For example, when the narrative text below is typed into diagnosis and observation fields (respectively), Clinithink is able to provide a list of possible coding options for manual confirmation (as shown below).

The increasing volume and variety of data collected by healthcare enterprises is a challenge to traditional relational database management systems. This increase in data is due both to an increase in computerization of health records, and to an increase in the capture of data from other sources, such as medical instruments (e.g. biometric data from home monitoring equipment), imaging data, gene sequencing, administrative information, environmental data and medical knowledge. The proliferation of large volumes of both structured and unstructured data sets has led to the popularity of the term 'Big data' within the healthcare context. Big data refers to any collection of data sets that is so large and complex that it becomes difficult to process them using traditional data processing applications.

Accommodating and analyzing this expanding volume of diverse data (i.e. 'Big Data') requires distributed database technologies. A distributed database is a federation of loosely coupled data stores with separate processing units, which are controlled by a common distributed database management system. It may be stored in multiple computers located in the same physical location, or dispersed over a network of interconnected computers. Distributed databases may be categorized as either:

• Homogeneous – A distributed database with identical software and hardware running on all database instances.

• Heterogeneous – A distributed database supported by different hardware, operating system, database management systems and even data models.

In both cases, however, the database appears through a single interface as if it were a single database.

Distributed databases are used for Big Data analytics for a number of reasons, including:

• Transparency of querying over heterogeneous data stores

• Increase in the reliability, availability and protection of data due to data replication

• Local autonomy of data (e.g. each department or institution controls their own data)

A number of tools are available for the distributed storage and processing of big data, including Apache Hadoop. Apache Hadoop is an open-source software framework, which splits files into large blocks and distributes these blocks amongst the nodes in the cluster. To process the data, Hadoop sends code to the nodes that have the required data, and the nodes then process the data in parallel. Hadoop supports horizontal scaling – that is, as data grows additional servers can be added to distribute the load across them.

Many distributed database solutions use NoSQL (Not Only SQL) systems. NoSQL systems are increasingly being used for big data, as they provide a mechanism for storage and retrieval of data in a variety of structures, including relational, key-value, graph or documents. The Oxford University, in collaboration with Kaiser Permanente are using a NoSQL database (RDFox) to investigate how to perform complex queries efficiently across extremely large numbers of patient records. RDFox is a highly scalable and performant NoSQL database that is readily distributed across parallel processing units.

The Data Analytics with SNOMED CT guide reviews current approaches, tools and techniques for performing data analytics using SNOMED CT and to share developing practice in this area. It is anticipated that this report will benefit members, vendors and users of SNOMED CT by promoting a greater awareness of both what has been achieved, and what can be achieved by using SNOMED CT to enhance analytics services.

Provide Feedback

A major application for Natural Language Processing technologies is indexing collections of free text transcripts or documents such that topic specific searches may be run on them. The challenge is to return ranked matches which permit selection of texts with high sensitivity and high specificity (i.e. that relevant documents are rarely overlooked and that irrelevant documents are rarely returned).

Clinical searches may be performed over transcripts or documents that reside in an electronic library, within medical records, or the Internet. Examples of searches include:

• "Show me articles on this website concerned with inflammatory bowel disease"

• "Does this patient have transcripts in their record suggesting a heart rhythm disturbance?"

When querying patient records containing SNOMED CT-enabled data, a variety of interfaces may be adopted to support the user in authoring queries. In this section we first consider user interfaces for querying SNOMED CT, and then look at user interfaces for querying SNOMED CT enabled patient records.

When querying clinical data, it may be necessary to first define a subset of SNOMED CT concepts (e.g. disorders or procedures) that may then be compared against values in a patient record. A number of different options exist for creating these SNOMED CT subsets, including:

1. Selecting individual SNOMED CT concepts (i.e. extensional definition)

2. Authoring queries directly using a query language (i.e. intensional definition)

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|

The Cambio COSMIC® Electronic Patient Record system has been under continuous development since 1993. Cambio has applied innovations within healthcare informatics in areas such as information models, clinical terminology and formal languages for expressing clinical decision support rules. The COSMIC® EPR combines openEHR archetypes, SNOMED CT terminology and Guideline Definition Language rules in implementations which benefit patients, clinical staff and healthcare enterprise management. Using these technologies, their system is able to incorporate advanced analytics capabilities.

Cambio uses the Guideline Definition Language (GDL) to combine archetypes, terminologies and clinical decision support rules. GDL provides:

• Bindings between archetype elements and variables in the rules;

Kaiser Permanente (KP) has been involved in the development of SNOMED CT since its inception. Preceding this, KP collaborated with the College of American Pathologists in the 1990's on the immediate predecessor of SNOMED CT (SNOMED-RT). Some of the very earliest deployments of SNOMED CT have been within KP electronic patient record systems.

The terminology services deployed within the KP HealthConnect electronic health record illustrate the practical use of SNOMED CT as a key reference terminology within a multi-coding system environment. KP is also at the forefront of realizing new possibilities offered by SNOMED CT using its description logic capabilities.

Convergent Medical Terminology (CMT) is KP's Enterprise Terminology System. While the KP HealthConnect EHR system is built by Epic (see case study Epic), the CMT is proprietary to Kaiser Permanente. CMT hosts several components:

• Standard reference terminologies

The National Release Centre of Denmark (National eHealth Authority) produces a SNOMED CT drug extension for medications. The Danish SNOMED CT drug extension was primed by data extraction, cleansing and conversion of content from the Danish Medicine Agency Database (DKMDB), which is primarily meant for pricing and stock handling. The DKMDB was then complemented with SNOMED CT substances and their unique IDs. The Danish SNOMED CT drug extension includes information such as trade names, substances, dose forms, strengths and units of measure.

Building upon the Danish drug extension, the National eHealth Authority is working to introduce centralized decision support (CDS) services for both primary care and hospital prescribing systems.

The CDS server will respond to web service requests from the various electronic medication systems and return alerts and other prescribing information

Allergies Register

A group of allergy specialists, family practitioners and CDS experts are developing a standard set of information to be used in a patient drug allergy register. A SNOMED CT subset, from the Drug Allergy (disorder) sub hierarchy in the Findings hierarchy, is used to document allergies. .

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.

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.

Cerner Corporation's Millennium healthcare system manages terminologies, classifications and other code systems within a terminology service - the Cerner Millennium Terminology (CMT) package. CMT accommodates and integrates SNOMED CT International Release data and National extension content - such as concepts, relationships, descriptions, subsets, maps etc.

At the Cerner Millennium user interface, content can be captured at point of care as SNOMED CT codes. Modules used with SNOMED CT include: Problems and Diagnoses, Allergies, Procedures, Pharmacy Orders, Radiology Orders and Cellular Pathology Reports.

Either Cerner or third party clinical encoding software can process SNOMED CT Diagnoses and Procedures captured in Millennium and suggest ICD-10 and other classification codes to Clinical Coders for activity reporting and billing.

SNOMED CT is also used extensively behind the scenes to support more sophisticated analytic facilities within their Natural Language Processing (NLP) tools and reporting tools. These Cerner products and services exploit unique features and content of SNOMED CT to extend the power of these applications.

Data Warehousing

The Cerner product suite includes two data warehousing applications. These applications share much of their terminology-related technology, including supporting subsumption queries with the CMT Concept Explode/Transitive Closure facility, which utilizes the SNOMED 'is a' relationships.

The PowerInsight® Data Warehouse (PIDW) is an enterprise level data warehouse which updates on a nightly basis from the live electronic patient record. PIDW services standard operational reporting, mandatory reports (e.g. for National or State governments and regulatory bodies), and ad hoc queries e.g. individual lists of patients treated as requested by clinicians for audit.

The Health Facts® Reporting supports the pooling of anonymized data from different healthcare organizations. Health Facts data warehouse represents information of electronic records from millions of inpatient, emergency department, and outpatient visits from participating U.S. health care organizations. (Data are encrypted and secured to ensure patient confidentiality in compliance with HIPAA privacy regulations.) The reporting facilities enable the analysis of patient care and process trends within a facility and provide comparisons to other Health Facts contributors.

The Cerner data warehouse query tools include simple graphical user interfaces which directly create powerful reports using the SNOMED CT hierarchy content. The screenshot below shows a report of attendances with diagnoses which are a descendent of the SNOMED CT concept .

Other Applications

Cerner's Natural Language Processing (NLP) technology interprets the content of clinical notes through a complex understanding of grammar, syntax, synonymy and phraseology. SNOMED CT's semantic content and concept model enriches the analysis of the text in several ways including

• Concept recognition using synonyms – for example: |heart attack| is a synonym of |myocardial infarction|;

• The hierarchical relationships between concepts – for example: |pneumonia||is a||respiratory disease|;

• The identification of context, such as negation, certainty, subject and timing;

Computer Assisted Coding allows the extraction of appropriate SNOMED CT codes for automating coding and billing processes.

Chart Search/Semantic Search is a tool that enables clinicians at the point of care to search in real time through a patient's multiple charts, pathology reports and other documents, for topics such as 'heart disease' and 'diabetes'. The interface, as shown below has the look and feel of a World Wide Web search engine.

The searches can be filtered by date, document type etc. However the power of this approach is extended beyond conventional search engine indexing by using SNOMED CT. Cerner's tools index SNOMED CT findings (including diseases and symptoms) and procedures to make searches and queries over these domains faster. Cerner also hand curates exceptions and associations between related concepts. A Clinical Significance Score is assigned to each concept to allow documents to be sorted based on the probable relevance of the concepts in the document given their context of use.

As shown below for example, when given the search term 'heart disease', the 'is a' hierarchies of SNOMED CT enable recognition and return of documents which reference 'sinus bradycardia' and 'dilated cardiomyopathy'.

One major ambition of healthcare IT is to make effective summaries of a patient's clinical history available to healthcare providers (especially in emergency situations). Typically a patient's clinical data is scattered across a number of healthcare institutions using a variety of information models and coding systems. Even within a single institution patient data may be captured across many episodes of care, many devices, and often many software systems.

SNOMED CT can help to support the integration of this information by serving as a common reference terminology into which other code systems can be mapped. It can also be used to unlock clinical data that was captured by source systems in free text narrative, and to summarize large volumes of data by grouping codes together into more general categories. SNOMED CT can also be used to enable clinicians to filter large volumes of data to select those records that are relevant to the current care episode – for example identifying all previous records of a heart attack.

One significant example of this is the UK NHS Summary Care Record (SCR) service,1 which uses SNOMED CT to represent a number of types of clinical information including medical history, medications, adverse reactions and allergies. This service uses a summary extracted from detailed patient care records held in a variety of disparate systems. Where the source data is not stored natively in SNOMED CT, they are mapped into SNOMED CT prior to transmission. Over 40 million people in England (80% of the population) now have a summary care record. This service now contributes to the safe and efficient assessment and treatment of these people, and has greatly improved the accuracy and timeliness of medicines reconciliation.

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.

Classifications are primarily used for purposes in which terms must be grouped into categories, and double counting must be avoided. These purposes may include:

• Statistical reporting on major diagnoses, procedures or primary cause of morbidity

• Epidemiological reporting involving counting of disease categories

• Other administrative reporting based on specific WHO reporting requirements

In contrast, SNOMED CT is a clinical terminology, in which each concept identifier represents a distinct clinical meaning. By providing a more detailed level of granularity than classifications, SNOMED CT enables clinicians to use SNOMED CT to record healthcare information at the clinically appropriate level of detail. Unlike statistical classifications, SNOMED CT uses a polyhierarchy, in which each concept may be grouped under more than one supertype, reflecting possible alternate ways of categorizing each clinical meaning. SNOMED CT also provides defining relationships between concepts, which further enhances its ability to support flexible and powerful analytics capabilities.

It is generally recommended that clinical data is recorded using a clinical terminology, such as SNOMED CT, and then mapped for reporting purposes to one or more classifications, such as ICD. SNOMED International publishes a map from SNOMED CT to both ICD-9 and ICD-10. This supports epidemiological, statistical and administrative reporting needs of the member countries and WHO Collaborating Centers. The collaborative work between SNOMED International and the WHO on the alignment of ICD-11 with SNOMED CT is in progress and promises tighter integration of the distinct use cases in the future.

The following example illustrates the rows of the Extended Map reference set that supports the mapping from the SNOMED CT concept 15296000 |sterility| to an appropriate ICD-10 code. The set of map rules associated with each SNOMED CT concept are grouped together into 'map groups' and then ordered within each map group by a 'map priority'. The map rule provides a machine readable rule that indicates whether this map should be selected within its map group, and the map advice provides human readable advice. The correlation indicates the type of match between the source and the target (e.g. 'exact match' or 'narrow to broad') and the map category indicates the kind of map being represented.

Maps from SNOMED CT to classifications are generally represented in SNOMED CT's RF2 using a Complex or Extended map reference set. Mappings are then performed by matching each SNOMED CT code in a patient's record with the corresponding row of the map reference set, and using the classification code found in the 'mapTarget' field.

The UK Terminology Centre's Data Migration Workbench demonstrates the use of maps from SNOMED CT to ICD-10 International Edition (using the UK maps) and OPCS Classification of Interventions and Procedures (OPCS-4). The National Library of Medicine (NLM) has also developed a demonstration tool, which demonstrated the key principles of implementing map rules and advice. This tool, called I-MAGIC

The uses the SNOMED CT to ICD-10 map in a real-time, interactive manner to generate ICD-10 codes. It simulates a problem list interface in which the user enters problems with SNOMED CT terms, which are then used to derive ICD-10 codes using the map. A number of vendor products, such as Cerner Millenium, also use maps from SNOMED CT to ICD-10 to enable statistical analysis.

Migration to native SNOMED CT electronic patient records is in progress in the United Kingdom National Health Service (NHS). In order to promote interoperability, usability and activity reporting, the NHS introduced a national standard set of imaging codes in 2005 – the National Clinical Imaging Procedure code set (NCIP).

While SNOMED CT was the prime candidate for populating the NCIP, many Radiology Information Systems (RIS) and Picture Archiving and Communication (PAC) systems at the time could not accommodate SNOMED CT 18-digit concept identifiers or (up to) 255 character descriptions without disruptive and costly software changes. There was also no consistent way to represent laterality of procedures, and some legacy systems required the creation of separate orderable items for each laterality – for example 'Plain X-ray left wrist', 'Plain X-ray right wrist', and 'Plan X-ray both wrists'. For these reasons, the NCIP code set was developed based on SNOMED CT, but with the addition of unique identifiers compatible with legacy system's character limitations (6 alphabetic characters), up to 40 character human readable descriptions, and additional laterality metadata. For example, 60027007 | Radiography of wrist| is represented within NCIP as:

NCIP short codes are 'meaningful', in that the modality of the procedure is defined by the first character of the code, and the finding site and laterality are both explicitly represented in the code.

Each hospital submits mandatory data extracts using NCIP from both legacy and SNOMED CT capable RIS. In addition to details of the imaging procedures, information about the referral source, patient type, demographics and times of each imaging related event are also collected centrally. The data from all sites is then combined and multiple reports are extracted. Hospitals can view their activity data via the iView web based reporting tool and compare their activity with other centers.

Analytics on this central platform are wholly SNOMED CT based. SNOMED CT hierarchies support sophisticated reports – for example, the monthly waiting times for Magnetic Resonance Imaging excluding Cardiac MRI and MRI guided procedures is specified as:

• Includes hierarchy <<

• Excludes hierarchy <<

• Excludes hierarchy <<

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.

SNOMED CT is a clinical terminology containing concepts, with unique meanings and formal logic-based definitions, organized into hierarchies. The clinical content of SNOMED CT includes diagnoses and other clinical findings, clinical observations, drug products, organisms, specimen types, body structures, and surgical and non-surgical procedures.

SNOMED CT enables clinical information to be consistently represented at an appropriate level of detail within electronic health records. The relationships within SNOMED CT then facilitate meaning-based retrieval of this information at the preferred level of detail for the given query. This provides significant flexibility and facilitates the integration of data from divergent models of use, such as different user interfaces or databases, into convergent models of meaning, such as for the representation of data for reporting or statistical analysis purposes. Clinical systems can thereby query and analyze electronic health record data recorded in different settings, at varying levels of granularity and across multiple axes. This enables SNOMED CT to support a variety of clinical processes, which may require either detailed or high-level information - from investigation, to diagnosis and clinical research.

SNOMED CT content is represented using three main types of component:

The SNOMED CT analytics techniques described in the previous chapter only become useful when performing a specific analytics task intended to meet a business need. In this chapter, we consider a range of analytics tasks, which are either enabled or enhanced by using these SNOMED CT techniques.

The analytics tasks which can benefit from the use of SNOMED CT techniques can be considered in three broad categories:

• Point of care analytics, which benefits individual patients and clinicians. This includes historical summaries, decision support and reporting.

• Population-based analytics, which benefits populations. This includes trend analysis, public health surveillance, pharmacovigilance, care delivery audits and healthcare service planning.

With an ever increasing volume of medical literature and clinical reports, it is becoming increasingly important to be able to meaningfully search this information. A major application for Natural Language Processing technologies is to index collections of free text transcripts or documents such that topic specific searches may be run on them. The challenge is to move beyond the limitations of plain keyword searching strategies towards more advanced search techniques, which return ranked matches with high sensitivity and specificity. Clinical searches may be performed over documents within an electronic library, within medical records, or on the internet. Examples of searches include:

• "Show me articles on this website concerned with inflammatory bowel disease"

• "Does this patient have transcripts in their record suggesting a heart rhythm disturbance?"

Epic's electronic patient record systems use SNOMED CT as a reference terminology through the following mechanisms:

• Mappings between a subset of Epic's standard data elements and SNOMED CT concepts;

• Mappings between diagnoses imported from other code systems (e.g. those used in Intelligent Medical Object's and Health Language's products) and SNOMED CT concepts;

• Mappings from additional data elements to SNOMED CT concepts that can be created by clients using an External Concept Mapping activity.

These mechanisms provide linking behind the scenes, so when clinicians add a diagnosis to the problem list by selecting a familiar term, for example, they automatically select the corresponding SNOMED CT concept. This SNOMED CT encoding creates powerful possibilities within Epic's decision support and reporting facilities.

The Epic system calls its decision support alerts 'Best Practice Advisories'. These customized alerts are programmed to fire according to predetermined triggers, such as specific chief complaints, vital signs, diagnoses or medications, either individually or in combination using inclusionary or exclusionary logic. Best Practice Advisories can thus be used to notify clinicians to tend to important tasks, such as reviewing a patient's allergies, writing orders, and completing charting. They can also present order sets and links to third party information sources refined using the clinical context of the patient record being reviewed.

Epic customers can use SNOMED CT's hierarchical structure to group related records, making the setup for clinical decision support much simpler than would be possible if users had to select records or clinical concepts individually. For example, an administrator creating Best Practice Advisories for diabetic patients could use 73211009 |diabetes mellitus| within the SNOMED CT hierarchy as one of the criteria instead of identifying every subtype of diabetes individually.

Within Epic's integrated analytics and reporting suite (i.e. Cogito) customers have achieved benefits by using SNOMED CT's clinical finding hierarchy to aggregate local diagnosis concepts.

The capability has for example been used by oncologists working with cancer-related ICD codes which are unsuited to grouping diagnoses by stage. Using the mapped SNOMED CT codes they are able to facilitate the reporting of staging data by utilizing the SNOMED CT hierarchy.

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.

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.

This section includes brief reviews of a variety of commercial tools which support analytics over SNOMED CT enabled data. These reviews focus predominantly on those tooling features that are relevant to supporting analytics services.

We welcome additional input to this section and anticipate updates to this report as new information becomes available.

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

• Incomplete modelling

These challenges are described in more detail in this section.

In some cases, the strict logical meaning of a term may differ somewhat from the local vernacular (or common) use of that term. For example, the assertions below in SNOMED CT are logically sound but may be counterintuitive to clinicians:

• |insect bite of nose| is a subtype of |head injury|

• |laceration of radial artery| is a subtype of |cardiovascular disease|.

Examples, such as these, exist in which the formal logical definitions of these concepts may lead to hierarchies that differ from what may be expected by some clinicians.

SNOMED CT definitions include the set of necessary and sufficient conditions that define the given concept. However, SNOMED CT does not currently distinguish the minimum sets which are sufficient to define these concepts. For example, the defining relationships of 154283005 |pulmonary tuberculosis| are:

While the associated morphology of 'granulomatous inflammation' is necessarily present, the following set of defining relationships are sufficient to infer 154283005 |pulmonary tuberculosis|:

As a consequence if the following expression was recorded in a health record:

This expression would not be returned by the following query:

However, the query:

would correctly return both the concept "154283005 |pulmonary tuberculosis|" and the above expression as required. In this way, the design of appropriate queries can help to mitigate this issue.

The SNOMED CT Concept Model continues to evolve to allow more concepts to be fully defined. For example, the 'Observable Entity' and 'Substance' hierarchies each have new concept models being developed, which will allow these concepts to be more fully defined in future releases of SNOMED CT. When the concept models for these hierarchies are incorporated, SNOMED CT's expressive power and analytics capabilities will be further expanded.

In those hierarchies for which the concept model has been established for some time (e.g. Clinical finding), ongoing expansion to SNOMED CT's formal logical definitions continues. However, there still remains some concepts which do not yet have all possible defining relationships included. This issue will be mitigated over time as more of SNOMED CT's concepts continue to be modelled.