Negation in QDM

In QDM 4.2, negation is specified using a "not done" qualifier within the QDM Data Element. In effect, this means that every QDM Data Element is specifying 4 critical peices of information:

Category - Medication, Encounter, etc.
Data Type - Administered, Performed, etc.
Value Set - Antithrombotic, Inpatient, etc.
Negation - Whether the element is being asserted positively or negatively

If the "not done" qualifier is not provided, the data element is being asserted positively. For example:

"Medication, Administered" using "Antithrombotic Therapy"

And the negative element:

"Medication, Administered not done: Medical Reason" for "Antithrombotic Therapy"

Using QDM 4.2 directly in CQL, the equivalent expressions are

define "Antithrombotic Administered":
    ["Medication, Administered": "Antithrombotic Therapy"] Medication
        where Medication.negationRationale is null

The filter on negationRationale is required because the unqualified retrieval returns all "Medication, Administered" for the value set "Antithrombotic Therapy" whether they were negated or not. To limit to only those that were not negated requires filtering to only those records where the negationRationale is not present.

The equivalent negative expression is then:

define "Antithrombotic Not Administered":
    ["Medication, Administered": "Antithrombotic Therapy"] Medication
        where Medication.negationRationale in "Medical Reason"

This approach is problematic because of the required filter on every access to any QDM data element.

Given that each element needs to specify the 4 peices of information (Category, DataType, ValueSet, Negation), there are a number of potential approaches to address this problem. Each approach differs in the amount of information that is specified in the name of the CQL Data Type.

Single Negation Type

The first approach involves defining a single negation type called "Not Done" which would enable the negation of all QDM types with a single Data Type. The equivalent positive assertion using this approach is then:

define "Antithrombotic Administered":
  ["Medication, Administered": "Antithrombotic Therapy"]

No filter is required because negative statements are no longer included in the results, they must be explicitly asked for using the "Not Done" type:

define "Antithrombotic Not Administered":
    ["Not Done": "Medication, Administered"] NotDone
        where NotDone.actionCode in "Antithrombotic Therapy"
            and NotDone.negationRationale in "Medical Reason"

However, this approach is still problematic because it only specifies 3 of the 4 critical peices of information within the retrieve (Category, Data Type, and Negation in this case).

Negation Type Per Data Type

Another approach involves defining a negation type for each QDM "data type" (e.g. "Not Administered", "Not Performed", etc.). This would enable negation to be expressed in a similar way, but with potentially more applicable attribute names. The positive assertion is the same, but the negative assertion becomes:

define "Antithrombotic Not Administered":
    ["Not Administered": "Medication"] NotAdministered
        where NotAdministered.medicationCode in "Antithrombotic Therapy"
            and NotAdministered.negationRationale in "Medical Reason"

As with the Single Negation Type, this approach is still problematic because it only allows 3 of the 4 required peices of information (Category, Data Type, and Negation).

Negation Type Per Category and Data Type

Another approach involves defining a negation type for each appropriately negatable combination of QDM Categories and Data Types (e.g. "Medication, Not Administered", "Encounter, Not Performed"). This would enable negation to be expressed without the need for an additional filter (because it allows all 4 required pieces of information to be expressed within the retrieve). The positive assertion is the same, but the negative assertion becomes:

define "Antithrombotic Not Administered":
    ["Medication, Not Administered": "Antithrombotic Therapy"] NotAdministered
        where NotAdministered.negationRationale in "Medical Reason"

This approach is the closest to what QDM 4.2 with HQMF currently does, and has the added advantage of being the only approach that enables tooling to ensure that all 4 required pieces of information can be specified within the retrieve.

Note also that although this approach does involve a separately identifiable type in CQL for each negatable combination of category and data type, it does not necessarily need to be described that way in QDM. It could be described generically, the way the "not done" negation pattern is currently described in QDM.

In addition, with some modifications to the CQL-to-ELM translator (not to CQL itself), we could expand the model info to enable the description of these "negation" types without actually defining any new types within the underlying QDM. This could be accomplished by the use of the "profileId" in the model info, and exanding the model info to allow the specification of a filter for each profile.

With some additional modification to the underlying ELM, this aspect could also be made an explicit part of the Retrieve definition, further facilitating implementation (and aligning with a FHIR implementation as well).