Clinical Practice Guidelines
3.0.0-ballot - STU 3 Ballot International flag

Clinical Practice Guidelines, published by HL7 International / Clinical Decision Support. This guide is not an authorized publication; it is the continuous build for version 3.0.0-ballot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/cqf-recommendations/ and changes regularly. See the Directory of published versions

Approach

This page was reorganized and editorially revised in this version of the guide (see FHIR-59639 in the change log).

The Approach section describes how guideline developers, knowledge engineers (and other informaticists), and implementers can work together across the lifecycle of a computable Clinical Practice Guideline (CPG). That lifecycle covers more than the guideline itself. It includes the activities that follow from it, such as clinical decision support, quality measurement, case reporting, and continuous improvement, all built on existing standards.

The approach has three parts:

  1. A conceptual knowledge architecture that names the key domain concepts in clinical guidance and separates them into distinct concerns (Case, Plan, and Workflow).
  2. A framework for describing knowledge artifacts: how formal they are (levels of representation), what they do (tiers of functionality), and how they are implemented and integrated.
  3. An agile, cross-functional development process in which guideline development, knowledge engineering, and implementation happen together and repeat, not one after another (see Figure 1.1).

This section is not a step-by-step guide to particular tools. It gives each contributor enough context to understand their role and how it connects to the others. It also explains the reasoning behind the Profiles and Conformance requirements in this guide. The Methodology page applies this approach in a concrete process (Select, Represent, Translate, Validate).

Where to Start

The CPG development team is cross-functional, and one person may hold several of these roles. Each path lists Approach pages in reading order, followed by where to apply them. The Conceptual Knowledge Architecture Index is a reference for every role.

If you are a… Read, in order Then apply
Guideline developer, clinical subject matter expert, or evidence methodologist Guideline Development → Development of Computable Clinical Guideline Artifacts → Separating and Defining Case, Plan, and Workflow → Plan → Metrics Select and Represent steps; L1 and L2 checklists
Knowledge engineer: acquisition and translation Knowledge Engineering Overview → Knowledge Acquisition → Knowledge Translation → Separating and Defining Case, Plan, and Workflow → Levels of Knowledge Representation → Agile CPG Development Approach Select and Represent steps; L2 checklist
Knowledge engineer: formal representation (logic, terminology, data modeling) Knowledge Architecture - Conceptual Perspective → Plan → Case → Care Plan → Activity Flow → Tiers of Functionality → Knowledge Assets Translate and Validate steps; Profiles; Terminology; L3 checklist
Knowledge architect or team lead Separations of Concerns → Knowledge Architecture → Agile CPG Development Approach → Levels of Enablement → Conformance Methodology, all steps
Metric or measure developer, or evaluator Guideline, Derivative, and Related Assets → Plan → Activity Flow → Knowledge Execution and Validation Metrics; Terminology; Profiles
Implementer (EHR, CDS service, or application developer) Implementing Computable Knowledge → Methods of Implementation → Activity Flow → Mechanisms of Integration → Levels of Enablement → Conformance Evidence-Based Care Planning; Interactive Clinical Decision Support; L4 checklist
Local informatics or practice governance Knowledge Implementation → Workflow and Common Pathway → Levels of Enablement → Mechanisms of Integration Common Care Pathway; L4 checklist

Conceptual Knowledge Architecture

This section describes how guideline concepts become computable knowledge artifacts. Its core idea is to keep three concerns apart:

  • Case: the patient's state at a point in time, meaning their clinical and physiological condition
  • Plan: what to do for a patient in that state, based on clinical decision-making
  • Workflow: how that care is delivered in a particular setting

Keeping these concerns apart lets each be expressed at the right level of detail, without mixing logic that belongs to different concerns or adding complexity that has no value. The separation is the basis for the CPG profiles, such as CPGCase, CPGPathwayDefinition, and CPGCarePlan.

Two ideas build on this separation and recur across this guide:

Guideline Development

This section describes how guidelines are developed: who takes part, and the processes, tools, and frameworks they use. It explains where a computable CPG fits in the evidence ecosystem and in a Learning Health System. It also covers the computable artifacts that express a guideline and the artifacts derived from it (for example, quality measures), along with their value to stakeholders.

Knowledge Engineering

This section describes the activities, techniques, and tools that knowledge engineers use to turn a guideline's narrative content into a faithful computable representation. That representation uses the conceptual knowledge architecture and the CPG profiles. The section also describes an agile approach to CPG development, in which an integrated, cross-functional team uses composite artifacts and test-driven techniques to produce high-quality artifacts quickly.

Knowledge Representation

This section describes the levels of representation a guideline passes through: narrative (L1), semi-structured (L2), structured and computable (L3), and executable in a real-world system (L4). It also describes the tiers of functionality (data, logic, and user interface) found at each level. Representations at the intermediate levels are useful work products in their own right. Clinical experts and knowledge engineers use them to check each other's understanding, and they give downstream implementers guidance. The section also covers knowledge assets, their metadata, and the architecture that defines how assets relate to one another.

Implementing Computable Knowledge

This section describes three ways to implement computable knowledge: as a specification that is built by hand, by automatic translation, or by native execution. It also describes how the resulting inferences can be integrated with clinical information systems, and how they can support guideline-informed workflows. The section closes with the levels of enablement and the conformance requirements for implementations of this guide.