In QRDA, CMD is a calculated field. It should be calculated for all matching medication events after filtering. The current version of the QDM makes it look like an attribute on a particular event rather than a function over a set of events. For example:

“Medication, Active: Warfarin (cumulative medication duration >= 180 day(s))” starts before start of “Measurement Period”

According to the currently defined QDM order of operations, the above approach would filter for events that contain a CMD and then remove any that did not occur during the measurement period. This conflicts with the expected behavior of cumulative medical duration calculations.

Accepted Interim Solution for 2014

An ideal solution is not currently possible, as it cannot be expressed in HQMF, and HQMF (and possibly other standards) cannot be modified in the timeframe needed. That being the case, we propose this interim solution.

The basic solution takes this form:

Sum > 180 day(s) of: "Medication, Active: Warfarin (cumulative medication duration)" during "Measurement Period"

You're not constrained to during the measurement period. You can also use other timing expressions. For example:

Sum > 120 day(s) of: "Medication, Active: Warfarin (cumulative medication duration)" < 6 month(s) starts before start of "Measurement Period"

The basic concepts are:

1. We keep the "cumulative medication duration" attribute, which on a single instance of an event represent the CMD for that instance
2. We use the SUM operator to get the total CMD for a set of events. We will define SUM such that it does not double-count overlaps when summing CMD.
3. So the constraint ("> 180 day(s)") needs to be at the level of the SUM operator (not within the attribute parentheses).

The benefits of this solution are:

1. It fixes the existing syntax issue without reducing the original functionality
2. It's expressible in QDM syntax now
3. It's expressible in HQMF R2 now

The limitations of this solution are:

1. You cannot "prorate" the CMD of medication events that overlap your period of interest. Whatever events are captured by your timing logic will contribute their CMD for the whole event to the aggregate calculation.
2. Patient-reported medications will not be represented in the calculation (this was also a limitation of the last solution)
3. You cannot group medications using different value sets together (e.g., using a union) and get CMD for the whole group. Each CMD calculation is limited to the set of events represented by one QDM element with one value set.

Please see the attached document, "CMD_2014-May-21.pptx" for the overview.

Previously Proposed Solution

While the following solution is very promising, it is not expressible in HQMF.

When measure authors talk about cumulative medication duration they are usually talking about days covered. As noted in the QDM User Group, it is desirable to be able to indicate the events qualifying for the calculation, as well as the period the calculation should cover.

The following example was discussed as a proposed representation of CMD:

# assign variable $med_days to the set of days that the medication was active
$med_days = days of: "Medication, Active: Drug" overlaps "Measurement Period"

# get CMD by counting the subset of $med_days that was during the measurement period
Count Unique < 90 of: $med_days during "Measurement Period"

Please note the following:

Calculating CMD
CMD is a calculation based on metadata such as dose, frequency, count, etc. As such, CMD can only be calculated on datatypes for which the corresponding QRDA Cat I records contain the needed metadata (e.g., Medication, Administered, Medication, Order, Medication, Activity).

Participating Medication Events
In general, Medication events are defined loosely and can include patient-reported medications. For the purposes of calculating CMD, only those events containing the necessary metadata will be used in calculations. This means that most patient-reported meds will not be represented in the CMD calculation.

Gaps in Medication, Active
A single Medication, Active event should represent a continuous block of time for which a medication is active. If a patient goes off a medication and then goes back on, this should result in a separate Medication, Active event.

Groups of Medication Datatypes
It should be possible to perform the calculation over the union of several data elements (to represent CMD for a group of medications).

Timing Constructs
In the examples above, the timing operators (overlaps and during) represent a common use case, but measure developers can use whatever timing operators fit the needs of the measure (for example, calculating CMD for the 6 months prior to the measurement period).

Count Unique
This solution uses the count unique function. This function is not yet in QDM, but has been proposed in QDM-6.

HQMF Representation
There is some risk that this solution cannot be properly represented in HQMF. This solution works because it treats days like events (getting sets of days, reducing to a subset, counting them, etc). HQMF may not be flexible enough to allow this. Further investigation is required.

Previously Proposed Solution

NOTE: The QDM User Group expressed concerns about this in the April 16, 2014 User Group meeting. Please see comments (dated 16/Apr/14) for more details.

While the QDM could take a more detailed approach to CMD (such as representing the individual components of the calculation), the most pragmatic approach is to fix the original syntactical error. While attributes are evaluated against single instances of events, functions are executed over a set of events. Therefore, the best approach to representing CMD over a set of events is to use a function. For example:

AND: DURATION >= 180 day(s) of: "Medication, Active: Warfarin" during "Measurement Period"

The DURATION function (name up for discussion), when applied to Medication datatypes, would represent a Cumulative Medication Duration calculation. The function would be defined such that it should not double-count overlapping days in medication activity.

This would still potentially require changes in HQMF (perhaps a new HQMF function) and QRDA (to ensure the necessary data is provided to allow the calculation), but each of these changes would go through the change request process for their respective governing bodies.

This new DURATION operation could also provide some value in other cases. For example, we could define it such that it sums up all of the "length of stay" values when applied to an Encounter, Active or Encounter, Performed (once again, taking overlaps into account). This QDM recommendation, however, pertains only to the application of the function over Medication datatypes.