Authoring Measures in CQL
This topic will provide a complete discussion of using Clinical Quality Language (CQL) to author electronic Clinical Quality Measures (eCQMs). The discussion assumes familiarity with clinical quality measurement in general, and the representation of eCQMs using Health Quality Measure Format (HQMF) and Quality Data Model (QDM) in particular.
Clinical Quality Language (CQL) is a high-level query language, meaning that it can be used to write expressions that determine what data is to be returned, not how it is to be returned. How the data is to be returned is part of the implementation of a quality measure, and may be accomplished in any number of ways (e.g. by queries in a database system, or map-reduce processing on a Hadoop cluster), so CQL is intentionally silent on any of those details, allowing the logic expressed by CQL queries to be used in a broad variety of implementation environments to achieve the same result.
One of the central constructs available in CQL is the expression, which is any sequence of CQL that returns a value. Values are the data that CQL operates on, and can be simple values like the integer 5 and the string John Doe, or they can be complex structures (or rows, also called tuples) like a QDM Encounter, Performed, which contains attributes such as admissionSource and relevantPeriod that are themselves values of different types.
The type of value that an expression returns is based on the contents of the expression. For example, an expression that consists only of a value, such as 5 will simply return that value. Operators, such as + and * can be used to create more complex expressions such as 2 + 3, which will return the result of evaluating the operation, the value 5 in this case. Expressions can also make use of functions, such as CalculateAge() that allow more complex operations to be defined and reused.
One of the most important types of values available in CQL is the list, which is a sequence of values of any type. Lists can contain simple values, like a list of integers, { 1, 2, 3 }, or they can contain tuples, like a list of encounters.
CQL includes a full suite of operators and functions to allow expressions to be written that can describe the logic and criteria used to precisely represent clinical quality measures. The following sections will discuss how to use this language to author a measure from the ground up.
One of the first considerations when expressing a clinical quality measure in CQL is determining what the measure is counting. Is the measure patient-based, meaning that the measure is expressed as some relationship between populations of patients, or is the measure counting some other kind of case such as encounters or procedures?
If the measure is patient-based, then the criteria we define will all return true or false for each specific patient, indicating whether the patient is part of the population being defined by that criteria. A true or false value is type Boolean in CQL, and many of the built-in operations such as comparison (e.g. value > 5) return values of this type.
For example, to express the demographic criteria for a patient-based measure, we can define an In Demographic expression:
define "In Demographic":
AgeInYearsAt(start of "Measurement Period") >= 13
This example returns true or false for a given patient, depending on whether they satisfy the criteria (13 years of age or older at the start of the measurement period).
Often, we want to identify whether a patient has had a particular type of encounter as part of a patient-based measure. For example:
define "Inpatient Encounters":
["Encounter, Performed": "Inpatient Encounter Codes"] Encounter
where Encounter.relevantPeriod during "Measurement Period"
This expression returns a list of encounters for the patient that match one of the codes in the Inpatient Encounter Codes value set, and that occurred during the measurement period. Now because the result of this expression is a list of encounters, we use an exists to turn the value into a Boolean so we combine it with the previous expression:
define "Initial Population":
"In Demographic"
and exists ("Inpatient Encounters")
The exists operator works on a list of values and returns true if the list has any values, and false if the list is empty.
By contrast, if we are counting encounters in an episode-of-care measure, the population criteria will all need to result in lists of encounters:
define "Measurement Period Encounters":
["Encounter, Performed": "Ambulatory/ED Visit"] Encounter
where Encounter.relevantPeriod during "Measurement Period"
and "In Demographic"
define "Pharyngitis Encounters With Antibiotics":
"Measurement Period Encounters" Encounter
with "Pharyngitis" Pharyngitis
such that Pharyngitis.relevantPeriod includes Encounter.relevantPeriod
or Pharyngitis.relevantPeriod starts during Encounter.relevantPeriod
with "Antibiotics" Antibiotics
such that Antibiotics.authorDatetime 3 days or less after start of Encounter.relevantPeriod
Since the measure is counting encounters, we can return the list in the initial population:
define "Initial Population":
"Pharyngitis Encounters With Antibiotics"
Once we've identified the type of information the measure will be counting, we need to describe what information needs to be retrieved from the source in order to build the population criteria. QDM allows us to describe clinical information as Data Elements, which identify a Data Type and a Value Set. The Data Type combines a Category of clinical information, such as Encounter, Medication, or Procedure, with a context, such as Performed, Administered, or Ordered. The Data Type then determines the structure of the information. For example, the Medication, Administered Data Type has the following attributes:
- authorDatetime
- relevantPeriod
- dosage
- supply
- frequency
- reason
- negationRationale
In addition to the Data Type, a QDM Data Element specifies a Value Set to indicate precisely what kinds of information should be retrieved. For example, the Outpatient Encounter Codes Value Set identifies encounters that take place in an outpatient setting. The QDM Data Element is then:
"Encounter, Performed: Outpatient Encounter Codes"
In CQL, this is expressed using a retrieve, which encloses the QDM Data Element information in square brackets ([]):
["Encounter, Performed": "Outpatient Encounter Codes"]
This retrieve expression results in only the highlighted encounters, because they have codes that match the "Outpatient Encounter Codes" Value Set:
This table depicts the instances (or rows) of encounters that might be present in an EHR for a particular patient. It only shows the id, code, and the relevantPeriod attributes for each instance. Note that every QDM Data Element has an implicit id and code that identifies the instance and the specific code for that instance.
Note that the quotation marks in this expression are important, as they are delineating the names of the constructs involved:
| Identifier | Description |
|---|---|
"Encounter, Performed" |
The name of the QDM Data Type |
"Outpatient Encounter Codes" |
The name of the Value Set |
Any expression in CQL can be given a name so that it can be reused by referencing it in other expressions. The define statement is used for this purpose:
define "Outpatient Encounters":
["Encounter, Performed": "Outpatient Encounter Codes"]
With this statement in a CQL library, the identifier "Outpatient Encounters" can now be used as a variable in other expressions.
Another central construct in CQL is the query, which is a specific type of expression that allows relationships between data to be easily and precisely expressed. Queries in CQL are clause-based meaning that they have different types of clauses that can be used depending on what operations need to be performed on the data. Each clause in a query is introduced with a different keyword, and must appear in a particular location within the query in order to be valid CQL.
The general structure of a CQL query is:
<source> <alias>
<with or without clauses>
<where clause>
<return clause>
<sort clause>
All the clauses are optional, so the simplest query is just a source and an alias:
"Outpatient Encounters" Encounter
Here, the source is just a reference to Outpatient Encounters, which is an expression that returns a list of encounters. This source is given the alias Encounter. The alias allows the elements of the source to be referenced anywhere within the query. However, this simple query doesn't have any clauses, so it simply returns the same result as the source.
The where keyword introduces a where clause, which allows you to filter the results of the source:
"Outpatient Encounters" Encounter
where Encounter.relevantPeriod during "Measurement Period"
This query returns only those encounters from the source whose relevantPeriod occurred entirely during the measurement period:
The where clause allows you to specify any condition in terms of the aliases introduced in the query, Encounter in this case. The condition in the where clause is evaluated for every encounter in the "Outpatient Encounters" query source, and the result then includes only those encounters for which the condition evaluated to true.
Describing relationships between data is so common in quality measurement that CQL provides special constructs to make expressing these relationships as simple as possible, the with and without keywords.
The with keyword can be used to describe cases that should only be considered if a related data item is present:
["Encounter, Performed": "Outpatient"] Encounter
with ["Laboratory Test, Performed": "Streptococcus Test"] Test
such that Test.resultDatetime during Encounter.relevantPeriod
This query limits the outpatient encounters returned to only those that had a streptococcus test performed during the encounter. The such that clause describes the condition of the relationship, which is expressed in terms of the aliases Encounter (for the main source of the query) and Test, which is only available in the such that clause.
In addition, the without keyword can be used to describe cases that should only be considered if a particular data item is not present:
["Encounter, Performed": "Outpatient"] Encounter
without ["Laboratory Test, Performed": "Streptococcus Test"] Test
such that Test.resultDatetime during Encounter.relevantPeriod
This query limits the outpatient encounters returned to only those that did not have a streptococcus test performed during the encounter. Just like the with clause, the without clauses uses such that to describe the condition of the relationship.
Note that the where and such that phrases serve very similar purposes in that they are both used to describe a condition that must hold. The difference is that such that is only valid as part of a with or without clause, and is the only place where the aliases introduced in those clauses can be referenced. For example, consider the following query:
["Encounter, Performed": "Outpatient"] Encounter
without ["Laboratory Test, Performed": "Streptococcus Test"] Test
such that Test.resultDatetime during Encounter.relevantPeriod
where Test.result is not null
This query is invalid because the alias Test is only available within the without clause that introduced it.
The with and without clauses apply to the whole query; every additional with or without clause further restricts the cases that will be returned. This means that these clauses can't be used directly to express presence of one item or another. Combining with and without clauses optionally can be accomplished using a union operator:
"Encounters With Comfort Measures"
union "Encounters With Expected Discharge Status"
The order in which the items are returned from a query can be described using a sort clause:
["Encounter, Performed": "Outpatient"] Encounter
sort by start of relevantPeriod
This query returns the results sorted by the start of the relevantPeriod element, ascending:
Note that the alias Encounter is not used in the sort clause. This is because the sort applies to the output of the query, so only elements that are present in the result can be referenced and there is no need to identify the source alias.
Also, any element of the result can be the target of the sort, but the values of the element must be comparable (i.e. must be able to be compared using <, > and =). Consider the following invalid query:
["Encounter, Performed": "Outpatient"] Encounter
sort by relevantPeriod
This query is invalid because relevantPeriod is an interval, and intervals cannot be unambiguously compared with >.
To determine the length of time between two dates, CQL provides two different approaches, duration the number of whole periods between two dates, and difference, the number of period boundaries crossed between two dates.
The first approach, calculating the duration, determines the number of whole periods that occur between the two dates. Conceptually, the calculation is performed by considering the two dates on a timeline, and counting the number of whole periods that fit on that timeline between the two dates. For example:
Date 1: 2012-03-10
Date 2: 2013-03-10
Duration In Years: years between Date1 and Date2
The Duration In Years expression gives one year, because an entire year has passed between the two dates. Note that time is considered for the purposes of calculating the number of years:
DateTime 1: 2012-03-10 10:20:00
DateTime 2: 2013-03-10 09:20:00
Duration in Years: years between DateTime1 and DateTime2
This expression gives zero years, because the year has not passed until 10:20:00 on the day in the following year. To calculate the number of years, ignoring the time, extract the date from the date/time value:
DateTime 1: 2012-03-10 10:20:00
DateTime 2: 2013-03-10 09:20:00
Duration In Years: years between (date from DateTime1) and (date from DateTime2)
The second approach, calculating the difference, determines the number of boundaries crossed between two dates. To illustrate the difference, consider the following example:
Date 1: 2012-12-31
Date 2: 2013-01-01
Duration In Years: years between Date1 and Date2
Difference In Years: difference in years between Date1 and Date2
The Duration In Years expression returns zero because a full year has not passed between the two dates. However, the Difference In Years expression returns 1 because one year boundary was crossed between the two dates.
In CQL, a year is defined as the duration of any time interval which starts at a certain time of day at a certain calendar date of the calendar year and ends at:
- The same time of day on the same calendar date of the next calendar year, if it exists
- The same time of day on the immediately following calendar date of the next calendar year, if the same calendar date of the next calendar year does not exist.
Note: When in the next calendar year the same calendar date does not exist, the ISO states that the ending calendar day has to be agreed upon. The above convention is used in CQL as a resolution to this issue.
- Month (date 2) < month (date 1): Duration (years) = year (date 2) - year (date 1) - 1
Example 1:
Date 1: 2012-03-10 22:05:09
Date 2: 2013-02-18 19:10:03
Duration = year (date 2) - year (date 1) - 1 = 2013 - 2012 - 1 = 0 years
- Month (date 2) = month (date 1) and day (date 2) >= day (date 1)
Duration (years) = year (date 2) - year (date 1)
Example 2.a: day (date 1) = day (date 2)
Date 1: 2012-03-10 22:05:09
Date 2: 2013-03-10 22:05:09
Duration = year (date 2) - year (date 1) = 2013 - 2012 = 1 year
Note: Time of day is important in this calculation. If the time of day of Date 2 were less than the time of day for Date 1, the duration of the time interval would be 0 years according to the definition.
Example 2.b: day (date 2) > day (date 1)
Date 1: 2012-03-10 22:05:09
Date 2: 2013-03-20 04:01:30
Duration = year (date 2) - year (date 1) = 2013 - 2012 = 1 year
- Month (date 2) = month (date 1) and day (date 2) < day (date 1)
Duration (years) = year (date 2) - year (date 1) - 1
Example 3.a:
Date 1: 2012-02-29
Date 2: 2014-02-28
Duration = year (date 2) - year (date 1) - 1 = 2014 - 2012 - 1 = 1 year
- Month (date 2) > month (date 1)
Duration (years) = year (date 2) - year (date 1)
Example 4.a:
Date 1: 2012-03-10 11:16:02
Date 2: 2013-08-15 21:34:16
Duration = year (date 2) - year (date 1) = 2013 - 2012 - 1 year
Example 4.b:
Date 1: 2012-02-29 10:18:56
Date 2: 2014-03-01 19:02:34
Duration = year (date 2) - year (date 1) = 2014 - 2012 = 2 years
Note: Because there is no February 29 in 2014, the number of years can only change when the date reaches March 1, the first date in 2014 that surpasses the month and day of date 1 (Feburary 29).
A month in CQL is defines as the duration of any time interval which starts at a certain time of day at a certain calendar day of the calendar month and ends at:
- The same time of day at the same calendar day of the ending calendar month, if it exists
- The same time of day at the immediately following calendar date of the ending calendar month, if the same calendar date of the ending month in the ending year does not exist.
Notes: When in the next calendar year the same calendar date does not exist, the ISO states that the ending calendar day has to be agreed upon. The above convention is used in CQL as a resolution to this issue.
- Day (date 2) >= day (date 1)
Duration (months) = (year (date 2) - year (date 1)) * 12 + (month (date 2) - month (date 1))
Example 1.a:
Date 1: 2012-03-01 14:05:45
Date 2: 2012-03-31 23:01:49
Duration = (year (date 2) - year (date 1)) * 12 + (month (date 2) - (month (date 1))
= (2012 - 2012) * 12 + (3 - 3) = 0 months
Example 1.b:
Date 1: 2012-03-10 22:05:09
Date 2: 2013-06-30 13:00:23
Duration = (year (date 2) - year (date 1)) * 12 + (month (date 2) - (month date 1))
= (2013 - 2012) * 12 + (6 - 3) = 12 + 3 = 15 months
- Day (day 2) < day (date 1)
Duration (months) = (year (date 2) - year (date 1)) * 12 + (month (date 2) - month (date 1)) - 1
Example 2:
Date 1: 2012-03-10 22:05:09
Date 2: 2013-01-09 07:19:33
Duration = (year (date 2) - year (date 1)) * 12 + (month (date 2) - month (date 1)) - 1
= (2013 - 2012) * 12 + (1 - 3) - 1 = 12 - 2 - 1 = 9 months
In CQL, a week is defined as a duration of any time interval which starts at a certain time of day at a certain calendar day at a certain calendar week and ends at the same time of day at the same calendar day of the ending calendar week. In other words, a complete week is always seven days long.
- Duration = [date 2 - date 1 (days)] / 7
Example 1:
Date 1: 2012-03-10 22:05:09
Date 2: 2012-03-20 07:19:33
Duration = [# days (month (date 1)) - day (date 1) + # days (month (date 1) + 1) + #days (month (date 1) + 2) + ... + # days (month (date 2) - 1) + day (date 2)] / 7
= (20 - 10) / 7 = 10 / 7 = 1 week
In CQL, a day is defined as a duration of any time interval which starts at a certain calendar day and ends at the next calendar day (1 second to 23 hours, 59 minutes, and 59 seconds).
The duration in days between two dates will generally be given by subtracting the start calendar date from the end calendar date, respecting the time of day between the two dates.
- Time (date 2) < time (date 1)
Duration = [date 2 - date 1 (days)] - 1
Example 1:
Date 1: 2012-01-31 12:30:00
Date 2: 2012-02-01 09:00:00
Duration = 02-01 - 01-31 - 1 = 0 days
- Time (date 2) >= time (date 1)
Duration = date 2 - date 1 (days)
Example 2:
Date 1: 2012-01-31 12:30:00
Date 2: 2012-02-01 14:00:00
Duration = 02-01 - 01-31 = 1 day
In CQL, an hour is defined as 60 minutes. The duration in hours between two dates is the number of minutes between the two dates, divided by 60. The result is truncated to the unit.
-
Example 1:
Date 1: 2012-03-01 03:10:00
Date 2: 2012-03-01 05:09:00
Duration = 1 hour -
Example 2:
Date 1: 2012-02-29 23:10:00
Date 2: 2012-03-01 00:10:00
Duration = 1 hour -
Example 3:
Date 1: 2012-03-01 03:10
Date 2: 2012-03-01 04:00
Duration = 0 hours
In CQL, a minute is defined as 60 seconds. The duration in minutes between two dates is the number of seconds between the two dates, divided by 60. The result is truncated to the unit.
-
Example 1:
Date 1: 2012-03-01 03:10:00
Date 2: 2012-03-01 05:20:00
Duration = 130 minutes -
Example 2:
Date 1: 2012-02-29 23:10:00
Date 2: 2012-03-01 00:20:00
Duration = 70 minutes