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

Conformance

Conformance from the perspective of this Implementation Guide (IG) refers to statements that prescribe expected characteristics and behaviors of systems involved in the authoring, testing, validation, distribution, integration, and delivery of the knowledge artifacts and associated documentation that make up a computable Clinical Practice Guideline (CPG). As described in the Content Implementation Guides section of this IG, a FHIR-based CPG is delivered as a FHIR Implementation Guide, and therefore follows the rules for establishing conformance requirements as defined by the FHIR specification.

This page explains how conformance requirements are expressed in this implementation guide, and lists all of the conformance statements it makes.

Clinical Safety

This specification defines profiles, terminologies, patterns, and guidance for describing guideline-directed care. As such, Clinical Safety is a key concern with regard to any content developed conformant with this implementation guide. As with any healthcare-related endeavor, content authors and implementers are strongly encouraged to keep patient safety, privacy, and security as a central focus. To aid with this focus, content authors and implementers are strongly encouraged to use the FHIR Implementer's Safety Check List to help inform development and implementation of computable guidelines.

Conformance Language

This implementation guide follows the same conformance language specified by the base FHIR specification:

This specification uses the conformance verbs SHALL, SHOULD, and MAY as defined in RFC 2119. Unlike RFC 2119, however, this specification allows that different applications might not be able to interoperate because of how they use optional features. In particular:

  1. SHALL: an absolute requirement for all implementations
  2. SHALL NOT: an absolute prohibition against inclusion for all implementations
  3. SHOULD/SHOULD NOT: a best practice or recommendation to be considered by implementers within the context of their particular implementation; there may be valid reasons to ignore an item, but the full implications must be understood and carefully weighed before choosing a different course
  4. MAY: truly optional language for an implementation; can be included or omitted as the implementer decides with no implications

Conformance Targets

Conformance statements in this implementation guide apply to one of two kinds of target:

  • Content: the knowledge artifacts and documentation of a computable guideline, typically published as a content implementation guide. Most of the statements in this implementation guide apply to content.
  • Systems: the systems that store, evaluate, and act on that content. This implementation guide defines three actors for these systems, the CPG Knowledge Repository, the CPG Service, and the CPG Client. See the Actors page for how these actors work together at each level of enablement.

Statements that apply to a particular system list that actor in the table below. Statements that apply to content list no actor.

Must Support

Profiles in this implementation guide use the must support flag to indicate that the elements play a meaningful role in the description of an artifact (for artifact profiles), or that the element is relevant for effective support of an expected behavior (for domain profiles). Note carefully that must support does not indicate a required element, that aspect is governed by the cardinality of the element; but it does indicate that systems involved in exchanging knowledge artifacts, or implementation systems involved in exchanging data during implementation of knowledge artifacts, must understand the element and be able to provide meaningful data if and when it is available.

Because FHIR-based CPGs are themselves FHIR implementation guides, content implementation guides SHALL include a statement describing how the must support flag is to be interpreted for effective use of their content, and that statement SHALL be consistent with the general characterization of must support behavior described here.§conf-1 Examples of must support declarations can be found in:

Use of CRMI

The knowledge artifacts of a computable guideline are canonical resources, and the Canonical Resource Management Infrastructure (CRMI) implementation guide defines profiles and capabilities for managing them. This implementation guide deliberately does not take a dependency on CRMI, so conformance to the CRMI profiles is not required. However, conformance to the CRMI Shareable profiles, and to the Computable, Publishable, and Executable profiles where they apply, is strongly recommended, and the statements below that refer to CRMI profiles use SHOULD for this reason. Content that does not conform to these profiles needs to understand and document the implications for sharing and managing that content.

Use of CQL

This implementation guide does not require that content use Clinical Quality Language (CQL), and so does not take a dependency on the Using CQL With FHIR implementation guide. However, content that does use CQL is required to conform to the Using CQL With FHIR implementation guide. This is a stronger expectation than the use of CRMI: the statements on the Libraries page that refer to the Using CQL With FHIR profiles use SHALL, and apply only to content that uses CQL.

Packaging and Distribution

Content implementation guides SHALL provide documentation describing the expected packaging and distribution targets for their knowledge artifacts, terminology, and logic.§conf-2 See the Packaging topic in the methodology for background.

Case Features and Data

Content implementation guides SHOULD provide case features describing the minimum data set appropriate for their content.§conf-3 See Translate Step: Profiles for how case features are defined.

Summary of Requirements by Topic

The following pages establish the detailed conformance requirements for each topic. Each of these statements is also listed in the table below.

  • Profiles: Knowledge artifacts and the selection of interoperability profiles. Statements prof-1 through prof-3.
  • Terminology: Code systems and value sets defined by content. Statements term-1 through term-9.
  • Libraries: Libraries of computable logic. Statements lib-1 and lib-2.
  • Methodology: Representation of recommendations, strategies, pathways, case features, and activities. Statements rec-1 through rec-7, data-1, and act-1 and act-2.
  • Workflow and Common Pathway: Case reporting and the identification of common processes. Statements path-1 and path-2.

Conformance Statements

This section contains a table listing all the free-text conformance statements found in this implementation guide. This table is provided as a useful summary for implementers for the purpose of evaluating key features and to support testing. However, reading this table alone is insufficient to understand or successfully implement the specification:

  1. The table only includes conformance expectations expressed as free text. It does not include the computable expectations represented in capability statements, profiles, value sets, etc.
  2. The text in the table only includes the 'formal' requirement. It does not provide the contextual language around the statement that will be needed for successful explanation. The 'id' of each statement is a hyperlink to the place it appears in the text to assist with gathering the needed context.

A few other notes:

  • The ids are generally specific to the pages on which the requirements appear, but not always. If content is moved from one page to another, the id will remain the same.
  • While ids start as contiguous, as the specification is updated, it is possible some conformance statements will be removed, which will create a gap in the numbers. This is not an error.
  • Ids are not final until published in an official release. After that point, ids will not be changed.
  • It is possible for the text of a given rule to change somewhat from one release to another so long as the intention of the rule is the same. If the intent has a significant change, the old rule will be removed and a new one added in its place (with a new id).
  • Categories are drawn from the CPG Conformance Category code system. They are provided as a general aid to filtering, and are not a definitive classification.
IdExpectationConditional?CategoriesRule
 SHOULD
 SHALL		 Yes
 No
 Any		 Activity
 Data
 Documentation
 Knowledge Artifact
 Logic
 Recommendation
 Terminology
§act-1SHALL ActivityContent conforming to this implementation guide SHALL use one of the recommendation instance profiles described above to ensure supporting information related to the recommendation is preserved through the recommendation instance.
§act-2SHALL ActivityContent conforming to this implementation guide SHALL use the event profiles defined above to ensure guideline supporting and tracking information is available for activities delivered in the context of a computable guideline.
§conf-1SHALL DocumentationBecause FHIR-based CPGs are themselves FHIR implementation guides, content implementation guides SHALL include a statement describing how the must support flag is to be interpreted for effective use of their content, and that statement SHALL be consistent with the general characterization of must support behavior described here.
§conf-2SHALL DocumentationContent implementation guides SHALL provide documentation describing the expected packaging and distribution targets for their knowledge artifacts, terminology, and logic.
§conf-3SHOULD DataContent implementation guides SHOULD provide case features describing the minimum data set appropriate for their content.
§data-1SHOULD DataContent conforming to this implementation guide SHOULD use the CPG Event Activity Profiles as the basis for case feature definitions.
§lib-1SHALLXLogicContent that uses CQL SHALL use CQLLibrary (for Computable content), ELMLibrary (for Executable content), and CQLModule (to provide structured representation of dependencies and data requirements)
§lib-2SHALLXLogicContent that uses CQL SHALL use CQLModelInfo for model information
§path-1SHOULD DataThis approach SHOULD be aligned with the eCaseReporting implementation guide.
§path-2SHALL RecommendationContent conforming to this implementation guide SHALL identify processes using the Common Processes code system.
§prof-1SHOULD Knowledge Artifact

Knowledge artifacts of the listed types SHOULD conform to the CRMI Shareable profile, and SHOULD conform to the CRMI Publishable profile

§prof-2SHOULD DataContent conforming to this IG SHOULD select a set of base interoperability profiles appropriate for the intended target.
§prof-3SHOULDXDataFor international usage, implementation guides conforming to this IG SHOULD use International Patient Summary.
§rec-1SHALL RecommendationContent conforming to this implementation guide SHALL provide references to supporting documentation for a recommendation in the form of a relatedArtifact element specifying a citation to the guideline.
§rec-2SHALL Recommendation
Documentation		content conforming to this implementation guide SHALL identify a rating system and use that to provide rating information for recommendations and guidance, and provide documentation on what rating system was selected and how it is communicated through the content.
§rec-3SHALL RecommendationContent conforming to this implementation guide SHALL provide the strength of a recommendation using the strengthOfRecommendation extension.
§rec-4SHALL RecommendationContent conforming to this implementation guide SHALL provide the quality of evidence for a recommendation using the qualityOfEvidence extension.
§rec-5SHALL RecommendationContent conforming to this implementation guide SHALL use the cpg-recommendationdefinition profile to represent recommendation definitions.
§rec-6SHALL RecommendationContent conforming to this implementation guide SHALL use the cpg-strategydefinition profile to represent strategy definitions.
§rec-7SHALL RecommendationContent conforming to this implementation guide SHALL use the cpg-pathwaydefinition profile to represent pathway definitions.
§term-1SHOULD TerminologyCode systems defined by content conforming to this IG SHOULD conform to the CRMIShareableCodeSystem profile, and SHOULD conform to the CRMIPublishableCodeSystem profile if the artifact status is active.
§term-2SHOULD TerminologyWhenever possible, value sets SHOULD be defined by crafting one or more inclusion and exclusion criteria that use code system properties, attributes, and relationships.
§term-3SHOULDXTerminologyFor these cases, the description of the construction of the value set SHOULD be represented with non-FHIR expressions using a computable expression in some terminology grammar.
§term-4SHOULD TerminologyValue sets defined by content conforming to this IG SHOULD use the CRMIComputableValueSet profile to define value set member content in one of three ways.
§term-5SHOULD TerminologyBefore and periodically during production use, value set expansions SHOULD be updated.
§term-6SHALL Terminology
Documentation		Content implementation guides that include executable value sets SHALL document the expected maintenance path for those value sets.
§term-7SHOULD TerminologyValue sets defined by content conforming to this IG SHOULD include an expansion element with a timestamp and enough information to determine whether the computed expansion is current, or needs to be updated.
§term-8SHOULD TerminologyThe parameters element SHOULD be used to convey information about the parameters used to expand the value set.
§term-9SHOULD Terminology

Value sets defined by content conforming to this IG SHOULD conform to the CRMI Shareable, Computable or Expanded, and (if active) Publishable value set profiles

Levels of Conformance

One major effort on compliance is the WHO and Integrated Health Enterprise (IHE) initiative on Computable Care Guidelines (CCG)1 profile of the HL7 CPG.2 The IHE/WHO CCG includes a minimum data set to be collected during an encounter (i.e., required data elements as CPGCaseFeatures), logic to be triggered based on data collected (CPGRecommendations), and reportable health system management indicators (CPGMetrics). It can track and monitor care delivery activities (e.g., what happened) as well as provide the ability to improve guideline adherence.

Conformance Testing

Levels of conformance will be based on alternative conformance profiles such as the CCG above, and on the actors and levels of enablement described on the Actors page. Conformance with Features of the CPG are still under development.

NOTE: This project is actively seeking feedback on how to characterize levels of enablement as capabilities, and how to support declaration and validation of conformance to these capabilities.

1: https://wiki.ihe.net/index.php/Computable_Care_Guidelines Computable Care Guidelines (CCG) profile

2: 'http://www.ihe.ca/download/ambassador_headache_final_100_pager.pdf'