CMS FHIR Quality Measure Development IG, published by Centers for Medicare & Medicaid Services (CMS). This guide is not an authorized publication; it is the continuous build for version 0.8.0-cibuild built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/cqframework/cms-qmd/ and changes regularly. See the Directory of published versions

Encounters

US Quality Core defines a US Quality Core Encounter profile to model any encounter between a patient and any number of providers in any setting, including virtual.

The US CQL implementation guide does not publish an Encounter patterns page, so this page is the primary source for encounter patterns; see the Pattern Index for the full list of available patterns. The encounter-specific fluent functions referenced below are defined in the CQMCommon library.

Several billing-related elements are represented in the clinical record on the Encounter resource rather than on Condition or Procedure: present on admission, principal diagnosis, and primary procedure on Encounter.diagnosis, and discharge disposition on Encounter.hospitalization. Those patterns are below; the corresponding claim representations are documented in Claim.

Office visit encounters

By default, encounters in US Quality Core are characterized using the type element, which is typically bound to a value set. The retrieve limits the result to encounters whose type includes a code from that value set:

define "Office Visit Encounters":
  [USQualityCore.Encounter: "Office Visit"]

Accessing Encounters with a Direct-reference code

The type element is multi-cardinality, so a given Encounter may carry several types. With a value set the retrieve resolves using the List<Concept> overload of the in(ValueSet) operator, but there is no equivalent overload of Equivalent (~) for comparing a list against a direct-reference code.

This is under review and may result in a specification or tooling change (see Translator Issue 1181). Until then there are two workarounds:

1. Define a value set containing the required code, and retrieve with that value set.
2. Retrieve without a terminology filter and test with an exists:

define "Office Visit Encounters By Code":
  [USQualityCore.Encounter] Visit
    where exists ((Visit.type) VisitType where VisitType ~ "Office Visit Code")

The second workaround typically produces an unrestricted data requirement for Encounter, so the first is preferred.

Encounters by class

The profile also supports characterizing encounters by class, which categorizes more broadly than type using the ActEncounterCode value set. Because class is single-cardinality, a direct-reference code works in the retrieve:

define "Virtual Encounters":
  [USQualityCore.Encounter: class ~ USQualityCoreCommon."virtual"]

Although QDM-based eCQMs have historically filtered encounters by type, class is a required element in US Core, so the recommendation is to filter by class first unless measure intent requires identifying encounters by type across classes. Additional filtering is often needed, for example to limit encounters by specialty:

define "Ophthalmology Encounter Codes":
  [USQualityCore.Encounter: class in "Inpatient Encounter Class Code"] InpatientEncounter
    where InpatientEncounter.type in "Ophthalmology Services"

Completed encounters in a period

Encounters usually need filtering on status and period:

define "Completed Encounters During The Measurement Period":
  [USQualityCore.Encounter: "Office Visit"] OfficeVisit
    where OfficeVisit.status = 'finished'
      and OfficeVisit.period starts during "Measurement Period"

Encounters with a certain length

CQMCommon defines lengthInDays(), which returns the difference in calendar days between the start and end of an interval:

define "Non Elective Inpatient Encounter Less Than 120 Days":
  [USQualityCore.Encounter: "Non Elective Inpatient Encounter"] NonElectiveEncounter
    where NonElectiveEncounter.period.lengthInDays() <= 120

Other durations are calculated directly:

define "Non-Elective Inpatient Encounter Over 24 Hours":
  [USQualityCore.Encounter: "Non Elective Inpatient Encounter"] NonElectiveEncounter
    where duration in hours of NonElectiveEncounter.period >= 24

NOTE: For an ongoing encounter the end of the period is often absent, which CQL interprets as an ongoing period and which will produce large duration values.

Hospitalization

For inpatient encounters, measures often need the whole hospitalization, including any immediately preceding emergency department or observation encounter. CQMCommon defines a family of fluent functions over an Encounter for this:

Function	Returns
hospitalization()	The admission-to-discharge interval, extended back to the admission of any immediately prior emergency department visit
hospitalizationWithObservation()	The same, extended back through any immediately prior observation encounter
hospitalizationWithObservationAndOutpatientSurgeryService()	The same, also including an immediately prior outpatient surgery service
hospitalizationLengthOfStay()	Length of stay in days over the hospitalization interval
hospitalizationWithObservationLengthofStay()	Length of stay in days including observation
hospitalizationLocations()	All locations within the encounter, including those of an immediately prior emergency department visit
edVisit()	The most recent emergency department visit occurring one hour or less before the encounter, if any
emergencyDepartmentArrivalTime()	Emergency department arrival time for the encounter
hospitalAdmissionTime()	Admission time for the encounter, or for an immediately prior emergency department visit
hospitalDischargeTime()	Discharge time for the encounter
hospitalArrivalTime()	Earliest arrival time for the encounter, including any prior emergency department visit
hospitalDepartureTime()	Latest departure time for the encounter, including any prior emergency department visit
firstInpatientIntensiveCareUnit()	The first intensive care unit location of the encounter, not considering any immediately prior emergency department visit

For example, to find comfort measures performed at any point during the hospitalization:

define "Comfort Measures Performed":
  [USQualityCore.Procedure: "Comfort Measures"] InterventionPerformed
    where InterventionPerformed.status in { 'completed', 'in-progress' }

define "Encounter With Comfort Measures Performed During Hospitalization":
  "Non Elective Inpatient Encounter Less Than 120 Days" NonElectiveEncounter
    with "Comfort Measures Performed" ComfortMeasure
      such that start of ComfortMeasure.performed.toInterval() during NonElectiveEncounter.hospitalizationWithObservation()

Present on Admission

Present on admission is an indication of whether or not the diagnosis was present when the patient was admitted (as opposed to a condition that developed during the encounter). This is not the same as the admitting diagnosis.

In the clinical record, whether or not a given diagnosis is or was present on admission is not always recorded explicitly. It may not be recorded unless that element has direct bearing on treatment (and even then it may not be discretely captured). In a clinical setting, if it is recorded, it is likely captured with a simple boolean flag. Also, whether or not a diagnosis was present on admission may be inferred, for example a congenital condition was obviously present on admission.

With those caveats, within the clinical record, present-on-admission is represented in US Quality Core using the presentOnAdmission extension:

define "Encounter With Asthma Present On Admission":
  [Encounter] E
    where exists (
      E.diagnosis D
        where D.condition.getCondition().code in "Asthma"
          and D.presentOnAdmission() in "Present On Admission Indicators"
    )

Note that the Encounter.diagnosis element is not profiled in the US Core Encounter profile in any version. Encounter diagnoses in US Core use the Encounter.reasonCode and Encounter.reasonReference elements, as well as the ConditionEncounterDiagnosis profile, so this representation is not likely to be available in data sourced from US Core implementations.

For the claim representation, see Present on Admission. See also the Billing-related Elements discussion.

Principal Diagnosis

Principal diagnosis is primarily a term used in hospital coding and reporting. However, FHIR also allows the element to be represented using the diagnosis element of an Encounter:

define "Encounter With Principal Diagnosis Of Asthma":
  [Encounter] E
    where exists (
      E.diagnosis D
        where D.condition.getCondition().code in "Asthma"
          and D.use = FHIRCommon."Billing"
          and D.rank = 1
    )

Note that the Encounter.diagnosis element is not profiled in the US Core Encounter profile in any version. Encounter diagnoses in US Core use the Encounter.reasonCode and Encounter.reasonReference elements, as well as the ConditionEncounterDiagnosis profile, so this representation is not likely to be available in data sourced from US Core implementations.

For the claim representation, see Principal Diagnosis. See also the Billing-related Elements discussion.

Primary Procedure

Primary procedure is primarily a term used in hospital coding and reporting. However, FHIR also allows the element to be represented using the diagnosis element of an Encounter. That is not a copy of the principal diagnosis pattern above: Encounter.diagnosis.condition is a reference to either a Condition or a Procedure, so the same element carries both, distinguished by what it points at.

define "Encounter With Primary Procedure Of Appendectomy":
  [Encounter] E
    where exists (
      E.diagnosis D
        where D.condition.getProcedure().code in "Appendectomy"
          and D.use = FHIRCommon."Billing"
          and D.rank = 1
    )

Note that the Encounter.diagnosis element is not profiled in the US Core Encounter profile in any version. Encounter diagnoses in US Core use the Encounter.reasonCode and Encounter.reasonReference elements, as well as the ConditionEncounterDiagnosis profile, so this representation is not likely to be available in data sourced from US Core implementations.

For the claim representation, see Primary Procedure. See also the Billing-related Elements discussion.

Discharge Disposition

In US Quality Core, discharge disposition on an encounter is represented as a clinical element using the Clinical Discharge Disposition value set.

define "Encounter With Discharge Disposition To Home":
  [Encounter] E
    where E.hospitalization.dischargeDisposition in "Home Discharge Disposition Codes"

Note that the dischargeDisposition element in US Core is profiled to use UB-04 billing codes, whereas the element in US Quality Core is overridden to use clinical discharge disposition codes, with the billing codes used in the claim representation (see below).

For the claim representation see Discharge Disposition. See also the Billing-related Elements discussion.

Admission Source

In FHIR, admission source on an encounter is represented using the Encounter.hospitalization.admitSource element, using the Admit Source terminology.

define "Encounter With Admission From Emergency Department":
  [Encounter] E
    where E.hospitalization.admitSource in "Emergency Department Admission Source Codes"

NOTE: This element is being proposed for inclusion in the US Quality Core Encounter Profile in the 1.0.0 ballot. It is not currently profiled in the 0.5.0 version, though the element can still be referenced in logic because it is not restricted by the profile, it is just not marked as required or must support.

NOTE: The clinical terminology for this element does not currently have hospice as an admission source. A UTG ticket has been submitted to add hospice to this terminology: https://jira.hl7.org/browse/UP-865

For the claim representation see Admission Source. See also the Billing-related Elements discussion.