FHIR Clinical Guidelines (v1.0.0) (STU1)

Clinical Practice Guidelines, published by Clinical Decision Support WG. This is not an authorized publication; it is the continuous build for version 1.0.0). This version is based on the current content of https://github.com/HL7/cqf-recommendations/ and changes regularly. See the Directory of published versions

4.0.0 Profile Definitions and Documentation

FHIR profiles are a key aspect of supporting interoperable computable content, providing a formal mechanism for defining the data elements used by computable content, as well as conformance expectations for the computable content itself. Readers of this implementation guide should be familiar with the Profiling FHIR topic in the base specification.

This page provides overview documentation for the following categories of profiles and documentation:

For indexes of profiles and extensions defined in this implementation guide, see the following:

4.1.0 Artifact profiles

For definitional artifacts, this implementation guide defines profile classes to represent knowledge capabilities for shareable, computable, publishable, and executable knowledge artifacts. All knowledge artifacts must be at least shareable, and where appropriate for the target environment, artifacts should declare the capabilities they support using the [cpg-knowledgeCapability](StructureDefinition-cpg-knowledgeCapability.html) extension, as well as the knowledge representation level of the artifact using the [cpg-knowledgeRepresentationLevel](StructureDefinition-cpg-knowledgeRepresentationLevel) extension, as defined in the shareable profiles.

  • Shareable: Shareable profiles set the minimum expectations for exchanging an artifact, including the URL, version, name, and publisher.
  • Computable: Computable profiles deal with authoring and design-time considerations, describing the minimum expectations for exchanging a machine-readable representation of an artifact. At a minimum, a computable artifact is one that does not have only human-readable content.
  • Publishable: Publishable profiles describe the expectations for publication and distribution of an artifact, typically as part of an artifact repository.
  • Executable: Executable profiles deal with run-time behavior and implementation considerations. For example, an executable library may contain compiled content that can be directly executed by an engine. At a minimum, an executable artifact is guaranteed to have all the elements required to support at least one operation appropriate to the type of artifact.

These capabilities are introduced to support separation of concerns along the spectrum from authoring to distribution to consumption, as illustrated by the following diagram:

Knowledge Capabilities

A given artifact may provide all knowledge capabilities (Shareable plus Computable, Publishable, and Executable), or it may be focused on a particular capability. For example, a ValueSet may be only Shareable and Executable because it is intended for use in environments without access to a terminology service capable of expanding the Computable value set.

Note that explicit profiles for capabilities are only defined when there are specific elements of the artifact involved in supporting that capability. For example, there is no executable ActivityDefinition profile, but that doesn't mean that ActivityDefinition artifacts cannot be executable, only that there are no additional conformance expectations for executable ActivityDefinitions specified by this implementation guide.


* - Conformance expectations covered by the Computable profile
** - Conformance expectations covered by the Shareable profile

4.2.0 Domain Profiles

Goaldefined in PlanDefinition.goalCPGGoal
Case SummaryCPGCaseSummaryDefinitionCPGCaseSummary
Case Plan SummaryCPGCasePlanSummaryDefinitionCPGCasePlanSummary
Case Plan Progressing NoteCPGCasePlanProgressingNote

Examples of the use of these profiles are available in the Examples page. In particular, see the Congestive Heart Failure Pathway example.

4.3.0 Activity Profiles

To represent the activities in a computable guideline, this implementation guide follows the workflow patterns established by the base FHIR specification, definition, request, and event. For each type of activity, these profiles establish at least:

  • Definitional activity profiles
    • kind - The type of request resource being defined
    • profile - The minimum profile that must be met by request resources produced by the activity definition
    • intent - The target intent, typically proposal, of the request resources
  • Request activity profiles
    • source reference - Typically the instantiatesCanonical element to refer back to the guideline content
    • identity - Typically via an identifier element to establish identity of the activity
  • Event activity profiles
    • source reference - Typically the instantiatesCanonical element to refer back to the guideline content
    • request reference - Typically the basedOn element to refer back to the request which the event is fulfilling
    • identity - Typically via an identifier element to establish identity of the activity

Note that the intent of these profiles is not to establish the content of the activity, only to ensure that requests and events related to guideline-based care can be traced back to the recommendation, strategy, pathway, and ultimately guideline they are representing.

Send a messageCPGCommunicationActivityCPGCommunicationRequestCPGCommunication
Collect informationCPGCollectInformationActivityCPGQuestionnaireTaskCPGQuestionnaireResponse
Order a medicationCPGMedicationRequestActivityCPGMedicationRequestCPGMedicationDispense
Dispense a medicationCPGDispenseMedicationActivityCPGDispenseMedicationTaskCPGMedicationDispense
Administer a medicationCPGAdministerMedicationActivityCPGAdministerMedicationTaskCPGMedicationAdministration
Document a medicationCPGDocumentMedicationActivityCPGDocumentMedicationTaskCPGMedicationStatement
Recommend an immunizationCPGImmunizationActivityCPGImmunizationRecommendationCPGImmunization
Order a serviceCPGServiceRequestActivityCPGServiceRequestCPGProcedure
Enroll a patientCPGEnrollmentActivityCPGEnrollmentTaskCPGCase
Generate a reportCPGGenerateReportActivityCPGGenerateReportTaskCPGMetricReport
Propose a diagnosisCPGProposeDiagnosisActivityCPGProposeDiagnosisTaskCPGCondition
Record a detected issueCPGRecordDetectedIssueActivityCPGRecordDetectedIssueTaskCPGDetectedIssue
Record an inferenceCPGRecordInferenceActivityCPGRecordInferenceTaskCPGObservation
Report a flagCPGReportFlagActivityCPGReportFlagTaskCPGFlag

See the Activity Examples for a complete example of each of the above activity types.

4.4.0 Content Profiles

In addition to the profiles defined by this implementation guide, computable content generally deals with two broad categories of profiles:

  • Interoperability Profiles that establish standards of data exchange between systems
  • Computability Profiles that define the data expectations for computable content

4.4.1 Interoperability Profiles

Interoperability profiles establish standards of data exchange between systems, and are typically defined in and distributed as part of model implementation guides. To be useful, these profiles will generally be established across a broad range of systems, all operating in a particular environment, or in support of a particular set of use cases. Examples of these types of profiles are:

4.4.2 Computability Profiles

Computability profiles describe the data expectations for computable content, and are typically defined in and distributed as part of content implementation guides. For example, given the following condition:

define "Active Ambulatory Opioid Rx":
  [MedicationRequest: "Ambulatory Abuse Potential Opioids"] Rx
    where Rx.status = 'active'
		  and Rx.category contains "Outpatient"

In this example, the condition is referencing the status and category elements of the MedicationRequest resource. In order for this logic to be evaluated effectively, the system providing the MedicationRequest instance must understand these two elements and provide data for them if it is available. Computability profiles are used to communicate this information through FHIR profiles.

Note that for logic expressed in CQL, this information can be inferred by static analysis of the CQL expressions and is exposed statically in the dataRequirement element of the Library resource. In addition, the $data-requirements operation can be used to extract this information from a CQL Library dynamically.

4.4.3 Implementation Considerations

Content conforming to this IG SHOULD select a set of base interoperability profiles appropriate for the intended target. For international usage, implementation guides conforming to this IG SHOULD use International Patient Summary.

In general, implementation of any given computable content is based on the intersection of the interoperability and computability profiles. As such, content authors must take care not to define computability profiles that conflict with interoperability profiles in their intended target scope.