Computable Care Guidelines
1.0.1-current - ci-build International flag

Computable Care Guidelines, published by IHE QRPH Technical Committee. This guide is not an authorized publication; it is the continuous build for version 1.0.1-current built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/IHE/QRPH.CCG/ and changes regularly. See the Directory of published versions

Content Specifications

Volume 3 (this volume) defines the base content model for the CCG Profile. All CCG actors SHALL declare the contextual content model to which they adhere. It may be the one defined in this Volume 3 or an alternate model defined in Volume 4. For clarity, normative statements in this Volume 3 apply to CCG actors that claim conformance to this base content model.

The content specifications in the IHE CCG Profile can be broadly categorized as being related to either the definition of CCGs or as being related to the transactional data needed to invoke and process CCGs.

Definitional Content

Figure 18 – Illustration of the Definitional Content for CCGs


The transactions [QRPH-62] and [QRPH-63] convey CCG Package content - it is the payload of the response of the former and of the input in the latter. Each CCG Package is a FHIR ImplementationGuide. To simplify discoverability of CCGs on a Guideline Registry (using transaction [QRPH-61]), the CCG_Deployment_Package specification normatively constraints the HL7 CPGComputableGuideline1 specification on which it is based.

Each CCG Package contains a single CCG Folder. The CCG Folder is a PlanDefinition of type clinical-protocol that adheres to the CCG_CARD_Folder specification. This specification normatively constrains the CPGComputablePlanDefinition2 specification on which it is based.

As per the Folders & CARDs Metaphor, the CCG Folder references one or more CCG CARDs. Each CARD is used to describe a recommended evidence-based activity. The thirteen types of evidence-based activities are defined by the CCG_Card_Type value set. Every CARD is comprised of one PlanDefinition (of type eca-rule) that refers to one of thirteen types of ActivityDefinition resources. Using the CARD acronym, the Condition statement(s) are defined using the PlanDefinition and the Action and Resulting Data are defined by the ActivityDefintion.

A CQL Library may be used to define complicated Condition statements; if this the case, the Library must adhere to the CCG_CARD_Library specification. Also, if supported as an Option by the relevant actors, Folder and/or CARDs and/or libraries may be digitally signed. Where this is the case, digital signing is effected using a Provenance resource that adheres to the CCG_Signature specification.

Originally launched in 2019, the IHE CCG Profile is the result of a joint HL7-IHE Gemini Project3. Including as noted above, relevant underlying specifications of the HL7 CPG-on-FHIR IG4 are constrained and profiled by this IHE CCG Profile.

List of Key Definitional Content Specifications

The collection of key specifications related to CCG Definitional content is listed below. These, along with supporting underlying specs, are listed in full on the Artifacts page.

Content:    
CCG Package CCG_Deployment_Package Implementation Guide
CCG Folder CCG_CARD_Folder PlanDefinition
CCG Patient Plans CCG_Patient_Plans PlanDefinition
Library CCG_CARD_Library Library
Digital Signature CCG_Signature Provenance
CARD types: PlanDefinition ActivityDefinition
Provide Information CCG_Provide_Information CCG_Provide_Info_Activity
Collect Information CCG_Collect_Information CCG_Collect_Info_Activity
Lab Order CCG_Request_Service_Lab_Order CCG_Request_Service_Labs_Activity
Radiology Order CCG_Request_Service_Radiology CCG_Request_Service_Rad_Activity
Procedure Order CCG_Request_Service_Procedure CCG_Request_Service_Procedure_Activity
Referral CCG_Request_Service_Referral CCG_Request_Service_Referral_Activity
Propose Diagnosis CCG_Propose_Diagnosis CCG_Propose_Diagnosis_Activity
Order Medication CCG_Order_Medication CCG_Order_Medication_Activity
Dispense Medication CCG_Dispense_Medication CCG_Dispense_Medication_Activity
Administer Medication CCG_Administer_Medication CCG_Administer_Medication_Activity
Request Immunization CCG_Request_Immunization CCG_Request_Immunization_Activity
Stop Medication Order CCG_Stop_Activity_Medication_Order CCG_Stop_Activity_Medication_Order_Activity
Stop Service Order CCG_Stop_Activity_Service_Order CCG_Stop_Activity_Service_Order_Activity

Transactional Content

Figure 19 - Illustration of Transactional Data Flow During a CCG-informed Care Encounter


During a CCG-informed care encounter, the Guideline Performer and Guideline Engine Actors will engage in an iterative data exchange operationalized by repeatedly invoking transaction [QRPH-64] and dispositioning the transaction results. This process, and the content that drives it, is illustrated in the figure above.

  1. The Guideline Performer prepares the initial contextual content bundle.

  2. The initial contextual content bundle is submitted to the Guideline Engine as one of the inputs to the [QRPH-64] transaction.

  3. A RequestGroup is returned by the Guideline Engine; this RequestGroup contains the evidence-based Actions that are recommended for the patient, based on the contextual content.

  4. The Guideline Performer processes the set of recommended Actions; this processing generates a normative Resulting Data output for each Action. The details of this processing are out of scope.

  5. The set of Resulting Data are included in the contextual content bundle submitted as an input to the next iterative invocation of the [QRPH-64] transaction.

  6. Based on this uPlanDefinitionated Data-in bundle, a RequestGroup is returned by the Guideline Engine containing zero or more recommended Actions.

  7. As in step 4, the Guideline Performer dispositions the recommended Actions to normatively generate Resulting Data. If the RequestGroup returned by the [QRPH-64] transaction is empty, the processing loop ends and the set of Resulting Data is persisted as part of the patient’s uPlanDefinitionated health record. NOTE: if an empty RequestGroup is returned by transaction [QRPH-64] at step 4, the processing loop ends at this step.

Contextual Content (Data-in) Bundle

This content model defines the data input (“data-in”) bundle5 that is passed as part of the Apply Guideline transaction submission. This bundle represents the content that will be used by the Guideline Engine to evaluate all relevant CCG CARD’s condition statements during the $apply operation.

The data-in bundle SHALL contain:

  • the relevant Encounter resource for the current patient encounter,

  • the relevant Practitioner resource, if applicable,

  • the relevant PractitionerRole resource, if applicable,

  • the relevant Location resource, if applicable,

  • the relevant Organization resource, if applicable,

  • the patient’s health summary document, which SHALL include all content defined in the CCG IPS composition model and available to the Guideline Performer, and which SHALL reference the top-level Folder that lists the patient’s applicable CCG(s) in the CCG Patient Plans resource referenced in the CCG IPS CarePlan resource,

  • the set of normative Resulting Data generated by the Guideline Performer after processing prior invocations of the [QRPH-64] transaction. At the first invocation of [QRPH-64], this content will be zero.

Note: UC-3 describes how one or more CCGs may be associated with the patient and referenced in the patient’s top-level Folder using transactions defined by the IHE Dynamic Care Planning (DCP)6 Profile.

Normative Action and Resulting Data Formats

The details of how the Guideline Performer processes each recommended Action are not specified by this IHE CCG Profile. The Resulting Data for each CARD; however, is normatively defined. For clarity, this means that the Guideline Performer SHALL ensure that necessary post-processing is completed, based on the request resources returned in the [QRPH-64] transaction response, such that the normative Resulting Data is generated and may be included in subsequent invocations of [QRPH-64].

Provide Information CARD

The role of this type of CCG CARD is to provide information, counseling, or instructions to the patient.

The recommended Action from this CARD SHALL be a CommunicationRequest resource based on the CPGCommunicationRequest7 profile.

After processing the Apply Guidelines transaction response, the Resulting Data from this CARD SHALL be a Communication resource based on the CPGCommunication8 profile with either status=completed or status=not-done (with statusReason). The Communication resource SHALL reference the Encounter.

Collect Information CARD

The role of this type of CCG CARD is to collect information about the patient. There SHALL be one Collect Information CARD for each data element needed to drive the evidence-based care workflow (e.g., current blood pressure, weight, spirometry, etc.). The CARD’s condition statement(s) will evaluate true if this information is missing from the Contextual Content bundle and the processing of the CARD SHOULD “fill in” this missing information using Structured Data Capture based on the Definition-based extraction method.9

The recommended Action from this CARD SHALL be a Task resource based on the CPGQuestionnaireTask10 profile.

The following constraints SHALL apply to the Questionnaire resource referenced in the Task:

  • the scope of the Questionnaire will be limited to a single data element (e.g., blood pressure, weight, spirmetry measure, etc.) and the relevant target FHIR resource content will be identified Questionnaire.item.defintion

  • the content type (e.g., LOINC code for observation) and relevant units of measure SHALL be defined by the Questionnaire such that the content is persisted in a format consistent with the evidence-based workflow logic defined for this CCG. To be clear, other CARDs' Condition statements may rely on this content for their evaluation.

It is the responsibility of the Guideline Performer to operationalize data collection as defined by the Questionnaire. After processing is completed, the Resulting Data from this CARD SHALL be a FHIR resource based on the semantic definition expressed in the Questionnaire. The resulting resource SHALL reference the Encounter.

Note: in this first version of the CCG Profile, Observation resources based on the CPGObservation11 profile SHALL be exclusively supported with either status=final or status=cancelled (with dataAbsentReason).

Request a Service (Lab Order) CARD

The role of this type of CCG CARD is to create a laboratory / pathology ServiceRequest for the patient.

The Action recommendation from this CARD SHALL be a ServiceRequest resource based on the CPGServiceRequest12 profile.

After processing the Apply Guidelines transaction response, the Resulting Data from this CARD SHALL be a Lab Order ServiceRequest resource based on the CPGServiceRequest profile with either status=draft or status=revoked (indicating not done). The ServiceRequest resource SHALL reference the Encounter.

Note: active Lab Order ServiceRequest resources SHALL be included as a CarePlan.activity.reference for any new IPS document generated for the patient.

A new IPS document SHALL NOT be regenerated before each invocation of the Apply Guidelines transaction, but ServiceRequest resources created during the present Encounter SHALL be included in the Contextual Content bundle.

Request a Service (Radiology Order) CARD

The role of this type of CCG CARD is to create a radiology ServiceRequest for the patient.

The Action recommendation from this CARD SHALL be a ServiceRequest resource based on the CPGServiceRequest13 profile.

After processing the Apply Guidelines transaction response, the Resulting Data from this CARD SHALL be a Radiology Order ServiceRequest resource based on the CPGServiceRequest profile with either status=draft or status=revoked (indicating not done). The ServiceRequest resource SHALL reference the Encounter.

Note: active Radiology Order ServiceRequest resources SHALL be included as a CarePlan.activity.reference for any new IPS document generated for the patient.

A new IPS document SHALL NOT be regenerated before each invocation of the Apply Guidelines transaction, but ServiceRequest resources created during the present Encounter SHALL be included in the Contextual Content bundle.

Request a Service (Procedure Order) CARD

The role of this type of CCG CARD is to create a procedure ServiceRequest for the patient.

The Action recommendation from this CARD SHALL be a ServiceRequest resource based on the CPGServiceRequest14 profile.

After processing the Apply Guidelines transaction response, the Resulting Data from this CARD SHALL be a Procedure Order ServiceRequest resource based on the CPGServiceRequest profile with either status=draft or status=revoked (indicating not done). The ServiceRequest resource SHALL reference the Encounter.

Note: active Procedure Order ServiceRequest resources SHALL be included as a CarePlan.activity.reference for any new IPS document generated for the patient.

A new IPS document SHALL NOT be regenerated before each invocation of the Apply Guidelines transaction, but ServiceRequest resources created during the present Encounter SHALL be included in the Contextual Content bundle.

Request a Service (Referral) CARD

The role of this type of CCG CARD is to create a referral ServiceRequest for the patient.

The Action recommendation from this CARD SHALL be a ServiceRequest resource based on the CPGServiceRequest15 profile.

After processing the Apply Guidelines transaction response, the Resulting Data from this CARD SHALL be a Referral Order ServiceRequest resource based on the CPGServiceRequest profile with either status=draft or status=revoked (indicating not done). The ServiceRequest resource SHALL reference the Encounter.

Note: active Referral Order ServiceRequest resources SHALL be included as a CarePlan.activity.reference for any new IPS document generated for the patient.

A new IPS document SHALL NOT be regenerated before each invocation of the Apply Guidelines transaction, but ServiceRequest resources created during the present Encounter SHALL be included in the Contextual Content bundle.

Propose a Diagnosis CARD

The role of this type of CCG CARD is to propose a diagnosis of health conditions; it is content about the patient.

The Action recommendation from this CARD SHALL be a Task resource based on the CPGProposeDiagnosisTask16 profile.

It is the responsibility of the Guideline Performer to operationalize the processing of the Task resource to capture a patient diagnosis. After processing the Apply Guidelines transaction response, the Resulting Data from this CARD SHALL be a FHIR resource based on the CPGCondition17 profile with either a verificationStatus absent altogether or not entered-in-error or verificationStatus=entered-in-error (indicating the recommendation was not followed).

Order Medication CARD

The role of this type of CCG CARD is to create a prescription / medication order for the patient.

The Action recommendation from this CARD SHALL be a MedicationRequest resource based on the CPGMedicationRequest18 profile.

After processing the Apply Guidelines transaction response, the Resulting Data from this CARD SHALL be a MedicationRequest resource based on the CPGMedicationRequest profile with either status=draft, status=active or status=cancelled (with statusReason). The MedicationRequest resource SHALL reference the present Encounter.

Note: active MedicationRequest resources SHALL be included as a CarePlan.activity.reference for any new IPS document generated for the patient.

A new IPS document SHALL NOT be regenerated before each invocation of the Apply Guidelines transaction, but MedicationRequest resources created during the present Encounter SHALL be included in the Contextual Content bundle.

Dispense Medication CARD

The role of this type of CCG CARD is to record a medication dispensation.

The Action recommendation from this CARD SHALL be a Task resource based on the CPGDispenseMedicationTask19 profile.

After processing the Apply Guidelines transaction response, the Resulting Data from this CARD SHALL be a MedicationDispense resource based on the CPGMedicationDispense20 profile with either status=completed or status=cancelled (with statusReason). The MedicationDispense resource SHALL reference the present Encounter in the MedicationDispense.context.

A new IPS document SHALL NOT be regenerated before each invocation of the Apply Guidelines transaction, but MedicationDispense resources created during the present Encounter SHALL be included in the Contextual Content bundle.

Administer Medication CARD

The role of this type of CCG CARD is to record a medication administration.

The Action recommendation from this CARD SHALL be a Task resource based on the CPGAdministerMedicationTask21 profile.

After processing the Apply Guidelines transaction response, the Resulting Data from this CARD SHALL be a MedicationAdministration resource based on the CPGMedicationAdministration22 profile with either status=completed or status=not-done (with statusReason). The MedicationAdministration resource SHALL reference the present Encounter in the MedicationAdministration.context.

A new IPS document SHALL NOT be regenerated before each invocation of the Apply Guidelines transaction, but MedicationAdministration resources created during the present Encounter SHALL be included in the Contextual Content bundle.

Request Immunization CARD

The role of this type of CCG CARD is to recommend and record an immunization event for the patient. Importantly, this CARD does not create an order for a future planned immunization.

The recommended Action from this CARD SHALL be a MedicationRequest resource based on the CPGImmunizationRequest23 profile.

After processing the Apply Guidelines transaction response, the Resulting Data from this CARD SHALL be an Immunization resource based on the CPGImmunization24 profile with either status=completed or status=not-done (with statusReason).

A new IPS document SHALL NOT be regenerated before each invocation of the Apply Guidelines transaction, but Immunization resources created during the present Encounter SHALL be included in the Contextual Content bundle.

Stop Activity (Medication Order) CARD

The role of this type of CCG CARD is to create a Task that, upon being processed, will “stop” a patient’s presently active MedicationRequest (i.e. set status to stopped).

The recommended Action from this CARD SHALL be a Task resource based on the CPGStopTask25 profile.

After processing the Apply Guidelines transaction response, the Resulting Data from this CARD SHALL be an uPlanDefinitionated MedicationRequest resource that SHALL have a status = stopped, SHALL reference the present Encounter, and SHALL set authoredOn = current timestamp. A Provenance resource SHOULD be created to log details of the STOP order; specifics of this are out of scope for this Profile.

The IPS document in the Data-in Bundle SHALL be uPlanDefinitionated to reflect the uPlanDefinitionated MedicationRequest resource.

Stop Activity (Service Order) CARD

The role of this type of CCG CARD is to create a Task that, upon being processed, will “stop” a patient’s presently active ServiceRequest (i.e. set status to revoked).

The recommended Action from this CARD SHALL be a Task resource based on the CPGStopTask26 profile.

After processing the Apply Guidelines transaction response, the Resulting Data from this CARD SHALL be an uPlanDefinitionated ServiceRequest resource that SHALL have a status = revoked, SHALL reference the present Encounter, and SHALL set authoredOn = current timestamp. A Provenance resource SHOULD be created to log details of the STOP order; specifics of this are out of scope for this Profile.

The IPS document in the Data-in Bundle SHALL be uPlanDefinitionated to reflect the uPlanDefinitionated ServiceRequest resource.

References:

  1. https://hl7.org/fhir/uv/cpg/StructureDefinition-cpg-computableguideline.html ↩

  2. https://hl7.org/fhir/uv/cpg/STU2/StructureDefinition-cpg-computableplandefinition.html ↩

  3. https://vimeo.com/347427025 ↩

  4. https://build.fhir.org/ig/HL7/cqf-recommendations/profiles.html ↩

  5. https://stackoverflow.com/questions/37579152/nested-fhir-bundles ↩

  6. https://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_Suppl_DCP.PlanDefinitionf ↩

  7. https://hl7.org/fhir/uv/cpg/StructureDefinition-cpg-communicationrequest.html ↩

  8. https://hl7.org/fhir/uv/cpg/StructureDefinition-cpg-communication.html ↩

  9. https://hl7.org/fhir/uv/sdc/extraction.html#definition-extract ↩

  10. https://hl7.org/fhir/uv/cpg/StructureDefinition-cpg-questionnairetask.html ↩

  11. https://hl7.org/fhir/uv/cpg/StructureDefinition-cpg-observation.html ↩

  12. https://hl7.org/fhir/uv/cpg/StructureDefinition-cpg-servicerequest.html ↩

  13. https://hl7.org/fhir/uv/cpg/StructureDefinition-cpg-servicerequest.html ↩

  14. https://hl7.org/fhir/uv/cpg/StructureDefinition-cpg-servicerequest.html ↩

  15. https://hl7.org/fhir/uv/cpg/StructureDefinition-cpg-servicerequest.html ↩

  16. https://hl7.org/fhir/uv/cpg/StructureDefinition-cpg-proposediagnosistask.html ↩

  17. https://hl7.org/fhir/uv/cpg/StructureDefinition-cpg-condition.html ↩

  18. https://hl7.org/fhir/uv/cpg/StructureDefinition-cpg-medicationrequest.html ↩

  19. https://hl7.org/fhir/uv/cpg/StructureDefinition-cpg-dispensemedicationtask.html ↩

  20. https://hl7.org/fhir/uv/cpg/StructureDefinition-cpg-medicationdispense.html ↩

  21. https://hl7.org/fhir/uv/cpg/StructureDefinition-cpg-administermedicationtask.html ↩

  22. https://hl7.org/fhir/uv/cpg/StructureDefinition-cpg-medicationadministration.html ↩

  23. https://hl7.org/fhir/uv/cpg/StructureDefinition-cpg-immunizationrequest.html ↩

  24. https://hl7.org/fhir/uv/cpg/StructureDefinition-cpg-immunization.html ↩

  25. https://hl7.org/fhir/uv/cpg/StructureDefinition-cpg-stoptask.html ↩

  26. https://hl7.org/fhir/uv/cpg/StructureDefinition-cpg-stoptask.html ↩