QI-Core Implementation Guide: STU Ballot (v3.3.0 for FHIR 4.0.0)

Quality Improvement Core Framework (v3.3.0: STU 4 Ballot 1). The current version is 3.2.0 based on FHIR R4. See the Directory of published versions

7.14.0 Intervention and Procedure

QDM defines Intervention and Procedure as:

  • Intervention is a course of action intended to achieve a result in the care of persons with health problems that does not involve direct physical contact with a patient. Examples include patient education and therapeutic communication.
  • Procedure is an act whose immediate and primary outcome (post-condition) is the alteration of the physical condition of the subject. A procedure may be a surgery or other type of physical manipulation of a person's body in whole or in part for purposes of making observations and diagnoses or providing treatment.

7.14.1 Procedure Vs Intervention

FHIR references both of these concepts using the Procedure resource, specifically noting a process that involves verification of the patient's comprehension or to change the patient's mental state would be a Procedure. Therefore, both QDM datatypes, Procedure and Intervention are included in this section of the QDM to QI-Core mapping especially since all of the QDM attributes for each of these QDM datatypes are identical.

7.14.2 Procedure Vs Task

Some use cases have considered differentiating a FHIR Procedure Resource from a FHIR core Task Resource. For example, should a request to perform medication reconciliation be classified as a Task or a Procedure? The FHIR Procedure Resource Boundaries and Relationships (Section 9.3.2) provides some distinction between a Task and a Procedure:

A Task is a workflow step such as cancelling an order, fulfilling an order, signing an order, merging a set of records, admitting a patient. Procedures are actions that are intended to result in a physical or mental change to or for the subject (e.g. surgery, physiotherapy, training, counseling). A Task resource often exists in parallel with clinical resources. For example, a Task might request fulfillment of a ServiceRequest ordering a Procedure.

Based on the guidance provided above, the workflow step to reconcile medication lists may be considered a Task to perform the Procedure that includes reviewing the medication list with the patient to assure it is correct and to education the patient about proper medication usage.

QDM 5.5 does not address Task; therefore, there is no direct mapping from QDM Intervention or Procedure to the FHIR Task resource.  The mapping presented is from QDM to QI-Core referencing the FHIR Procedure resource.

7.14.3 Procedure Priority

QDM 5.5 includes a new attribute for Procedure: priority with the following definition:

Priority indicates the urgency of the procedure or the encounter referenced. In [electronic clinical quality measures] (eCQMs) the priority attribute will help specify elective from urgent encounters (e.g., hospital admissions) or procedures. Priority is a codable concept (i.e., may use a direct reference code or a value set). For example, priority is used to express an elective procedure or encounter from an emergency procedure or encounter.

As noted in the QDM to QI-Core Mapping for Encounter-Related Diagnoses and Procedures, a specific measure may have interest in evaluating care provided for elective procedures (e.g., hip surgery due to osteoarthritis) while excluding emergency, non-planned procedures (e.g., hip surgery due to acute fracture). The procedure code does not necessarily allow differentiation of the two concepts. A ServiceRequest.priority does have the ability to differentiate the urgency with which the request (or order) should be fulfilled. However, there is no element within the FHIR Procedure resource to address the issue. Encounter.priority allows specification of whether the encounter is elective. An encounter with Encounter.priority = elective and an Encounter.procedure.rank = 1 addresses the need to specify an elective encounter with a principal procedure. Therefore, based on the current use case QI-Core has not added an extension to address Procedure.priority and, as a result, there is no direct mapping from the QDM Procedure priority attribute to QI-Core.

QDM Context QI-Core R4 Comments
Procedure, Performed and Intervention, Performed Procedure
Procedure, Performed Context Procedure.category Helps differentiate "intervention" from "procedure" from QDM
QDM Attributes
status Procedure.status constrain to "completed"
Code Procedure.code
Procedure.category Helps differentiate "intervention" from "procedure" from QDM
id Procedure.id
Method N/A Procedure.method does not exist in FHIR. Rather than create an extension, QI-Core's approach is to assume the Procedure.code includes reference to the method.
Rank Referenced as attributes of Encounter (Encounter.rank). Consider extension for Procedure.sequence to be consistent with the FHIR Claim resource includes a Claim.procedure.sequence used to uniquely identify procedure entries. Claim.procedure.type provides a relative ranking with two example concepts - primary (the first procedure in a series to produce an overall patient outcome) and secondary the second procedure in a series required to product an overally patient outcome). However, type refers to procedures within a serier for which one is first. Such a sequence does not assure that the first procedure is the principal procedure for an encounter.
Priority Referenced as Encounter.priority to determine the elective nature of a procedure (i.e., a principal procedure performed as part of an encounter in which Encounter.priority=elective.
Anatomical Location Site Procedure.bodySite
Reason Procedure.reasonCode
Result Procedure.report Procedure.report references DiagnosticReport, DocumentReference, Composition (histology result, pathology report, surgical report, etc.). However, based on feedback regarding the use of the Observation resource, a procedure result might be better referenced as an Observation that includes the element Observation.partOf to reference the procedure to which it applies.
Observation.partOf
Negation Rationale Procedure.status constrain status to "Not-done"
Procedure.statusReason
Relevant dateTime Procedure.performed[x] dateTime
Relevant Period Procedure.performed[x] Period
Incision dateTime Procedure.extension:incisionDateTime
Author dateTime N/A The concept "author" requires a reference to a report about the procedure or about an indication the procedure was not performed. Therefore, the procedure resource does not have a reference to author dateTime. Author dateTime can reference a report about the procedure or an observation describing that result (e.g., Observation with metadata Observation.partOf procedure).
Components N/A Procedure does not include components and the concept of components references a observation that is a result of the procedure (Observation.partOf) for which that observation has components consistent with the Observation component modeling recommendation in FHIR.
Component Code N/A N/A
Component result N/A N/A
Performer Procedure.performer

7.14.4 Intervention, Order

To address the QDM attribute Intervention, Order see Service Request

7.14.5 Intervention, Recommended

To address the QDM attribute Intervention, Recommended see Service Request

7.14.6 Procedure, Order

To address the QDM attribute Procedure, Order see Service Request

7.14.7 Procedure, Recommended

To address the QDM attribute Procedure, Recommended see Service Request