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. 318353009 | propranolol hydrochloride 40mg tablet| ) and the conditions (e.g. 370219009 | moderate asthma| ) 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 195967001 | asthma| to FDB's 'asthma', to the more subtle, such as linking 447413000 | drainage of amniotic fluid using ultrasound guidance| to FDB's 'pregnancy'.

FDB reviews the relevant SNOMED CT domains (i.e. | Clinical finding|, | Procedure| and | Situation with explicit context| ) for concepts applicable to drug-condition checking. The FDB linking tool uses the SNOMED CT | is a| 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.

As discussed in this guide, SNOMED CT is increasingly being used in clinical decision support (CDS) systems to support healthcare providers in making well informed clinical decisions.

This appendix presents two sets of case studies, which demonstrate the use (or planned use) of SNOMED CT in clinical decision support systems.

• Organizational Case Studies describes a range of organizations that use SNOMED CT for clinical decision support;

• Vendor Case Studies describes a number of commercial products that use SNOMED CT to enable clinical decision support.

Overview

The purpose of the communications mechanism is to handle CDS communications into and out of the system. Examples of user inputs include entry of clinical data, and the selection of a proposed drug, order set, or treatment regime. Examples of outputs include CDS interventions such as alerts, guidelines, diagnostic refinements, and smart forms. These outputs are typically delivered to the u ser interface. SNOMED CT has limited involvement in the communications mechanism of CDS as most of the codes and features will be used by the knowledge base and inference engine. That being said, it is possible that SNOMED CT terms are used at the user interface level as part of the data entry process. For more information on using SNOMED CT to support data entry, please refer to the SNOMED CT Search and Data Entry Guide. SNOMED CT can also be used in the CDSS outputs. For example, using the relevant terms in the alert messages, populating smart forms with SNOMED CT codes, or linking terms in CDS guidelines to other appropriate clinical knowledge sources.

The figure below depicts the key interactions of the CDS communications mechanism.

Once the inference engine has determined that an intervention is appropriate, the communications mechanism takes over and handles its delivery. Conversely, user inputs are also delivered into the CDSS by the communications mechanism. Note that guidelines or knowledge resources may reference externally hosted content, which may be accessed by the user via a link. An example of this would be a PubMed citation for biomedical literature.

Note that the diagram also shows how the internal CDSS communications (associated with the external inputs and outputs) are related to the components of the CDS rule. The communication 'inputs' feed into the event (from "ON event") and the condition (from "IF condition") components of the rules, while the 'outputs' are the result of the action (from "THEN action") that is performed if the event occurs and condition is true.

The following screenshot was generated from an EHR with CDS capabilities. This illustrates what a typical CDS intervention may look like.

Note that the contents of this alert have been magnified for the purpose of this illustration. Characteristics of this alert include:

• It appears at the top of the screen using fonts and colors that help to distinguish it from other content. (Alerts, by design, are intended to be noticed.)

• It includes mechanisms to process the intervention as appropriate (e.g. to acknowledge, accept or discard the alert). In this case, the alert my be closed (by clicking the X) or the suggestion to order a lab test may be accepted (by clicking on "order a lab").

• It provides a link to applicable reference information (

Alert fatigue is an unwanted side effect of CDS. Alert fatigue occurs when clinicians become overwhelmed by or desensitized to CDS alerts because of their sheer number, intrusive nature, or non-relevance to a clinical situation. The danger of alert fatigue is that the clinician will miss something important as a result. Strategies are required to minimize alert fatigue. Some of the interesting ideas proposed by thought leaders in CDS include:

• Increasing the specificity of alerts;

• Allowing users to customize CDS alerts by types of interventions

• Using a human factors approach to designing alerts

SNOMED CT is able to help with the first two items above. Firstly, it can be used to increase the specificity of the CDS conditions that trigger the alerts. And secondly, it can be used to distinguish between different types of interventions to enable customization to occur. Please refer to in the section Context in CDS Rules for more information on minimizing alert fatigue.

An example of a standard which relates to CDS communications is provided below.

CDS Hooks is a relatively new CDS initiative which aims to automate the launching of applications that assist with decision support. CDS Hooks are designed around the premise of a clinician initiating a triggering activity within the EHR. When the triggering activity occurs, the EHR automatically sends a notification in real time to a decision support service (DSS). This notification is considered the "hook" to the decision support logic. An example of a triggering activity would be a clinician writing a prescription. Some pre-defined hooks have already been developed and new hooks can be defined and added to the catalogue as required. Once the DSS is aware of the specific event, it may generate a response in the form of a "card" to be displayed in the UI of the EHR. An example of an "information" card might be one that contains pricing data about a proposed drug. The DSS could then propose a more cost effective "suggestion" card as an alternative. The other type of card the DSS may offer is an "app link" card which, as the names suggests, provides a link to an external application that can assist with further decision support. This architecture eliminates the need for the user to be aware of specific decision support applications that may be useful. The final outcome or choice, initiated by the app link card process, can then be automatically transferred to the appropriate field(s) in the EHR. A clinician has the option to accept or decline any suggestions present in the card. References to external knowledge resources may also be present in CDS Hooks cards.

The screen shot below captures part of a CDS hook. Note that the condition the clinician is treating is represented using the SNOMED CT code for 396275006 | Osteoarthritis|.

For more information about CDS Hooks, please refer to .

This section provides an overview of the logical architecture of an electronic health record (EHR) which uses CDS.

In particular, it focuses on the logical architecture of knowledge-based CDSSs, which use pre-loaded CDS artifacts (such as rules and guidelines) that closely match a human's natural reasoning process. Non-knowledge-based CDSSs, which use artificial intelligence (AI) or machine learning to acquire knowledge over time, are outside the scope of this guide.

The logical architecture of knowledge-based CDSSs are explored in the following subsections.

EHR System Architecture

To understand how clinical decision support (CDS) works, it is important to understand how CDS fits within the logical architecture of an EHR system. This section describes the major architectural components of an EHR system, and the interactions between these components.

Major Components

Table: Descriptions of the major architectural components of an EHR system

The major architectural components of an EHR system that incorporates CDS interact with each other in a variety of ways to support the overall functioning of the EHR. The diagram below uses orange arrows to illustrate the primary interactions between these EHR components.

As shown above, the UI communicates with the record services to facilitate the storage and subsequent retrieval of health record data. The UI also provides inputs to the CDSS and displays alerts and guidelines on its behalf. The CDSS uses the inputs from the UI and data from the record and terminology services to processes decision support rules. The CDSS uses the inputs from the record and terminology services to determine whether or not the CDS conditions have been met, and if so then CDS interventions, such as alerts or knowledge resources, are delivered back to the UI. The internal components and processes of the CDSS will be described in more detail in the next section.

This section describes the major architectural components of a CDSS and explores how they work together with the components of an EHR, as described in .

Table: Descriptions of the major architectural components of a CDSS

The diagram below illustrates how the components of the CDSS (shown in the blue box) work together with the components of the EHR system (shown in the red box).

Internal CDSS interfaces are represented by the green directional arrows, while external CDSS interfaces are represented by the orange arrows. Note that the inference engine interfaces directly with record and terminology services while communications, which is focused on the delivery of CDSS inputs and outputs, interfaces directly with the user interface.

An important consideration in the development of a Clinical Decision Support System (CDSS) is the substrate over which the knowledge artifacts are authored and executed. When using SNOMED CT in a CDSS, the substrate is the SNOMED CT content over which the CDS rules are authored or executed. Because medical knowledge is constantly changing, it is important that the substrate over which CDS is applied is kept current. To support this requirement, SNOMED CT releases regular new versions of the terminology, and retains a history of changes using its strong versioning mechanism. With this in mind, both the SNOMED CT edition and the specific version of that edition (released on a given date) need to be considered in determining the SNOMED CT substrate. For more information on the topic of versioning, please refer to section in the guide SNOMED CT Data Analytics Guide.

Knowledge Artifact Substrate

When publishing CDS knowledge artifacts, such as rules or guidelines, it is important to clearly indicate the substrate over which the artifacts were authored. The substrate used to author a CDS artifact needs to be considered when determining the appropriate substrate to use in the execution of that artifact.

For example a CDS rule, using the SNOMED CT US edition, dated 20160901 (September 1st 2016), may refer to the concept 5281000124103 | Persistent asthma|. If this rule was executed against the SNOMED CT International Edition (20170131), then this extension concept would not be found, and the rule could not be executed.

Similarly, a CDS rule using the International edition (20170131) may refer to the concept 721039003 | Dual energy computed tomography|. If the rule was executed against the 20160731 International edition (or an older version), then this concept (created in the 20170131 version) would not be found, and the rule could not be executed. This would also be true if the same CDS rule was executed against the US edition (20160901), because this edition is dependent on the 20160731 International edition.

Therefore, CDS knowledge artifacts referencing SNOMED CT concepts must be executed (by the inference engine) using a SNOMED CT substrate that includes the same modules, or a superset of the modules included in the SNOMED CT substrate used to author the artifact. In addition, the SNOMED CT substrate used to execute the CDS artifacts must use the same version, or a more recent version of these SNOMED CT modules, to ensure that all the referenced concepts are present. Please note that if a newer version of the substrate is used to execute the rules, then it is possible that a concept or relationship used at the time of artifact authoring may have become inactive. Edition and version dependencies such as these should be checked when adopting new CDS artifacts or updating a CDS system to use a newer version of SNOMED CT.

Another consideration when selecting the SNOMED CT substrate on which to execute CDS artifacts, is the substrate used to record data in the Electronic Health Record (EHR).

For example, if a CDS rule is triggered when the diagnosis recorded in the EHR is a descendant of 195967001 | Asthma|, that is: IF < 195967001 | Asthma| THEN ... and this rule is executed over the SNOMED CT International edition, dated 20170131 (January 31st 2017), then EHR records which capture a diagnosis of 5281000124103 | Persistent asthma| from the SNOMED CT US edition (20160901) will be unsuccessful in triggering the CDS rule.

Similarly, if a CDS rule is triggered when the diagnosis recorded in the EHR is a descendant of 19829001 | Pulmonary disease|, that is: IF < 19829001 | Pulmonary disease| THEN ... and this rule is executed over the US edition (20160901), then EHR records which capture a diagnosis of 12240951000119107 | Squamous cell carcinoma of left lung| will be unsuccessful in triggering the CDS rule. This is because the US edition (20160901) is dependent on the International edition (20160731), and the concept referenced above was added to the International edition (20170131).

Therefore, CDS knowledge artifacts must be executed (by the inference engine) using a SNOMED CT substrate that includes the same modules, or a superset of the modules used by the EHR system to record patient data. In addition, the SNOMED CT substrate used to execute the CDS knowledge artifacts must use the same or a more recent version of these SNOMED CT modules, to ensure that all the referenced concepts are present. Please note that if a newer version of the substrate is used to execute the rules, then it is possible that a concept recorded in the EHR may have become inactive. Edition and version dependencies such as these should be checked when implementing new CDS rules over existing EHR data or updating a CDS system to use a newer version of SNOMED CT.

Overview

The Pharmacy Health Information Technology Collaborative (PHIT Collaborative) is a body of pharmaceutical organizations which operates in the United States and was formed in 2010. As the name suggests, they focus on the pharmacists providing patient care services and assess how information technology can be used to support their processes and workflows. Health information technology standards and clinical terminology are used to promote interoperability and to support their strategy of collecting, documenting, and preparing information for sharing with other service providers. Much of the work the PHIT Collaborative does is guided by the Centers for Medicare & Medicaid Services (CMS) medication therapy management regulations and Meaningful Use (MU) reporting requirements.

Use of SNOMED CT

The PHIT collaborative has been working towards the standardization of clinical pharmacy documentation which includes the use of SNOMED CT to record events such as a 404684003 | Clinical finding|, 71388002 | Procedure|, or 243796009 | Situation with explicit context|. This has resulted in a number of SNOMED CT value sets being published in the National Library of Medicine (NLM) Value Set Authority Center (VSAC), such as the one shown in the figure below.

A major benefit of using SNOMED CT in clinical pharmacy documentation is that SNOMED CT supports the calculation of (eCQMs). This ensures that pharmacists are included in the overall measurement of quality in the US health care system and more recently, outcomes-based payment models.

In addition to improved interoperability and calculation of eCQMs, the standardization of clinical pharmacy documentation can help to enable decision support and the Pharmacy HIT Collaborative is looking at some potential scenarios. One of the central components of pharmacy documentation includes identification of drug therapy problems. Once a medication problem has been identified, a pharmacist can intervene to optimize a patient medication regimen. But in some US jurisdictions, the direction to adjust a medication must come from the prescribing physician. Clinical decision support could be a huge benefit in these cases by acting on the recommendations of a pharmacist. More specifically, CDS could be used to help identify drug therapy issues, to propose actions, and to notify prescribers.

Using clinical decision support in the documentation of medication adverse reactions, allergies, intolerances and interactions could also benefit pharmacists and their patients. For example, SNOMED CT concepts subsumed by 62014003 | Adverse reaction caused by drug| and 272141005 | Severities| could be used to document adverse reactions . When prescribers are managing medication regimens, improved clinical decision support alerts could provide a mechanism to outline the risk of prescribing a medication based on past experience.

Medication outcomes could also be documented using SNOMED CT. For example, SNOMED CT could be used to document the outcomes of a patient who is involved in clinical trials for a new medication. Lack of an adverse reaction may have multiple explanations, including that the patient may not be adherent to the medication due to cost or the inconvenience of frequent administrations. Documenting the reason why a therapy failed could provide useful information for future prescribing events.

This section describes a number of commercial products that use SNOMED CT to support their clinical decision support systems. The vendors that have contributed to this review include:

• Duodecim

• First Databank

What is Clinical Decision Support?

Clinical Decision Support (CDS) is a service that enables healthcare providers to make well-informed decisions by supplying guidance, knowledge, and patient-specific information at relevant points in the patient journey, such as diagnosis, treatment, and follow-up. CDS uses a range of mechanisms to assist users in this process. Examples of these mechanisms include automated alerts or reminders, clinical guidelines, contextually relevant reference information, conditional order sets, diagnostic support, and patient-focused reports, forms, or templates. The beneficiaries of the information derived from CDS may include patients, clinicians, and others involved in the delivery of health care.

It is important to distinguish the general practice of clinical decision support from the application of tools designed to enhance decision support practices. One is performed by humans who make decisions based on knowledge they possess and information they consume. The other is computed by systems and engines using rules and predefined conditions. Although both are important, the technical components of CDS are designed to assist rather than replace the subtle judgment and guidance provided by the clinician.

Applications and tools that provide clinical decision support are known as as Clinical Decision Support Systems (CDSS). A clinical decision support system is defined as a computer system or software application designed to assist clinicians, caregivers, or patients in healthcare and/or treatment decisions.

Notes

• Typically a clinical decision support system responds to triggers, such as specific signs or symptoms, diagnoses, laboratory test results, medication selections, or complex combinations of such triggers. The system then provides information or recommendations relevant to the specific patient.

It has been suggested that the origins of clinical decision support (CDS) can be traced back to the 1950s and 1960s. In an early example from 1961, Dr. Homer Warner, a cardiologist from the University of Utah developed a mathematical model which was used to diagnose heart disease. Since then, there have been countless developments and advancements in the area of decision support. Many theories have been proposed as to how CDS should be approached and applied in clinical practice.

When implemented properly, CDS has the potential to enhance patient care, reduce errors and duplication of effort, and introduce efficiencies to the clinical workflow. Conversely, CDS tools can also be distracting and disruptive, even producing unwanted consequences. It is therefore important to consider the lessons learned from previous implementations of CDS and conduct thorough requirements analysis prior to designing or procuring a CDSS. One of the best practice frameworks that has been developed to guide those considering a CDS implementation is the "CDS Five Rights". "The Five Rights" suggests that to realize the full potential of CDS, solutions should:

• Supply the right information (evidence-based guidance, address the clinical need)

• To the right people (entire care team, including the patient)

• Using the right channels (e.g., EHR, mobile devices, patient portals)

A typical application of CDS is shown in the diagram below:

The clinical setting in which this hypothetical tool has been applied is the prescribing of a medication. In this example, the patient has previously had an 91936005 | Allergy to penicillin| recorded. When prescribing a new drug, such as 27658006 | Amoxicillin|, an alert is displayed to remind the clinician of the previously diagnosed allergy. The application may also provide a mechanism to search for alternative medications. Note that the mechanics of this workflow uses a predefined rule which specifies a condition to be evaluated and an action to be taken if the condition evaluates to true.

This section addresses the functional scope of clinical decision support. CDS may be represented in a variety of formats or tools which depend on the clinical situation or environment. These tools are often referred to as CDS formats, types, or interventions and can be deployed to a wide variety of systems and platforms, such as mobile devices.

Within these functional areas, CDS can be further subdivided into tools which are prompted by the tasks a clinician performs such as patient charting or diagnosis, and functions that are triggered by external events such as the expiration of a period of time. Some of the more common CDS functions are described briefly in the table below. Use of these functions may be appropriate in a variety of clinical domains or use cases, some of which are discussed in the section.

The focus of this section is the clinical application of CDS tools or how the described earlier can be used in practice. Stakeholders from various clinical domains interact with clinical systems, such as EHRs with CDSS and CPOE (computerized physician order entry). The table below lists some of the clinical areas in which SNOMED CT enabled CDSSs can assist clinicians in making well informed decisions.

This section contains a brief summary of key SNOMED CT features and explains how they may be useful in CDSSs.

SNOMED CT concepts are used to represent clinical meanings. Every concept in SNOMED CT is uniquely identified by a distinct SNOMED CT Concept Identifier. For example, 195967001 is the concept identifier for the concept 195967001 | Asthma| .

SNOMED CT concepts play an important role in CDS by enabling actions to be triggered based on the meaning of data recorded in the patient records.

SNOMED CT descriptions provide the human-readable terms associated with SNOMED CT concepts. A concept may have one or more descriptions, which act as synonyms for the same clinical meaning. This is also how SNOMED CT supports different dialects and languages.

SNOMED CT descriptions allow common CDS rules to be consistently applied across patient records recorded using different synonyms, dialects and languages.

SNOMED CT relationships link concepts together to formally define the meaning of each concept. For example, one type of relationship is the 116680003 | is a| relationship which relates a concept to a parent or supertype. These 116680003 | is a| relationships define the subtype hierarchy of SNOMED CT concepts.

For example, the concepts 53084003 | Bacterial pneumonia| and 75570004 | Viral pneumonia| both have an 116680003 | is a| relationship to 233604007 |Pneumonia| which has an 116680003 | is a| relationship to the more general concept 128601007 |Infectious disease of lung|. Subtype relationships can be used by CDS rules to refer to codes in an EHR that are any specific type of a relevant clinical concept.

Additional attribute relationships help to define the meaning of a concept. For example, the concept 75570004 | Viral pneumonia| has a 246075003 | Causative agent| relationship to the concept 49872002 | Virus| and a 363698007 | Finding site| relationship to the concept 113255004 |Structure of parenchyma of lung|.

Attribute relationships can be used by CDS rules to refer to codes recorded in an EHR that have a specific meaningful relationship with a concept of interest.

The SNOMED CT concept model is a set of rules that govern the ways in which SNOMED CT concepts are permitted to be modeled using relationships to other concepts. It defines the types of relationships that may be used on each type of concepts, and the permitted values for each relationship type. The represents the rules in the SNOMED CT concept model in a form that can be read by a computer and applied to test that concept definitions and expressions comply with these rules.

The SNOMED CT concept model plays an important role in CDS by providing the rules by which the clinical meaning of SNOMED CT encoded health records can be queried. The MRCM makes it possible to process these rules in a machine-processable way.

SNOMED CT provides a mechanism which enables clinical phrases to be represented by a computable expression, when a single concept does not capture the necessary level of detail. For example, the following expression represents a right hip:

SNOMED CT expressions enable additional clinical meanings to be captured in a health record, without requiring the terminology to include countless combinations and permutations of precoordinated concepts.

SNOMED CT expressions facilitate CDS over an expanded set of clinical meanings that extends beyond individual concepts. For more information about expressions, please refer to the .

SNOMED CT reference sets are a flexible and standardized approach used to support a variety of requirements for the customization and enhancement of SNOMED CT. These include the representation of subsets, language preferences for use of particular terms, mapping from or to other code systems, and ordered lists.

Reference sets may be used in the following aspects of CDS:

• Representing subsets of SNOMED CT concepts that may trigger a CDS action

• Representing non-standard aggregations of concepts for specific CDS use cases

• Defining language or dialect specific sets of descriptions over which term searches can be performed

For more information about reference sets, please refer to the .

Description Logic (DL) is a family of formal knowledge representation languages and used as the formal foundation of meaning in SNOMED CT. The way that concepts have been modeled in SNOMED CT permits them to be represented using Description Logic. DL helps computers to make useful inferences about concepts, and to classify SNOMED CT using a DL reasoner. Description Logic also helps by testing expressions for subsumption and equivalence.

The logical inferences supported by DL can be useful when executing CDS rules. For example, when a CDS rule requires an action to be performed when the patient has any type of 195967001 | Asthma| , a DL reasoner may be used to determine that 281239006 |Acute asthma| and 427603009 | Intermittent asthma| are both types of 195967001 | Asthma| and should therefore both trigger the action to be performed.

The following table contains the definition of abbreviations used in this document. Please refer to the for additional definitions.

The knowledge base can be thought of as the brains of a clinical decision support system. Clinical knowledge is what fuels the knowledge base. This knowledge is documented by the clinical experts in their respective domains. The knowledge is then loaded into the KB as knowledge artifacts and stored in a machine processable format. These artifacts are then made available to the to execute the decision support logic. Knowledge artifacts may be updated when new clinical knowledge becomes available. In some CDSSs this is done using a specialized knowledge artifact management interface, which may support tasks such as rule creation, customization, and updating. In other cases, clinical knowledge artifacts are used from third party providers, who specialize in supporting CDSSs.

Types of CDS knowledge artifacts include:

• Decision support rules

EBMeDS

The Evidence-Based Medicine electronic Decision Support system (EBMeDS) was developed by Duodecim. It is a platform-independent service, which can be integrated with any EHR that uses structured patient data. EBMeDS contains over 40,000 decision support rules which can be used to generate reminders, therapeutic suggestions, order sets and diagnosis-specific links to guideline sets and other online resources. EBMeDS can also be used to automatically populate calculators and forms with patient-specific data, and to generate summary views and dashboards. In addition to real-time use, the EBMeDS decision support rules can also be run as batch scripts on patient populations to generate reports that measure quality and analyze care-gaps. The rules of EBMeDS are based on the data in the EBMG collection, with several 3rd party resources also used for evidence collection.

Using SNOMED CT

EBMeDS receives encoded patient data from EHRs. The coded data pertains to several _ data groups _ including diagnoses, medications, vaccinations, investigation results, surgical procedures, and risk factors (such as smoking). Although multiple coding systems are supported, only SNOMED CT and the Read code system are accepted for all data groups. Within EBMeDS, all codes are mapped to internal aliases. For example, for the concept _ serum or plasma creatinine _ includes codes from 10 different coding systems. Duodecim is expecting to derive additional benefits from using SNOMED CT when more EHRs are able to provide SNOMED CT encoded records as outputs.

Deployments

At present, EBMeDS is used mainly in Finland. Duodecim is planning to offer a cloud-based centralized EBMeDS service in the near future, but currently the application is integrated into the local EHR environments. Belgium has a national license for EBMeDS as part of the EBMPracticeNet implementation in Belgium. Several pilots and scientific studies are being performed in Italy, Denmark, Estonia, the United States and the UK.

Clinical decision support rules play a key role in the overall delivery of CDS. CDS rules typically follow a common pattern, which has been modeled in several healthcare standards formalisms. The Event-Condition-Action model, as used in the HL7 community, is described below.

Event

A CDS event is the clinical situation in which a decision support rule will be applied. First something must happen before the rule can be utilized. Examples of CDS events include:

Condition

A CDS condition defines the question(s) that must be answered to determine the outcome of the rule. Examples of conditions include:

Action

The CDS action describes what should be done if the condition evaluates to true. Examples of actions include:

Event-Condition-Action Model

An informal representation or rule template which captures the Event-Condition-Action pattern is shown below. This pattern can be read as "ON event IF condition THEN action".

Rules may reference both EHR data and reference data such as terminology to determine whether or not a specific condition is true. This topic will be explored in more detail in section .

Context has been defined as the circumstances that form the setting for an event, statement, or idea, and in terms of which it can be fully understood. Contexts that modify the meaning of a diagnosis or procedure may include family history, past history, suspected diagnoses, planned procedures and procedures not done. It is important to understand the context of each statement in a health record, to determine whether or not it is appropriate to for a CDS rule to be applied.

Context can be expressed in a health record in a number of ways. Firstly, a precoordinated expression can be used in which the context is captured in the meaning of the concept. For example, 160303001 | Family history: Diabetes mellitus|. Alternatively, a postcoordinated expression can be used. This is where the meaning is expressed by combining codes in a structured way using . For example:

A third way to express context is to use a context-specific section or field, such as a "Family history section", which captures the context in the meaning of the section or field name. Lastly, it is also possible to use two separate fields - one which captures the finding | Diabetes mellitus|, and the other which captures the context | Family history of disorder|.

Table: Techniques for recording context in an EHR

Considering context that is captured in either the terminology or the information structure is important when executing CDS rules.

• Logic based purely on the presence or absence of codes, without considering the context implied by the information structure, may lead to CDS alerts being triggered unnecessarily (i.e. false positives).

• Conversely, logic based purely on the presence or absence of codes, without considering context implied by the information structure, may lead to CDS alerts not being triggered when required (ie. false negatives).

In the following example, a CDS rule is triggered inappropriately (i.e. false positive):

• A CDS rule is designed to display clinical practice guidelines for stage 1 chronic kidney disease when the code 431855005 | Chronic kidney disease stage 1| is found in the EHR. A retrospective analysis of a false positive trigger reveals that the code was recorded in the past history section of the health record. As this record indicates that the | Chronic kidney disease stage 1| was part of the patient's | Past medical history|, the display of stage 1 chronic kidney disease guidelines was inappropriate.

In the following example, a CDS rule is not triggered when required (i.e. false negative):

• A CDS rule is designed to display patient-focused, preventative educational material when the code 160303001 | Family history: Diabetes mellitus| is found in the EHR. This rule is implemented in an EHR system, which uses a family history section to record the family history of disorders. Even though the SNOMED CT concept 73211009 | Diabetes mellitus| is recorded in the patient's family history, the CDS rule is not triggered as required.

When neither the SNOMED CT concept nor the surrounding health record explicitly states the context, a default context applies.

Table: Default context values alongside their corresponding attributes

For clinical findings, it is assumed that the finding is known to be present (as opposed to known to be absent), we assume that the finding is about the patient ( as opposed to someone else), and we assume that the finding occurred at either the present time or a time specified in the record structure ( as opposed to a general time in the past).

The following diagram illustrates how additional context can be captured during the data entry process. The diagnosis (disorder) of 254837009 |Malignant neoplasm of breast| is selected using the pick-list in the top left corner of the screen and then the context values are selected using the other radio button and pick-list. These context values for relation to subject and finding context must be considered when the conditions in this CDS rule are evaluated.

It is important to always consider context when defining (and executing) the conditions in a CDS rule. If the default context applies to the condition, then it does not need to be explicitly stated in the CDS rule. However, care should be taken when testing the CDS condition against health records, to ensure that the recorded values share the same context as is required by the CDS rule. If a non-default context is required in a CDS rule, then the rule must explicitly state the context that is required. This context must also be appropriately checked when testing the CDS condition against health records.

The following diagram illustrates a CDS rule, which explicitly states the context of a 254837009 |Malignant neoplasm of breast| diagnosis that must be matched in order for the action to be triggered. In this example, the CDS condition requires that for patients over the age of 30 258707000 | years|, a diagnosis of 254837009 |Malignant neoplasm of breast| must be present, in a female family member of the subject, with genetic ties.

The contextual selections in the data entry screen above would satisfy the conditions in this rule because the user has specified that the diagnosis of female breast cancer occurred in the mother of the subject. This can be seen in the postcoordinated expression below, which corresponds to the user's selections in the data entry screen:

254837009 |Malignant neoplasm of breast| : 408729009 |Finding context| = 410515003 |Known present| , 408732007 |Subject relationship context| = 444301002 |Mother of subject|

Note that a selection of 65412001 | Stepmother| would not trigger the rule as this concept is not a descendant of 444148008 | Person in family of subject|. (Stepmother has no genetic relationship to the patient.)

The components and criteria within a CDS rule should also be considered when designing or implementing the rules. Some of the additional aspects of these considerations have been described below.

Multiple events, conditions, or actions may be associated with each CDS rule. For example, two separate actions defined in a medication allergy rule might be:

1. Firstly to alert the user and;

2. Secondly to suggest an alternative drug

Additional examples of complex rules, with multiple conditions and actions, are provided in the section .

Each CDS condition (or criterion) can be further subdivided into a "name-value" pair. The criterion name will typically map to a data element in the electronic health record, while the criterion value is compared with the data that populates this element in the patient's health record.

Table: Examples of criterion name-value pairs

Some criteria may refer to the value of coded data elements, while others may refer to the value of non-coded data elements. When a criterion refers to a SNOMED CT encoded data element, the value may be a that defines the permitted subset of concepts that will satisfy this criteria.

Table: Examples of criteria which refer to coded data elements

Criteria that refer to non-coded data elements may use operators that are valid for the given element's data type. For example, criterion that refer to numeric data elements may use standard mathematical operators to restrict the required value.

Table: Examples of non-coded data elements

In this section we present a number of examples of CDS rules, using the 'ON event IF condition THEN action' pattern.

This simple CDS rule was designed to be used during a clinical encounter. If the patient is diagnosed with asthma, the appropriate management guidelines are automatically displayed on the clinician's workstation.

This rule has been designed to be used when ordering a medication. If the patient is 77386006 | Pregnant| and the drug has an active ingredient of 372756006 | Warfarin|, the clinician will be alerted and the CDSS will suggest an alternative blood thinner which does not pose a risk for expectant mothers.

The following example is a CDS rule designed to be used in an Emergency Department setting, when a patient has presented in the ER with chest pain. In this scenario, the attending physician may order a 312468003 | Blood potassium measurement|. If the patient is currently taking a medication with an active ingredient of 387461009 | Digoxin|, and the lab result is published indicating that the patient's potassium level is less than 3.0 mmol/L, the attending physician will be paged.

This section presents some examples of standards used to represent CDS rules. Please note that this list is not exhaustive, and other established and emerging standards for rule representation do exist.

The (ECL) provides a computable way of intensionally defining a set of clinical meanings represented in SNOMED CT. For example, the expression constraint below represents the set of lung disorders that have an associated morphology that is a type of edema.

< 19829001 |Disorder of lung| : 116676008 |Associated morphology| = << 79654002 |Edema|

When executed against a specific SNOMED CT edition, an expression constraint will return the set of concepts that match the given constraint. Expression constraints can also be used to query over precoordinated and postcoordinated expressions recorded in EHRs.

SNOMED CT expression constraints provide a standard way of referring to intensionally defined sets of SNOMED CT concepts (or expressions) that are required to test CDS rule criterion. Examples of CDS rules that use SNOMED CT expression constraints can be found in .

For more information about expression constraints, please refer to .

The Arden Syntax is a widely-used and mature markup language for representing, sharing, and processing clinical knowledge, which makes it suitable in the application of expressing rules for use in decision support. The syntax has a long history, but is currently maintained by HL7 International. One of the advantages of the ARDEN syntax is improved human readability which is achieved by its resemblance to natural language. This in turn makes ARDEN code easier for non-technical audiences to interpret.

When used in CDS, Arden code can be embedded in independent files called medical logic modules (MLMs). The improved readability of Arden syntax makes it easier for a clinician to validate the clinical accuracy of any given MLM. MLMs have been widely used and libraries of these modules are available. It is also worth noting that the Arden syntax does not define how it should be integrated within an electronic health record or how an application should use it.

For more information on the Arden Syntax, please refer to the .

PlanDefinition is a general FHIR resource which can be used to represent a range of CDS artifacts such as rules, order sets, and protocols. According to the HL7 FHIR specification, a resource contains a set of structured data items that conform to the definition of the resource type and can be used to exchange and/or store data to satisfy a wide range of clinical and administrative healthcare information needs. PlanDefinition is currently defined as a draft resource within FHIR's module. The Clinical Reasoning module is a draft of the Clinical Quality Framework Implementation Guide (or FHIR-Based Clinical Quality Framework). The guidance in this module is prepared as a Universal Realm Specification, which means it is designed to be used Internationally.

The PlanDefinition resource can be used to represent a rule using the Event-Condition-Action pattern. This pattern is defined within the actionDefinition element of the PlanDefinition resource. "A single, top-level actionDefinition represents the overall rule, with the triggerDefinition element used to specify the triggering event(s), the condition element used to specify the applicable condition for the rule, and the actionDefinition itself describing the action to be performed." The PlanDefinition resource is used to describe series, sequences, or groups of actions to be taken, while the ActivityDefinition resource is used to define each specific step or activity to be performed. An example of an XML instance of a PlanDefinition resource that encapsulates a Chlamydia Screening rule is shown below.

For more information on this FHIR resource, please refer to or .

Overview

EBMPracticeNet is a consortium of Belgian organizations whose mission is to develop a national online knowledge base of clinical practice guidelines based on evidence-based medicine (EBM). The project is funded by RIZIV-INAMI, the Belgian national health insurer. The consortium acknowledges that clinical decision support systems play a vital role in the implementation of evidence-based medicine. EBMPracticeNet is very active in the development, evaluation, and distribution of evidence based CDS knowledge, mainly for use in primary care settings. Their users include family physicians, nurses, physical therapists, occupational therapists, pharmacists, speech therapists, patients, and eventually dentists. Clinicians will access the system through their EHRs with an Infobutton (called "EvidenceLinker") which links coded diagnoses to relevant guidelines on the platform. The consortium is in the process of conducting an analysis to compare several terminologies to gauge which may be best suited for using encoded health records from a primary care setting with CDS services. An early version of the analysis report has identified SNOMED CT as the terminology with the most comprehensive coverage and best suited to unambiguously describe the concept.

Technology

The EBMPracticeNet consortium hosts a platform of clinical practice guidelines. Seventy five of these are from Belgium, and an additional 1000 international guidelines have been developed by Duodecim, the Finnish developers of EBM guidelines. The knowledge resources from Duodecim have been translated from its language of origin into both Dutch and French, and localized for Belgium using a variant of the ADAPTE framework. Currently all guidelines are accessible through the EHR using the EvidenceLinker, which suggests relevant guidelines based on the coded diagnosis. The EvidenceLinker currently uses ICPC-2 codes for this linkage. Additionally, EBMPracticeNet uses Duodecim’s EBMeDS as the engine in their clinical decision support system, which is currently in the pilot phase. A depiction of the architecture is shown below.

All EBMPracticeNet guidelines are associated with metadata which includes the relevant diagnosis codes for the ICPC-2 and ICD-10 classification systems. Mapping work is being considered that would add the appropriate SNOMED CT codes to this metadata. The SNOMED CT codes could then be used to link diagnoses to relevant clinical guidelines using EvidenceLinker. This EvidenceLinker feature is already available in all commercially available EHR systems in Belgium, which will help to facilitate rapid deployment. The CDSS engine, EBMeDS, has been designed to process SNOMED CT encoded health records.

Overview

Sundhedsplatformen which translates to the health platform, is a jurisdictional electronic health record (EHR) in Denmark with decision support capabilities. The system, provided by Epic, operates in the Capital and Sealand regions of Denmark, which cover a population of approximately 2.6 million people (almost half of the population of Denmark). The system uses SNOMED CT as the basis for its diagnosis-related decision support services. The first clinical rollout of the system was performed in May 2016. When the rollout is complete at the end of 2017, the system will provide services for up to 45,000 clinical users.

Standards and Technology

One of the design considerations of this system is to capture and store clinical data as structured content ( as opposed to unstructured or free text). This use of structured health data reduces the need for mapping and creates many opportunities including clinical decision support. In terms of terminology, Denmark’s national classification system, called Sundhedsvæsenets Klassifikations System (SKS) , is based on ICD-10 and a range of other classification systems. Traditionally, SKS has been used for statistical aggregation and for billing purposes. Although not designed for clinical use, SKS was selected as the primary classification system for the Sundhedsplatformen project to maintain the legacy requirements associated with billing and classification. There was therefore a need to represent both procedures and diagnoses within SKS.

Use of SNOMED CT

It is worth noting that SNOMED CT is already used in many existing clinical databases and registries throughout Denmark. So from an interoperability perspective, there was incentive for the regional EHR to incorporate SNOMED CT in its implementation approach. As previously mentioned, Epic’s diagnosis-related decision support system is widely based on SNOMED CT. For example, the ability to traverse SNOMED CT’s hierarchy is a key component of all diagnosis related decision support in the Epic system. Since the region chose SKS as the classification system, there was a need to map their local concepts to SNOMED CT to be able to perform decision support. Over 20,000 diagnosis concepts from SKS were mapped to SCT over a period of 8 months. The mapping was performed through several steps, the first of which was based on the international SNOMED CT to ICD-10 map. Compared to the alternative (i.e. mapping from scratch), this approach was a major help and significantly increased the speed and ease of the mapping process.

Background

SNOMED CT is a standardized and multilingual clinical terminology used by clinicians and other health care providers to record and share health information. As the most comprehensive terminology in the world, SNOMED CT contains over 300,000 active clinical concepts, each representing a unique clinical meaning. These concepts are organized into hierarchies such as 404684003 | Clinical finding|, 71388002 | Procedure|, 123037004 | Body structure| and 373873005 | Pharmaceutical / biologic product|.

SNOMED CT is increasingly being used in clinical decision support (CDS) systems to support healthcare providers in making well informed clinical decisions. SNOMED CT's polyhierarchy, defining relationships and concept model are just some of the terminology's features that help to link patient records to the appropriate guidance, clinical knowledge and decision support rules.

Purpose

The guide Data Analytics with SNOMED CT explains how SNOMED CT may be used to support data analytics, and how integrating clinical records with decision support tools can improve the care provided to individual patients by guiding safe, appropriate and effective patient care.

The purpose of this guide is to review the approaches, tools and techniques used to implement clinical decision support with SNOMED CT, and to share developing practice in this area. It is anticipated that this guide will benefit Members, vendors and users of SNOMED CT by promoting a greater awareness of how SNOMED CT has been and can be used to enhance clinical decision support implementations.

This guide introduces the key components of clinical decision support systems, explores ways in which SNOMED CT can be used to enhance the capabilities within each of these components, and presents some case studies in which SNOMED CT has been used to support clinical decision support. The guide focuses on CDS systems that use a combination of SNOMED CT encoded knowledge artifacts (e.g. CDS rules and guidelines) and SNOMED CT encoded electronic health records. However, using SNOMED CT to enhance non-SNOMED CT enabled CDS and EHR systems is also considered.

The target audience of this guide includes:

• Members who wish to learn about using SNOMED CT for clinical decision support

• Clinicians, informatics specialists and technical staff involved in the planning, management, design or implementation of clinical record applications or clinical decision support systems

• Software vendors, data analysts, epidemiologists and others designing SNOMED CT based solutions

This guide assumes a basic level of understanding of SNOMED CT. For background information it is recommended that the reader refers to the .

The guide presents an introduction to clinical decision support using SNOMED CT and is structured as follows:

• : Provides an introduction to the guide, and defines clinical decision support (CDS) and clinical decision support systems (CDSS). It then presents an overview of CDS (including its scope, history and the 'five rights'), it explores the functional and clinical areas in which CDS is used, the features of SNOMED CT that support CDS, and a table of abbreviations used in this guide.

• : Presents an overview of the logical architecture of an electronic health records system that uses CDS, and the internal components of a CDSS system.

• : Describes the knowledge base of a CDSS, in which the knowledge artifacts that drive the CDS are stored, and how SNOMED CT may be used within these artifacts.

This playlist brings together all videos on clinical decision support 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 clinical decision support in health information systems.

Open playlist on YouTube:

👉

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.

• Use the forward () and back (

This section describes a range of organizations that have used SNOMED CT for clinical decision support. The organizations that have contributed to this review include:

• EBMPracticeNet

• Kaiser Permanente

Overview

The Department of Biomedical Informatics at the University of Utah is an internationally recognized leader in both research and education in the field of medical informatics. The university has been a major contributor to the development of health information standards and open source initiatives, many of which have been leveraged in their own solutions, including their clinical decision support systems.

Standards, Architectures, Techniques

As a major contributor to the development of the OpenCDS collaborative, the University of Utah has been able use the architecture from OpenCDS to provide a service-based approach to their CDSS and clinical quality measurement efforts. As part of this effort, they have made use of HL7 International’s Decision Support Service (DSS). The University also played a key role in the development of OpenInfobutton, an opensource web service and reference implementation of HL7's infobutton standard. Infobuttons are context-sensitive links, which can be embedded in EHR systems as buttons or tabs. OpenInfobutton was funded by the US Veterans Health Administration (VHA) and developed by researchers at the VHA, Duke University, and the University of Utah.

Using SNOMED CT

SNOMED CT value sets are used to map to clinical concepts referenced in the University's CDS rules. SNOMED CT value sets are also used to configure patient problem lists in OpenInfobutton. Since the Infobutton standard uses SNOMED CT for problem lists, SNOMED CT concept identifiers are embedded in the requests and responses between the EHR and OpenInfobutton architecture, as shown in the figure below.

The University has benefited from using a standardized clinical reference terminology which can be used across clinical domains. By using SNOMED CT in OpenInfobutton, the University has improved the interoperability between EHR systems and knowledge resources, by providing more efficient access to the indexed knowledge content.

Terminology

Practice Fusion’s EHR uses the Health Language Enterprise Terminology Management Platform from Wolters Kluwer to support the management of its terminology content. This terminology platform enables Practice Fusion’s patient health records to be encoded using SNOMED CT, ICD-9, ICD-10 and a range of other code systems. Practice Fusion’s EHR uses a physician friendly library of terms, together with mappings to SNOMED CT, ICD-9 and ICD-10, to support the selection of appropriate clinical concepts at the user interface.

Practice Fusion has chosen to make SNOMED CT codes and descriptions available for viewing in the user interface. As shown in the screen shot below, when recording a diagnosis a provider can examine the mappings between the user interface term, ICD-9, ICD-10 and SNOMED CT. This approach has received positive feedback from their users as it provides an additional layer of validation when selecting a concept to record in the patient’s health record. Since 2014, all diagnoses recorded in Practice Fusion’s EHRs have included the associated SNOMED CT codes.

Clinical Decision Support Advisories

Practice Fusion includes a feature called Clinical Decision Support (CDS) advisories. When a new encounter is entered, the patient's record is processed against a rule engine with specific criteria to determine whether the patient requires a clinical intervention. If the patient requires an intervention, one or more yellow alerts will appear at the top of the encounter. These alerts can be resolved by following an appropriate sequence of events such as ordering a lab test or completing a screening or assessment.

Practice Fusion creates and maintains value sets which include, SNOMED CT concepts to support criteria for their CDS advisories. SNOMED CT codes recorded in the patient’s record are tested for membership in relevant SNOMED CT value sets, to determine which CDS advisories should be triggered. All diagnosis related value sets and some procedural value sets used by their CDS advisories contain SNOMED CT concepts. In addition, Practice Fusion uses SNOMED CT to define their encounter and attribute value sets.The SNOMED CT value sets used by Practice Fusion’s advisories are mostly defined intensionally using SNOMED CT’s hierarchy and (in some cases) SNOMED CT’s defining relationships. This allows the value sets to be easily updated (by re-executing their intensional definition) when a new version of the terminology is adopted. Practice Fusion has found that SNOMED CT’s polyhierarchy provides a significant advantage when defining these value sets, because similar concepts can easily be grouped together by including all descendants of a common supertype.

SNOMED CT is particularly useful for rare diseases, enabling expression of diagnoses requiring a high degree of specificity and which may not be sufficiently defined in ICD. For example, the screen shot below illustrates a CDS advisory that is triggered when clinical markers considered high-risk for 274864009 | Pompe disease|, are detected in the patient’s health record. Using the hierarchy of SNOMED CT, appropriate value sets were defined that help to identify those patients for which a GAA enzyme assay order should be considered to confirm the presence or absence of the diagnosis.

Examples of other advisories that use SNOMED CT value sets in their criteria include:

• Patient requires screening for clinical depression and follow-up plan

• Patient has poor control of hemoglobin A1C and needs a new lab test

• Patient has diabetes and is due for an eye exam

Practice Fusion has also used SNOMED CT to represent procedures for follow up actions, such as assessments and interventions. CDS advisories are often linked to Clinical Quality Measures (CQM) in the Practice Fusion workflow. When a provider fulfills the requirements associated with a specific CDS advisory, they will get credit for fulfilling the requirements of the associated CQM, such as completing a specific assessment. Using SNOMED CT for these assessments facilitates the capture and storage of the associated treatment plans.

The two main approaches to preparing clinical guidelines for use in CDS are to use simple markup (also referred to as "semantic tagging"), and to use a standard guideline representation language.

Simple guideline markup involves annotating free-text clinical guidelines using terminology codes that represent its meaning. This enables relevant guidelines to be retrieved based on specific codes recorded in a patient's health record. For more information on this approach, please refer to .

An alternative approach is to use a standard guideline representation languages to formally define each guideline. Some examples of standard guideline representation languages, such as the Guideline Definition Language (GDL) and the Guideline Interchange Format (GLIF) are presented in the section .

This section examines how clinical guidelines can be linked to SNOMED CT to enable the automated display of contextually relevant knowledge resources. We begin by reviewing how a guideline can be linked to a SNOMED CT concept using semantic tags. Next we will examine how SNOMED CT concepts can be associated with guidelines using a reference set. Lastly, we will look at the automated display of a contextually relevant guideline, based on the selection of a SNOMED CT concept in a data entry protocol.

Orion Health

Overview

Orion Health currently has four products which leverage SNOMED CT for Clinical Decision Support. These are:

• Global Drug Model (GDM);

• Orion Health Medicines;

• Orion Health Problem List; and

• Clinical Decision Support (CDS) application.

To allow for multiple customers to be supported worldwide, these products adopt a modular approach to terminology deployment. A customer selects the relevant data loader for their jurisdiction and the experience is customized for their region automatically. When deployed in SNOMED CT member countries, this process involves loading the relevant SNOMED CT National Edition and local medication codes. Drug data is represented using a common model based on SNOMED CT. This enables customers already using SNOMED CT coding to migrate to these products very quickly. Other local medication codes can be translated to the SNOMED CT equivalent representation using integrated mappings. Orion’s Medicines platform provides support for terminologies from the UK, Australia, New Zealand, USA and France, as well as support for other customers with local data sets.

SNOMED CT offers a range of significant benefits to Orion Health’s CDS solutions. SNOMED CT’s relationships and drug class information are used to optimize the drug database during the import process. Orion Health has also developed several algorithms which allow for extremely fast retrieval of medication data, traversal of the medication hierarchy and testing for concept subsumption. These SNOMED CT features are used extensively by the Clinical Decision Support APIs and are therefore a core part of Orion Health’s CDS applications. These products also provide the ability to add new medications that are not predefined in the terminology, such as extemporaneous medications, clinical trial drugs or medications obtained in a different country. New medications can be fully modeled within the GDM concept hierarchy, and assigned a valid SNOMED CT extension identifier using the customer’s assigned namespace.

The Amadeus Clinical Portal as shown in the diagram below provides a single point of access for clinicians to manage patient information. This portal integrates the CDS products mentioned above, including the Medicines and Problem List applications. All Orion Health’s CDS applications expose their data using FHIR’s RESTful APIs. The use of SNOMED CT in these products also facilitates easier translation to standard messaging formats, such as HL7 CDA or other message structures mandated by local jurisdictions.

The Global Drug Model (GDM) enables Orion’s software to be deployed worldwide. This application standardizes and normalizes data sets from many different countries into a single data model. Customers upload their local SNOMED CT edition into GDM via an application that runs inside the Orion Health Clinical Portal. GDM processes the data and then publishes it using HL7 FHIR’s RESTful APIs. The processing performed by GDM makes heavy use of the SNOMED CT defining relationships, as well as discovering data about drug classes that is present in the terminology releases. This application facilitates a number of clinical decision support functions, including duplicate therapy checking and linking to relevant drug monographs. The use of SNOMED CT concepts in the GDM is illustrated in the screenshot shown in the diagram below.

Orion Health Medicines supports an authoritative medication list for each patient, and enables its curation, reconciliation and management. The Medicines application uses the FHIR APIs from GDM to allow the discovery and validation of medications. Patients can also manage their own list of medications via the Orion Health Patient Portal or the Orion Health Engage mobile application.

Orion Health Problem List is a centralized and web-based list of patient problems. It enables healthcare providers to view, create and change clinical information, procedures, psychosocial and cultural issues that may affect the care of the patient, as well as safety and security concerns that may be relevant to medical staff caring for the patient. The Problem List application also integrates with GDM via the FHIR APIs, and enables clinicians to record allergies, adverse reactions and intolerances at the drug class level. The Problem List application is fully integrated with SNOMED CT, with a variety of fields using SNOMED CT subsets.

The Clinical Decision Support (CDS) application is a new product that integrates with the three applications mentioned above, as well as other third party decision support applications. The CDS application provides APIs to support duplicate drug therapy checking, drug allergy checking, links to drug monographs and additional drug information, and grouping of similar medications based on a common ingredient or therapeutic moiety.

For example, when new medications are added to a patient’s medication list, they are automatically screened against the current list of medications for that patient using the CDS Duplicate Therapy API. This check ensures that the clinician is advised of existing medications with the same ingredients. Clinicians viewing medications are able to access drug monographs and any other additional information listed against a medication. The medication list is also screened using the CDS Drug Allergy API, which presents a warning if a drug allergy or intolerance to a particular medication or drug class is detected. These checks use data traversal algorithms that were developed by Orion Health for fast traversal of the SNOMED CT concept hierarchy and defining relationships. The warnings have been specifically designed to minimize alert fatigue. The Orion Health Problem List application is shown below in the diagram below with an adverse reaction alert.

At the heart of a clinical decision support system, the inference engine uses inputs from the user, the record services, and the terminology services to process the machine readable rules, guidelines, or CDS artifacts. It is the job of the inference engine to establish if the CDS conditions have been met and determine the appropriate outcome. It does this by executing queries over the health records and terminology, to test the CDS conditions defined in the CDS rules. Note that it is the communications mechanism which handles the action defined in the CDS rules, but the inference engine determines whether or not the action should be carried out.

The diagram below illustrates the key inference engine interactions described above:

The following topics , which relate to the inference engine, are explored in the following sections:

• Reasoning with SNOMED CT

• Accessing Clinical Records

• Accessing Terminology

of SNOMED CT can be used in a range of techniques which may then be applied to clinical decision support. For example, these techniques can help to execute decision support logic by assisting the inference engine in evaluating the trigger conditions defined in CDS rules.

This section describes these SNOMED CT techniques with respect to CDS by first providing an overview of the technique, and then presenting an example of how the inference engine can apply the technique to execute a specific CDS rule.

The following SNOMED CT techniques can be used by the CDS inference engine:

A subset is defined in mathematics as a set whose members are all contained in another set. A SNOMED CT typically refers to a collection of components that all come from the same edition of SNOMED CT. This is depicted in the diagram below.

A SNOMED CT subset may be defined extensionally, by enumerating all of the components in the set or intensionally, by defining a query written using the .

Extensionally and intensionally defined subsets can both be represented as SNOMED CT reference sets, which support versioning and traceability. For more information about reference sets, please refer to the . For additional information on using subsets in queries, please refer to in the .

This section presents a simple example of a CDS rule defined using a SNOMED CT subset, and explains how this rule could be executed by the CDS inference engine.

The diagram below shows a simple CDS rule based on the IF-condition-THEN-action pattern. This rule uses a SNOMED CT subset to define the set of diagnoses that should trigger the display of the asthma management guidelines. It can be read as follows - "IF the diagnosis is a member of the Asthma conditions reference set THEN display the asthma management guidelines".

When executing this rule, the inference engine checks the given diagnosis for membership in the 239999999106 | Asthma conditions reference set|. The associated SNOMED CT subset is defined extensionally using a simple type reference set, and its members can be queried using a standard SNOMED CT terminology service.

The diagram below illustrates the process followed by the inference engine in executing the CDS condition in the above rule, when the clinician selects a diagnosis of 370220003 | Occasional asthma|. The inference engine checks if this concept is a member of the 239999999106 | Asthma conditions reference set|, and determines that it is not a member. As a result, the condition evaluates to false, and the action is not triggered.

One of the fundamental benefits of SNOMED CT is its built-in polyhierarchy that specifies which concepts are subtypes of others. This hierarchy facilitates the automated grouping of health records which have been encoded using SNOMED CT. The 116680003 | is a| relationships in SNOMED CT form the basis of its subtype hierarchy.

For example, 54441004 | Fracture of shaft of femur| has an 116680003 | is a| relationship to 71620000 | Fracture of femur|, and therefore (as the diagram below illustrates), the concept 54441004 | Fracture of shaft of femur| is subsumed by 71620000 | Fracture of femur| .

This also means that if a patient has a 54441004 | Fracture of shaft of femur|, then it is implied (i.e. it is also true) that they have a 71620000 | Fracture of femur|. We can use this principal to aggregate health records that have been encoded with SNOMED CT. By selecting any code that is a subtype of 71620000 | Fracture of femur|, we are selecting all the codes that imply that 71620000 | Fracture of femur| is true (given the appropriate context).

When testing for subsumption, we must also consider the transitivity of the 116680003 | is a| relationship. For example, the diagram below indicates that 426656000 | Severe persistent asthma| is a subtype of 370221004 | Severe asthma| which is a subtype of 195967001 | Asthma|. Therefore 426656000 | Severe persistent asthma| is also a subtype of 195967001 | Asthma|.

As previously suggested in the section , the hierarchical relationships of SNOMED CT can be leveraged to enable clinical decision support. More specifically, we can apply subsumption testing to make additional determinations. For additional information on subsumption, please refer to in the .

The diagram below shows a simple CDS rule based on the IF-condition-THEN-action pattern. This rule uses the descendant or self operator (<<) from the to check if the diagnosis is in the set of concepts that includes 195967001 | Asthma| and all of its subtypes.

When executing this rule, the inference engine tests if the given diagnosis is subsumed by the concept 195967001 | Asthma|. This subsumption testing can be performed using a range of approaches, including using a transitive closure implementation. A transitive closure table facilitates rapid testing of all possible 116680003 | is a| relationships, and provides a very effective way of testing concept subsumption in relational databases.

The diagram below illustrates the process followed by the inference engine in executing the CDS condition in the above rule, when the clinician selects a diagnosis of 426979002 | Mild persistent asthma|. The inference engine checks if this concept is a subtype of 195967001 | Asthma|, and determines that it is. As a result, the condition evaluates to true, and the action is triggered.

In addition to the subtype relationships in SNOMED CT, attribute relationships may be used to support the definition of concepts. Only the relationships that are necessary (i.e. always true) are used as defining relationships in SNOMED CT. This is because these are the ones that produce reliable and consistent inferences. For example:

The green arrows in the diagram above show that the concept 22298006 | myocardial infarction| has two necessary attribute relationships that represent a characteristic of the meaning of the concept. It always has an 116676008 | associated morphology| of 55641003 | infarct|, and it always has a 363698007 | finding site| of 74281007 | myocardium structure|. The blue arrows in the diagram above are used to indicate the subtype relationships.

The full definition of a concept consists of both the defining subtype relationships and the defining attribute relationships. There are over 50 attributes in SNOMED CT which can each be used as the "type" of a defining relationship, including 246075003 | causative agent|, 260686004 | method|, and 272741003 | laterality|.

The SNOMED CT Concept Model provides rules about how these attributes can be used to define concepts from different hierarchies. The (MRCM) represents these rules in a form that can be read by a computer and applied to test that CDS criterion comply with these rules.

As previously suggested in the section , the defining relationships of SNOMED CT can be leveraged to support CDS. For additional information on using SNOMED CT defining relationships in queries, please refer to of .

The diagram below shows a simple CDS rule based on the IF-condition-THEN-action pattern. This rule uses attribute refinements in the to define the set of procedures with a 71388002 | Procedure site| that is a type of 20139000 | Structure of the respiratory system|.

Using attribute refinements in the CDS rule criteria facilitates richer expressivity and specificity in the rules. For example, we can restrict pharmaceutical/biological products based on their active ingredients, procedures based on their methods, and disorders based on their finding sites.

When executing this rule, the inference engine must process the defining relationships of each 71388002 | Procedure| concept to determine which ones have a 363704007 | Procedure site| that is a type of 20139000 | Structure of respiratory system|. These relationships are distributed as part of SNOMED CT's Release Format 2 relationship file, which can be searched by a terminology service to discover relationships that match the given attribute refinement.

The diagram below illustrates the process followed by the inference engine in executing the CDS condition in the above rule, when the clinician selects the therapy 386565009 |Postural drainage therapy|. Once the inference engine has found the defining relationships whose source is 386565009 |Postural drainage therapy| and whose type is 363704007 | Procedure site|, it determines whether the destination of these relationships is either 20139000 | Structure of respiratory system| or a subtype of 20139000 | Structure of respiratory system| (e.g. using a transitive closure table). Since the given procedure has a 363704007 | Procedure site| equal to 20139000 | Structure of respiratory system|, the condition in the rule evaluates to true, and the action is triggered.

Description logic (DL) reasoners can apply additional logic-based techniques to assist with clinical decision support reasoning. Two of the DL techniques supported by SNOMED CT have been briefly described below.

It is also worth pointing out that DL can be applied over the terminology or to the terminology in combination with the record structure. For more information on this topic, please refer to sections and in the .

SNOMED CT supports the use of postcoordinated expressions to define additional clinical meanings beyond the standard precoordinated concepts. Postcoordinated expressions are comprised of two or more concepts, and are structured in accordance with the compositional grammar. A simple example of a postcoordinated expression is:

This can be read as "an abrasion with a finding site of skin of ankle".

When postcoordinated expressions are used to capture and record clinical meaning in a health record, the CDS inference engine may need to be able to test if one expression subsumes another to execute the CDS rules. For example, it would be reasonable to conclude that the first expression listed below, subsumes the second expression if you were aware that 40196000 | Mild pain| is subsumed by 22253000 | Pain|.

However, many expressions are much more complex than this and may involve multiple focus concepts, attribute groups, and nesting as examples. There are a couple of methods which can be utilized to determine if one expression subsumes another. The first process, which is a manual process, involves normalizing the expressions, comparing the primitive focus concepts, and then comparing the defining attributes. The other is an automated process which can be used to compare expressions for subsumption. Expressions can be imported into a description logic classifier and classified in the same way as SNOMED CT concept definitions, which tests for subsumption in the process.

The transitive nature of the 116680003 | is a| attribute allows us to make subtype inferences. This topic was explored in the section on . In some cases, different types of attribute relationships may be related to one another in such a way that additional inferences are possible. For example (using fictitious concepts) if Lucy 619999999100 | Has sister| Beth, and Beth 629999999107 | Has daughter| Jane, then Lucy 639999999109 | Has niece| Jane. The chain from 619999999100 | Has sister| to 629999999107 | Has daughter| implies 639999999109 | Has niece|. This rule can be expressed as:

At present, the only property chain recognized in the International Edition of SNOMED CT is from | Direct substance| to | Active ingredient| and can be expressed as such:

This can be used to provide a link from product administration (as part of a procedure) to substance administration. Additional property chains can be added at the local implementation level, if required.

This section describes the approaches that inference engines use to access EHR records for CDS. The CDS rules that an inference engine executes typically include references to EHR records and terminology. There are two general approaches to accessing health records from these CDS artifacts. The first is the direct access approach, in which a reference to the physical store is used. A simple example of this would be a reference to a patient diagnosis in a database table. The other approach is to base the CDS references on a common logical information model, and then map this to one or more physical datastores, as required. This approach enables a more standardized approach to the development of CDS rules and other artifacts. These two approaches are described in more detail below, along with some of the advantages, challenges, and examples. Please note that standards for accessing clinical records will be discussed in section . Approaches to access the terminology which will be discussed in section .

Perhaps the most obvious approach to accessing health records is to use direct references to the locations in the clinical record store that will be used in a CDS rule. Many consider this the more common approach for point of care (POC) decision support today. For example, the pointers within a CDS rule could be expressed to reference a schema, table, and column in an SQL database. This approach requires a detailed knowledge of how the EHR data is stored to achieve an appropriate outcome from CDS tools. The challenge with this approach is that it can be more difficult to share CDS artifacts across institutions that may use different physical data stores.

The logical model approach aims to standardize all references to EHR data, by specifying a common logical information model upon which all CDS rules are defined. This enables CDS rules to be shared and reused in different physical implementations. However, an additional transformation is usually required for each physical EHR store, to convert the logical references into physical ones. Examples of the logical model approach are presented in section Standards for Accessing Clinical Records.

This section presents some examples of standards for accessing clinical records. Please note that this list is not complete, and other standards and formalisms for accessing clinical records do exist.

The HL7 Clinical Information Modeling Initiative (CIMI) is an HL7 International working group, which aims to improve the interoperability of healthcare systems by providing a shared open library of implementable clinical information models. CIMI clinical models, which are defined using computable formalisms such as the Archetype Definition Language (ADL) and Archetype Modeling Language (AML), are based on a common reference model using a common set of data types. CIMI models also have formal bindings to standard terminologies, including SNOMED CT and LOINC. SNOMED CT has been selected as the primary reference terminology for CIMI's clinical models. A number of CDS efforts within HL7 International are expected to use CIMI clinical models as the basis for referencing clinical data within CDS artifacts. For more information on CIMI please refer to and .

The Quality Improvement Core (QICore) Implementation Guide is a U.S. realm-specific CDS initiative that references a logical model called the Quality Information and Clinical Knowledge () model. The QUICK model (which is expected to be aligned with CIMI formalisms) will provide a uniform way for clinical decision support and quality measures in the U.S. to refer to clinical data. The QUICK logical model is defined as a series of QICore specific FHIR profiles. It provides a way for applications to access data using FHIR interfaces. Several of these QICore profiles have bindings to SNOMED CT value sets in their definition. For example, the Condition model (shown below) binds a 'SNOMED CT Body Structure' value set to the data element 'bodySite'.

The QUICK logical model provides the basis upon which the FHIR RESTful interfaces refer to clinical data in a CDS service. For more information on QICore please refer to .

The Virtual Medical Record (vMR) for CDS is an HL7 standard, which describes a standardized “virtual interface” for CDSSs to refer to the data in clinical records. The vMR logical data model is based on the HL7 V3 RIM (Reference Information Model). Developing CDS rules can be time-consuming and costly. Hence, the key goal of the vMR is to provide a simplified common information model upon which sharable CDS resources can be developed. To implement the vMR, each EHR system must create a virtual interface that exposes its clinical data in the standardized vMR format, to facilitate shared CDS logic working across multiple EHR systems. An example of an expression, written in terms of the HL7 vMR, which could be used in a CDS rule, is shown below. This expression asserts that a patient has a condition of 195967001 | Asthma| that has a status of 55561003 | Active|.

Example from HL7 Version 3 Standard: Clinical Decision Support; Virtual Medical Record (vMR) Logical Model, Release 2

vMR expression example

The vMR's data model includes clinical findings, problems, allergies, adverse advents and patient history. The vMR was also optimized to permit CDS languages such as to reference a standard model of clinical data. For more information about the HL7 vMR please refer to the .

GELLO is an object-oriented programming language that can be used to support access to health record data in CDS. It has been adopted by ANSI and HL7 as a language used in CDS and GELLO Release 2 now part of the HL7 v3 product suite.

GELLO provides a standardized interface and query language for accessing data in health information systems. Expressions can also be defined to compare data values and attributes. These values and attributes can then be used in decision support knowledge resources such as rules and guidelines. GELLO works hand in hand with the (vMR). A major advantage of this approach is that GELLO code can be used in different environments where health data is stored using a variety of formats and technologies.

Using GELLO with the vMR ensures that the code does not alter the physical medical record. It can also be used to answer complex queries and to query a reference terminology such as SNOMED CT. The example screen shot below illustrates how SNOMED CT refinements can be used in a GELLO expression:

For more information about GELLO, please refer to or .

As references to terminology codes may exist in both health records and CDS artifacts, the inference engine needs to be able to access terminology services to execute CDS logic. Furthermore, to maximize the benefits of using SNOMED CT, additional terminology operations, such as finding descendants of a concept and finding the value of a defining relationship, can be used. For example, a CDS rule may refer to all the descendants of 56265001 | Heart disease| to ensure that a specific cardiology CDS rule is applied to all applicable diagnoses. Similarly, a CDS rule may need to find all the active ingredients in a medication, to ensure that a contra-indication does not occur.

This section discusses some of the options that a CDS inference engine can use to access terminology content.

As discussed in section , terminology services are those services required to load, update, access and make effective use of terminology content. Terminology services provide important functions to CDSSs, such as term searching (i.e. synonyms), definitional and reference set querying, and retrieval of map data. It is also useful if Terminology Services support the execution of the , as this is a standardized way of representing terminology queries in CDS rules. For more information on Terminology services, please refer to the .

An application programming interface (API) for a SNOMED CT enabled terminology server can be used to execute SNOMED CT searches and queries. The principle benefit of using a terminology server API is the reusability. Other systems are able to access terminology services without having to re-implement their functionality. Another key benefit is that the internal workings of the solution can be modified, improved, upgraded without impacting the external interfaces. For example, SNOMED CT can be updated, without necessitating any changes to the external systems which use terminology services. A number of commercial terminology servers offer proprietary APIs that enable SNOMED CT search and query. These include Dataline’s SnAPI solution and B2i’s Snow Owl Terminology Server. The following diagram depicts how the individual terminology services interact with the terminology store:

Services that load the terminology data into the server, either for installation or updating are illustrated on the left, while services which search and query over the installed terminology content are depicted on the right. The diagram also shows how the services depicted on the right could be made available to other services and components such as a CDS inference engine through the use of an API.

Standardized APIs for terminology services are also available. For example, HL7's specification for a FHIR Terminology Service, which is described as a service that lets healthcare applications make use of codes, code systems, and value sets without having to become experts in the fine details of terminology. The services provided include code lookup and validation, value set expansion, subsumption testing, and maintaining a transitive closure table. HL7 has also published Common Terminology Services 2 (CTS2) which provides a standardized API that supports access to terminology servers which may contain a variety of code systems, including SNOMED CT.

The SNOMED CT Clinical Decision Support guide reviews the approaches, tools and techniques used to implement clinical decision support with SNOMED CT, and shares developing practice in this area. It is anticipated that this guide will benefit members, vendors and users of SNOMED CT by promoting a greater awareness of how SNOMED CT has been and can be used to enhance clinical decision support implementations.

Provide Feedback

Overview

Kaiser Permanente (KP) has a long history with SNOMED CT, dating back to the 1990s when they collaborated with the College of American Pathologists (CAP) on the development of SNOMED RT (Reference Terminology). KP was also one of the first healthcare organizations to implement a SNOMED CT enabled health record (EHR). KP HealthConnect (KPHC), Kaiser Permanente's enterprise electronic medical record, was developed by Epic and hosts the records of over 10 million patients. KPHC uses a set of clinician and patient friendly terminologies, collectively known as the Convergent Medical Terminology (CMT), with SNOMED CT as its core reference terminology. KP has made their contributions to SNOMED CT available to the broader community by donating CMT to SNOMED International and the US National Library of Medicine (NLM).

KP HealthConnect

KP loads SNOMED CT in its native RF2 format into the HealthConnect EMR system. The EMR "Chart Search" functionality can execute a global search for diagnoses, procedures, and laboratory results against a given patient. All patient encounters that match the resulting criteria are displayed to the clinician. This provides a global summary of all encounters which relate to a given condition. This function takes advantage of the hierarchical structure of SNOMED CT. KP also maps the "clinician friendly" terms used in the EMR to SNOMED CT to meet and Health Information Exchange reporting requirements.

Value sets are an integral part of terminology management services at Kaiser Permanente. Value set identification, development, deployment, and maintenance is performed using a custom tool developed within KP. This "Subset Management" tool utilizes the native ontological structure of SNOMED CT and adds KPHC local terminology as additional artifacts within the terminology model. The formal concept definitions of SNOMED CT are used to define and generate the required value sets. The "CMT Query" tool also uses the hierarchy of SNOMED CT and description logic reasoning to identify value sets of clinician friendly terms used in patient clinical encounters. These value sets are also used within KPHC to drive business intelligence (including CDS), support workflow, and enable data reporting and analytics. As shown in the screen shot below, the queries used to define value sets leverage SNOMED CT defining relationships, such as those using the attributes 363698007 | Finding site| and 116676008 | Associated morphology|.

KP uses the native functions provided by Epic to define and maintain CDS rules. This accounts for all criteria used in the rules, such as inclusions and exclusions. A screen shot of the tool used to define these criteria is shown below.

Clinical decision support at Kaiser Permanente leverages the value sets developed by their CMT team. For example, a CDS rule which uses value sets associated with 195967001 | Asthma| and 33252009 | beta-blocker| drugs is used to trigger an alert when specific conditions are met in the patient encounter, diagnosis, or problem list. The diagram below shows the associated value sets used in this rule.

Overview

The National Institutes of Health (NIH) is a federally sponsored biomedical research program in the United States. The NIH is made up of 27 separate institutes and centers. The Intramural Research Program's (IRP) programs are embedded in 24 of the NIH Institutes. One of those institutes, the National Library of Medicine (NLM) is the world's largest biomedical library and the SNOMED CT National Release Center for the United States. The NLM curates an extensive collection of medical knowledge in various formats which is used by millions of people around the world. Across the IRP, some of their Principal Investigators (PIs) use SNOMED CT in their research. A selection of the Intramural Research Program's initiatives which relate to SNOMED CT and CDS, are briefly described below.

Value Set Authority Center

The Value Set Authority Center (VSAC), managed by the NLM, is a service designed to maintain and distribute the value sets defined in (eCQMs). Each VSAC value set consists of codes and terms from clinical vocabularies such as SNOMED CT, RxNorm, LOINC and ICD-10-CM . Value sets derived from SNOMED CT are used to support the calculation of data quality measures which in turn provide feedback to clinicians about the quality of care. Note that VSAC is a project administered by NLM, but the actual data quality computations are done at individual healthcare sites.

is an resource which accepts requests for information on diagnoses (problem codes), medications, and lab tests, and returns related information from . The API is available as a web or as a web , which can be integrated with an EHR. MedlinePlus accepts SNOMED CT problem codes as input and provides CDS in the form of targeted information prescription. The example below shows how the Medline Plus Connect request and response are structured. Note that the response includes the title and link of the matched topic and may include synonyms, attribution acknowledgements, and related links.

The requests conform to the . A screen shot of the application's response to a request for information on | Asthma| is provided below:

Some NLM researchers also participate in external projects which utilize SNOMED CT. One such project is . This collaborative uses SNOMED CT to integrate diagnostic data. This semantic data integration is then used by research studies which in some cases serves as input into the authoring of CDS knowledge artifacts.

One of the programs related to OHDSI is (IMEDS), which includes a number of projects led by NIH researchers, such as:

• NIH Investigators

• Ferdinand Dhombres (NIH)