Approach

The approach taken by this implementation guide is to consider three broad aspects of the problem of clinical guideline implementation:

1. Levels of knowledge representation
2. Tiers of functionality
3. Methods of implementation

Levels of Knowledge Representation

This implementation guide utilizes an established clinical decision support (CDS) implementation model to move from a clinical guideline to computable content¹. This model defines four (4) levels of knowledge representation:

Figure 2.1

Narrative

Level 1 (L1) is the clinical guideline, generally a narrative, often in Portable Document Format (PDF), and includes:

• Clinical Focus
• Scope
• Setting(s)
• Recommendations
• Who / what is included (inclusions)
• Who / what is excluded (exclusions)
• Policy considerations (e.g. privacy, access, regulations)

For example, one such guideline is the Guideline for Prescribing Opioids for Chronic Pain (2016) published by the Centers for Disease Control (CDC).

Semi-structured

Level 2 (L2) is semi-structured, and generally consists of process and workflow diagrams, user stories, and personas that provide contextual and descriptive information about the steps involved in each recommendation of the guideline. This level generally includes:

• Personas - Who are the actors involved
• Concepts - What are the concepts involved
• User Stories - Functional descriptions of what happens from the perspective of each persona
• Processes - Diagrams depicting the processes involved
• Triggers - When do the processes happen (what are the entry points for the processes)

The examples included in this implementation guide illustrate some of the types of content and approaches that can be used for this level.

Structured

Level 3 (L3) is a computable representation of the content in the guideline and can be shared across health systems and implementation settings. This level is the primary focus of this implementation guide, and generally consists of:

• Complete value sets specified using standard terminologies
• Data element definitions describing the information involved
• Computable logic describing at least the inclusion/exclusion criteria
• Structured recommendations in the form of event-condition-action rules
• Structured process definitions describing how the recommendations fit into a clinical workflow
• Structured form definitions providing a conceptual description of the user-interfaces involved

Executable

Level 4 (L4) is executable software running in a clinical system. This is the local implementation and generally involves:

• Mapping of terms (value sets) to local terms
• Adjustment of workflow for site-specific factors
• Interpretation of computable content in the site-specific environment

Tiers of Functionality

This implementation guide defines three (3) tiers of functionality, very roughly analogous to the tiers of architecture in software engineering:

Figure 2.2

To illustrate these tiers of functionality, consider the following excerpt from a recommendation statement in the CDC Opioid Prescribing Guideline:

When prescribing opioids for chronic pain, providers should use urine drug testing before starting opioid therapy

The data elements in this recommendation statement are the concepts involved, such as medication prescriptions, opioids, chronic pain, urine drug testing, and opioid therapy.

The clinical logic then describes the behaviors in terms of the data elements, such as when prescribing opioids for chronic pain, and use urine drug testing before starting opioid therapy.

And finally, the forms descriptions are the user interfaces involved in the implementation of the recommendation such as an order entry form.

Note carefully that these tiers each have different manifestations at different knowledge levels. At L3, these tiers are formal, but still conceptual representations of the content, whereas at L4, these tiers are concretely implemented in software systems. For example, a form at L3 is intentionally silent on the actual presentation layer details, whereas a form at L4 necessarily includes them.

Data Elements

The Data Elements provide a computable representation of the concepts and information involved in the clinical guideline. The artifacts at this level are represented in FHIR using the following resources:

• StructureDefinition - Specifically, profiles and extensions
• CodeSystem
• ValueSet

Expressing the data elements in a clinical guideline enables the description and exchange of the data involved in the guideline; roughly, the data tier in a traditional 3-tier architecture.

Clinical Logic

The Clinical Logic in a computable guideline provides a formal representation of the behavior involved in the recommendation statements in terms of the Data Elements. This includes items such as inclusion/exclusion criteria, calculations such as risk scores, public health indicators, or average daily dosage, as well as rules that describe how and when a recommendation applies such as event-condition-action rules. The artifacts at this level are represented in FHIR using the following resources:

• Library
• ActivityDefinition
• PlanDefinition
• Measure

Expressing the clinical logic for a guideline enables application functionality; roughly, the application tier in a traditional 3-tier architecture.

Forms Description

The Forms Description in a computable guideline describes user interactions and uses both the Data Elements and Clinical Logic. The artifacts at this level are represented in FHIR using the following resources:

• Questionnaire
• PlanDefinition

Expressing the forms description for a guideline provides a more complete description of the recommendations in a guideline; roughly, the presentation tier in a traditional 3-tier architecture. This level involves specifying a conceptual description of the processes involved, as well as the user-interfaces that capture the user’s interactions with the system.

Methods of Implementation

With these computable artifacts, there are three (3) methods of implementation that broadly describe different approaches to moving from the computable representation (L3) of guideline content to the executable representation (L4):

Figure 2.3

Note that there are numerous factors that must be considered as part of the local implementation of guideline content. The intent of the L3 artifacts that are the focus of this implementation guide is to ensure that these factors can be appropriately considered and addressed as part of implementation, while still providing useful content that can accelerate the process.

Manual

Manual implementation involves development of clinical guideline functionality using the computable (L3) content as a set of rigorously specified requirements for the implementation. In the absence of computable (L3) content, this is the only method.

Automatic

Automatic implementation involves programmatic translation of the L3 content into an appropriate L4 format. For example, a CQL query may be translated into an equivalent SQL query for execution, or a PlanDefinition may be transformed into a production rule. This approach involves potentially significant effort to build the appropriate tooling, but can pay dividends at scale once the tooling is in place.

Native

Native implementation involves direct execution of L3 content. For example, a CQL query may be run directly on a native CQL engine. As with the automatic approach, this approach may involve significant initial tooling effort, but can dramatically reduce implementation time thereafter. In addition, there are open source reference implementations that support the use of the FHIR Clinical Reasoning module resources. In particular:

• CQL Engine - A java-based native engine for Clinical Quality Language
• HAPI FHIR - A java-based reference implementation of a FHIR Server and Client
• CQF Ruler - A java-based plug-in for the HAPI FHIR server that enables Clinical Reasoning use cases

References