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 inference engine 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
Clinical guidelines and care pathways
Documentation templates
Order sets
The characteristics of these knowledge artifacts are described in the section .
The diagram below illustrates the key interactions with the knowledge base, as described above.
The topics below are presented in more detail in the following sections:
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.
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.
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.
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:
A CDS condition defines the question(s) that must be answered to determine the outcome of the rule. Examples of conditions include:
The CDS action describes what should be done if the condition evaluates to true. Examples of actions include:
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 SNOMED CT Compositional Grammar. 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
Precoordinated as a single SNOMED CT concept identifier explicitly representing family history of diabetes mellitus.
160303001 | Family history: Diabetes mellitus|
Postcoordinated as a SNOMED CT expression that includes a concept representing a family history of disorder and specifies the diabetes mellitus as the disorder.
281666001 |Family history of disorder| : 246090004 |Associated finding| = 73211009 |Diabetes mellitus|
A context specific family history section in the record structure
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
Attribute
Value
Clinical Findings
408729009 | Finding context|
410515003 | Known present|
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:
Firstly to alert the user and;
Secondly to suggest an alternative drug
Additional examples of complex rules, with multiple conditions and actions, are provided in the section Rule Examples.
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
Pregnancy status
77386006 | Pregnant|
Drug prescribed
85990009 | Codeine|
Hematocrit result
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 SNOMED CT Expression Constraint that defines the permitted subset of concepts that will satisfy this criteria.
Table: Examples of criteria which refer to coded data elements
Condition
<< 195967001 | Asthma|
Diagnosis
<< 29857009 | Chest pain|
Procedure
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
Wait time
Quantity
>
90
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 SNOMED CT expression constraint language (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 Rule Examples.
For more information about expression constraints, please refer to SNOMED CT Expression Constraint Language.
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 HL7 Implementation Guide for Arden Syntax, Release 1.
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 Clinical Reasoning 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 http://build.fhir.org/plandefinition.html or http://build.fhir.org/clinicalreasoning-module.html.
281666001 |Family history of disorder|:
246090004 |Associated finding|= 73211009 |Diabetes mellitus|
A separate field in the record structure to indicate the context of the disorder recorded
408732007 | Subject relationship context|
410604004 | Subject of record|
408731000 | Temporal context|
410512000 | Current or specified time|
Procedures
408730004 | Procedure context|
385658003 | Done|
408732007 | Subject relationship context|
410604004 | Subject of record|
408731000 | Temporal context|
410512000 | Current or specified time|
41 118582008 | %|
< 71388002 |Procedure| : << 363704007 |Procedure site| = << 20139000 |Structure of respiratory system|
258703001 | days|
Lab result
Quantity
<=
7.5
258813002 | mmol/L|
Birth date
Date
>=
1990/01/01
n/a
Family History Record Section
73211009 | Diabetes mellitus|
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 Guidelines with SNOMED CT.
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 Standards for CDS Guidelines.
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.
One approach known as simple markup, involves the application of semantic tags using terminology codes (such as SNOMED CT concept identifiers) to free text clinical guidelines. When using SNOMED CT, concept identifiers (or expressions) are added as document metadata to the appropriate guideline or text within the guideline. For example, when applying semantic tags to asthma management guidelines, we might add the following concept identifiers, to enable the guideline to be linked to a patient's health record that includes a diagnosis of 195967001 | Asthma|, a regime of 406162001 | Asthma management|, or an assessment scale coded with 445531003 | Asthma control questionnaire| (respectively):
The diagram below depicts the process of tagging the SNOMED CT concepts mentioned above to an Asthma Management Guideline.
This tagged resource may then be presented as reference material when a relevant clinical scenario arises. For example, the guidelines shown in the image above could be presented upon the diagnosis of | Asthma|. Additional details on the mechanics of this process are provided below in the section below.
SNOMED CT Annotation Reference Sets can be used as a mechanism to define, share, and distribute links from SNOMED CT components to appropriate guidelines. This approach involves defining one or more links to relevant guidelines (using a URL) as a string based annotation for each relevant concept. An example of this is shown in the table below. In this example, the same clinical guideline is relevant to more than one SNOMED CT concept.
Table: Concepts which refer to NIH: Asthma Care Quick Reference guideline
Another example use case is linking a specific clinical field, such as a diagnosis, to an appropriate clinical guideline. Given the more specific scope, it may be possible to avoid repeating the same guideline for multiple SNOMED CT concepts referenced by the reference set. The table below, shows an example in which disorder concepts are linked to appropriate clinical guidelines.
Table: Respiratory diagnoses linked to relevant clinical guidelines
EHR systems, designed to use clinical guidelines marked up with semantic tags, are able to display relevant guidelines to the user when a subtype (or self) of the semantic tag concept is recorded in the health record.
Below is a generic template that could be used in an EHR system to facilitate the display of an appropriate clinical guideline, when a relevant diagnosis is recorded.
For example, the above template could be used on a clinical guideline that has the semantic tag 195967001 | Asthma|, generating the CDS rule:
IF diagnosis = << 195967001 | Asthma| THEN display NIH Asthma Care Quick Reference
Using the above CDS rule, if a clinician selects a diagnosis of 195949008 | Chronic asthmatic bronchitis|, the NIH Asthma Care Quick Reference would be displayed because 195949008 | Chronic asthmatic bronchitis| is a subtype of 195967001 | Asthma|.
This enables contextually relevant clinical knowledge to be presented to the user, based on the specific codes recorded in the patient's health record. The diagram below illustrates this scenario:
This section presents some examples of standards used to represent CDS guidelines. Please note that this list is not complete, and other standards and formalisms for representing clinical guidelines do exist.
The Guideline Interchange Format (GLIF) is a language for modeling and executing clinical practice guidelines. GLIF uses GELLO, and therefore can make use of SNOMED CT within its language. Users of GLIF have the option of viewing GLIF code in a interactive flowchart to represent guidelines and present pop-up information and instructions. The following screenshot presents the "UI view" of a query / guideline structured in GLIF. This example uses SNOMED CT to answer the questions in the decision shapes:
For more information about GLIF, please refer to .
The Guideline Definition Language (GDL) is a syntax designed to express clinical logic as rule inputs and outputs. Discrete rules can be combined together to support simple or complex decision making. The specification which accompanies the GDL describes its status as "trial." One of the goals of the GDL is to be able to share CDS artifacts across languages and technical platforms. GDL artifacts can be applied to point of care (POC) decision support and in population health analytics. The GDL uses reference and archetype models from openEHR and in doing so supports information model references that are language independent. For example, it is possible to add language translations without changing the logical definitions in the rule. It is also possible to bind locally defined terms in the guideline to a single concept, multiple concepts, or reference set in any reference terminology as the language considers a reference terminology to be an external resource.
For more information on the Guideline Definition Language, please refer to .
195967001 | Asthma (disorder)|
406162001 | Asthma management (regime/therapy)|
445531003 | Asthma control questionnaire (assessment scale)|
719999999107 | Guideline annotation reference set|
195967001 | Asthma (disorder)|
719999999107 | Guideline annotation reference set|
406162001 | Asthma management (regime/therapy)|
719999999107 | Guideline annotation reference set|
195967001 | Asthma|
719999999107 | Guideline annotation reference set|
32398004 | Bronchitis|
IF diagnosis = << [[ + $semanticTag]] THEN display clinical guideline
719999999107 | Guideline annotation reference set|
445531003 | Asthma control questionnaire (assessment scale)|
719999999107 | Guideline annotation reference set|
13645005 | Chronic obstructive lung disease|
