During the March 2015 QDM UG meeting, the UG accepted a solution for a single "Diagnosis" datatype for which "abatement datetime" can be used to determine the status. This solution removes the concept of "Inactive" status. See QDM-103 for more details.

This topic has been discussed in some user groups already. The following are excerpts from meeting minutes that may pertain to the discussion.

From the September 2014 QDM UG meeting minutes:

There were questions on whether ‘Inactive’ status was really needed; FHIR and QUICK do not represent those status. Would ‘Inactive’ be the same as ‘Resolved’?

Members also confirmed that having a single datatype, whose status can be tracked over time, would be very helpful.

From the October 2014 QDM UG meeting minutes:

Regarding the problem with Diagnosis, Active, there is confusion regarding whether it is when a condition is diagnosed, or when the condition first started (i.e., onset). The current model also doesn’t allow a Diagnosis, Active to be easily related to its corresponding Diagnosis, Resolved.

The question was raised regarding what Diagnosis, Inactive means. An example was given for an inflammatory bowel disease that has not abated, but is in remission. Also, in a clinical workflow, if a patient enters the ER with a heart attack, a nurse may 'inactivate' longitudinal problems (such a gout) on the problem list—since they are not the main concern at the moment. This is not likely the intent of Diagnosis, Inactive, however. One participant suggested that nuances like this are not helpful and should be avoided when possible. A question was asked whether the concept of inactive had to be carried forward (noting that it is not modeled in QUICK). One of the participants stated No.

There was continued discussion asking if moving to a single data type was a good idea, and whether there is a need for a status attribute (or if condition / diagnosis could be distinguished using the date attributes). One member suggested instead of Diagnosis, Resolved, have a single Diagnosis, Active datatype that has an onset and abatement date. Another member expressed concern with having ‘Active’ in the name, especially if a resolved diagnosis could be represented. The same member also suggested that ‘Diagnosis’ itself also wasn’t the correct terminology for the concept.

From the November 2014 QDM UG meeting minutes:

MITRE stated that there is concern with having conditionStatus as its own attribute, since EHRs might only store the most current value for that attribute. As a result, a Condition could have a conditionStatus value of resolved even though it was not yet resolved in the Encounter of interest for the measure.

Another participant stated that FHIR status and QDM status are very different. In FHIR, the status represents the status of the actual assertion. However, QUICK supports both the conditionStatus and status. A participant stated that FHIR might expect the status to be reflected in the code– e.g., cancer in remission, as a pre-coordinated code as opposed to an attribute reflecting the condition’s active/inactive/resolved status.

From a December 2014 meeting with a vendor representative:

We recently met with a member of the vendor community to discuss the representation of diagnoses/conditions in QDM and EHRs. The following is a brief summary of the points we discussed and the data available in one of the nation's leading EHR implementations.

The notion of condition status (active, resolved, etc.) is important, but only has value within the context of time. For that reason, a measure author shouldn't ask "is this condition active", but rather, should always ask "was this condition active on this date" (or "during this interval"). How could QDM model Condition so that the right question can be asked?

The current distinction between active, inactive, and resolved status is not practical. In practice, EHRs usually only support active/inactive or active/resolved (which mean the same thing to them). This notion corresponds fairly well with FHIR's intentional ambiguity regarding the definition of abatement. If QDM supports more precise concepts, vendors will either ignore unsupported statuses or map them to the closest supported status.