Common CQL Artifacts for FHIR (US-Based)
2.0.0-ballot - Informative 2 Ballot

Common CQL Artifacts for FHIR (US-Based) - Downloaded Version null See the Directory of published versions

## Service Patterns

Page standards status: Informative | Highlight text changes?

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
- DiagnosticReportNote - Recording a mammography test report
- Claim - Recording a claim for a mammography provided
- ExplanationOfBenefit - Recording an adjudicated claim for a mammography

Note that we are excluding the Procedure and ImagingStudy possibilities.

This leads to the following patterns:

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

    define "Mammography Diagnostic Report":
      ["DiagnosticReport Profile for Report and Note Exchange": "Mammography Report"] MammographyReport
        where MammographyReport.isComplete()

For the Claim and ExplanationOfBenefit patterns, see Mammography Claim.

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