Rules
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 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:
A clinician is prescribing a drug to a patient
A nursing supervisor is reviewing a list of patients previously diagnosed with cancer
A clinician is assessing a patient enrolled in a jurisdictional diabetes monitoring program
Condition
A CDS condition defines the question(s) that must be answered to determine the outcome of the rule. Examples of conditions include:
Does the usual drug of choice for this patient's condition contain a substance to which the patient is allergic?
Have any patients with a suspected cancer diagnosis NOT been referred to a specialist within 14 days of diagnosis?
Has the patient with a previous diagnosis of diabetes type II NOT had HBA1C tested within the last 12 months?
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 Inference Engine.
Context in CDS Rules
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.
When evaluating the condition within a CDS rule it is important to take account of context.
For example, a rule that requires a current diagnosis of diabetes should not trigger an action in response to a record that states that a patient has a family history of diabetes.
Representing Context in a Health Record
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:
281666001 |Family history of disorder|:
246090004 |Associated finding|= 73211009 |Diabetes mellitus|
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.
Postcoordinated as a SNOMED CT expression that includes a concept representing a family history of disorder and specifies the diabetes mellitus as the disorder.
A context specific family history section in the record structure
Family History Record Section
A separate field in the record structure to indicate the context of the disorder recorded
False Positives and False Negatives
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).
False Positive Example
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.
False Negative Example
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.
Default Context
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
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).
Data Entry with Context
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.
Defining Context in Rules
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.)
Rule Components and Criteria
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.
Multi-Component CDS Rules
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.
Criteria in CDS Conditions
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
Drug prescribed
Hematocrit result
Criteria Values
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
Diagnosis
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
Birth date
Date
>=
1990/01/01
n/a
Rule Examples
In this section we present a number of examples of CDS rules, using the 'ON event IF condition THEN action' pattern.
Asthma Diagnosis
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.
Medication Order
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.
Emergency Department
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.
Standards for CDS Rules
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.
Expression Constraint Language
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.
Arden Syntax
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.
. 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.
FHIR CDS Resource
is a general FHIR resource which can be used to represent a range of CDS artifacts such as rules, order sets, and protocols. . 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. " 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.
Last updated