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
This page was reorganized and editorially revised in this version of the guide (see FHIR-59639 in the change log).
The conceptual knowledge architecture for the CPG describes how the concepts from a guideline and its recommendations described in Guideline Development are realized as computable knowledge assets. The CPG knowledge architecture provides the framework through which the knowledge engineering team realizes the guideline, its recommendations, and their various features through explicit formalisms and ultimately as information. The CPG conceptual knowledge architecture together with the implementation instructions and examples in the Methodology section provide the means to develop and concretize a CPG representation that can be consumed through various mechanisms in end-user workflows.
This section covers:
Figure 1. The CPG Pathway Definition that contains all the CPG-specific knowledge content and assets including the Recommendations (and Strategies); The Case that scopes all the required data elements (Case Features) including many of the patient-specific inferences thereon (inferred Case Features); and the CPGCarePlan that includes the patient-specific recommendations (Proposals) and any resulting or relevant orders, prescriptions, scheduling (Requests) and the data elements representing the events that fulfill these requests (a subset of the Case Features)

Separation of concerns is a design principle that gives distinct, focused attention to each aspect of a domain. In healthcare, a critical axis of separation is by kind of process:
The CPG knowledge architecture is designed to respect these separations. See Separations of Concerns for other axes of separation (for example, by condition, intervention, or care setting), and Separating and Defining Case, Plan, and Workflow for the definitions and the boundary issues between them.
Figure 2. Illustrating the separation of the Case (patient clinicopathophysiological processes and their manifestations and qualifications thereof), the Plan (the approach to the patient’s current, historical, and potential future state of disease and well-being including medical decision-making), and the Workflow (how the Plan is implemented either through interactions with clinical information systems or through real-world human tasks and activities).

The Plan describes how a class of patients should be managed given a set of clinical parameters, constrained to the interventions scoped by the guideline's recommendations. It is definitional and consists of Recommendations, Strategies that coordinate related recommendations, and a Pathway that coordinates strategies and recommendations across the whole guideline. If logic describes what to do for a patient, it very likely belongs in the Plan. A Recommendation's activity is the Definition phase of the Activity Flow. See Plan.
The Case is the information that describes an individual patient's current and historical state of health, disease, and risks: patient descriptors, exposures, assessments, clinical presentation and progression, diagnostic findings, diagnoses, risk and severity scores, and outcomes. These descriptors are referred to as Case Features, which may be recorded directly or inferred. See Case.
The Care Plan is the Plan applied to an individual Case. It contains the patient-specific recommendations (Proposals), the Requests that correspond to them, and the Events that fulfill those Requests, scoped to a specific CPG. These are the patient-specific phases of the Activity Flow. See Care Plan.
This implementation guide does not specify local workflows. Instead it uses a "common pathway" (an abstraction of high-level clinical workflow), shared information (Case Features), and the standard FHIR request, event, and task patterns to connect guideline content to clinical information systems. See Workflow and Common Pathway. See also the Activity Flow, which carries an activity from definition to event in parallel with the EHR's own order lifecycle.
All of the knowledge assets produced by CPG development are packaged in a guideline container asset. Because the CPG formally expresses the intent of the guideline, other assets that have historically been developed by hand from the narrative (such as metrics, measures, case summaries, and case reports) can be derived from or related to it. See Guideline, Derivative, and Related Assets.
The Conceptual Knowledge Architecture Index lists each concept used in these pages, such as Recommendation, Case Feature, and Proposal. For each one it links to where the concept is defined and shows how it is represented by the profiles in this implementation guide.