Common CQL Artifacts for FHIR (US-Based), published by HL7 International / Clinical Decision Support. This guide is not an authorized publication; it is the continuous build for version 1.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/us-cql-ig/ and changes regularly. See the Directory of published versions

Service Patterns

Page standards status: Informative

US Core defines US Core ServiceRequest to track the proposal / planning / ordering of a service, and US Core Procedure to track performing a service.

Typical procedure codes include SNOMED-CT, CPT, HCPCS II, ICD-10-PCS, CDT, and LOINC.

Modifier Elements

The ServiceRequest resource defines the following modifier elements:

• status
• intent
• doNotPerform

In addition to being modifiers, the status and intent elements are required with a required binding. The USCoreCommon library defines several functions for determining status and intent of a service request.

However, doNotPerform is not required, so care must be taken to ensure that if specified, the doNotPerform element is respected.

The Procedure resource defines the following modifier elements:

• status

In addition to being a modifier, the status element is required with a required binding. The USCoreCommon library defines several functions for determining status of a procedure.

Search Parameters

USCore defines the following mandatory search parameters:

• patient, category
• patient, code
• patient, category, authored

In addition, the following optional parameters are defined:

• patient, status
• patient, code, authored

NOTE: For discussion on how to manage search parameters with terminology, see the Terminology Considerations discussion in the Architectural Guidance topic.

NOTE: For discussion on how to manage optional search parameters, see the Performant Data Access discussion in the Architectural Guidance topic.

Cross-Version Considerations

Note that 3.1.1 does not define a profile for ServiceRequest, so the direct FHIR ServiceRequest resource is used.

Common Elements and Functions

Requested Services

NOTE: In the prior auth use case, the workflow is generally being conducted in the context of 1 or more order, so you'll want to start by working off that context before searching the FHIR server for service requests.

If you need to search for requested services, this is made available with UCE."All ServiceRequests".

Procedures Performed

US Core defines the Procedure profile to represent an in-progress or complete procedure for a patient. By default, Procedure resources in US Core are characterized by the code element.

define "Application of Intermittent Pneumatic Compression Devices":
  ["Procedure": "Application of Intermittent Pneumatic Compression Devices (IPC)"] DeviceApplied
    where DeviceApplied.status = 'completed'

NOTE: Because the Procedure profile does not fix the value of the status element, authors must consider all the possible values of the element to ensure the expression meets measure intent. In this case, completed status is used to indicate that only completed procedures should be returned.

Imaging Procedures

In FHIR generally, because they involve significant and specialized information, imaging procedures (such as X-Rays, CT-Scans, MRIs, etc.) have resources designed specifically to represent imaging information. Overall, imaging procedures are represented using a combination of the following FHIR resources:

• ServiceRequest - representing a proposal, plan, or order for an imaging procedure, using the code element to distinguish the type of procedure being ordered
• Procedure - representing the actual performance of the imaging procedure, using the code element to distinguish the type of procedure performed
• ImagingStudy - representing the resulting images and other DICOM content, using the procedureCode, procedureReference, and/or basedOn elements to associate the study to an order or procedure
• DiagnosticReport - representing the interpretation or clinical impression of the imaging procedure (detected or ruled out diagnoses), using the code element to distinguish the type of test or report
• Observation - representing individual measurements and comments on the images, using the code element to distinguish the type of measurement
• Claim - representing the claim for an imaging procedure, specifically the procedure[x] element to distinguish the type of procedure performed
• ExplanationOfBenefit - representing an adjudicated claim response for an imaging procedure, specifically the procedure[x] element to distinguish the type of procedure performed

Depending on the procedure, and the extent to which the results of that procedure are captured by clinical systems, there is variation in whether each of these resources is present for any given imaging procedure. In particular, Some diagnostic procedures might not have a Procedure record. The Procedure record is only necessary when there is a need to capture information about the physical intervention that was performed to capture the diagnostic information (e.g. anaesthetic, incision, scope size, etc.). As a result, authors must consider how to approach gathering information for specific procedures to ensure expressions match application intent.

For example, if application intent is that a CT Scan was performed, regardless of the results of that scan, authors should consider looking in all of the above possible locations for evidence that a CT Scan was performed:

• ServiceRequest with an intent of order and a status of completed
• Procedure with a status of completed
• ImagingStudy with a status of available and related by basedOn or one of the procedure elements
• ​DiagnosticReportNote with a status of final, amended, appended, or corrected
• ObservationClinicalResult with a status of final, amended, or corrected
• ​Claim with a status of active and a use of claim
• ​ExplanationOfBenefit with a status of active and a use of claim

If application intent is only looking for the performance of the scan, not whether it was resulted, the first two may suffice:

define "CT Scan Order Completed":
  ["ServiceRequest": "CT Scan Codes"] SR
    where SR.intent = 'order'
      and SR.status = 'completed'

define "CT Scan Procedure Performed":
  ["Procedure": "CT Scan Codes"] P
    where P.status = 'completed'

define "CT Scan Performed":
  exists "CT Scan Order Completed"
    or exists "CT Scan Procedure Performed"

However, if application intent is that the scan was performed and resulted, diagnostic report provides the next level of checking:

define "CT Scan Diagnostic Report":
  ["DiagnosticReportNote": "CT Scan Notes"] DR
    where DR.status in ('final', 'amended', 'corrected', 'appended')

An additional check may be considered by looking for any imaging study results:

define "CT Scan Imaging Study":
  ["ImagingStudy"] IS
    where exists (IS.procedureCode C where C in "CT Scan Procedure Codes")
      or exists ("CT Scan Procedure Performed" P
        where IS.procedureReference.references(P)
      )

As well as potentially looking for any measurements performed as part of the scan or study.

NOTE: This topic is a summary of discussion with the Orders & Observations Work Group in the following FHIR Zulip chat: https://chat.fhir.org/#narrow/channel/179256-Orders-and-Observation-WG/topic/How.20to.20represent.20CT-Scan.3F/with/541254708. Also note that part of that discussion suggests that ChargeItem may be useful as a source of evidence that something was done. This needs followup and additional investigation.

Mammography

Applying this pattern to mammography, we may find evidence of mammography performed in:

• ObservationClinicalResult - Recording a mammography test result
• Claim - Recording a claim for a mammography provided
• ExplanationOfBenefit - Recording an adjudicated claim for a mammography

Note that we are excluding the Procedure, DiagnosticReportNote, and LaboratoryTestResult possibilities

For mammography, the following patterns can be used:

define "Mammography Observation":
  ["Observation Clinical Result Profile": "Mammography Result"] MammographyResult
    where MammographyResult.isImaging()
      and MammographyResult.isResulted()

​For the Claim and ExplanationOfBenefit patterns, see Mammography Claim.

NOTE: Content for this page was adapted from the QICore Authoring Patterns - Procedures topic.