Uploaded image for project: 'CQL Issue Tracker'
  1. CQL Issue Tracker
  2. CQLIT-102

Potential use of "Time" instead of "DateTime" data types in calculations

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • None
    • Hide
      The impact will occur when time values get mixed up with Date Time values, and patients have negative values because they crossed the midnight boundary. In general "Time" is a poorly designed data type and should not ever be used because of these kinds of issues.
      Show
      The impact will occur when time values get mixed up with Date Time values, and patients have negative values because they crossed the midnight boundary. In general "Time" is a poorly designed data type and should not ever be used because of these kinds of issues.
    • Other

      For use of most calculations that use “Duration Between” (or Difference Between) these functions accepts both “DateTime” data types AND “Time” data types. However, for these eCQMs, the “Time” data type should never be used, only DateTime. I cannot find any circumstance where the “Time” data type is appropriate instead of only allowing the “DateTime” type. For example, from the HL7 CQL Specification document:

      “9.8.7 Duration

      Signature:

      duration between(low DateTime, high DateTime) Integer

      duration between(low Time, high Time) Integer

      Description:

      “The duration-between operator returns the number of whole calendar periods for the specified precision between the first and second arguments. If the first argument is after the second argument, the result is negative. The result of this operation is always an integer; any fractional periods are dropped.

      For DateTime values, duration must be one of: years, months, weeks, days, hours, minutes, seconds, or milliseconds.

      For Time values, duration must be one of: hours, minutes, seconds, or milliseconds.

      If either argument is null, the result is null.”

      In the measure specifications, the potentiual use of the “Time” data type ought to almost never be allowed due to the fact that it is a really useless data type that is never better than the “DateTime” data type and almost always introduces the possibility of complcations from the midnight transition and timezone issues.

      However, I cannot find anything in the measure specification documents that limit data elements to be the “DateTime” type and not the “Time” type. Is this somehow limited by the QDM? If this is not restricted, then the measure specifications should technically support the use of either DateTime or Time elements, and when the “Time” type is used, it looks like many functions will fail to work as intended.

      For example, when calculating this from CMS#32, patients that arrive to the ED at 11:30 PM and are admitted to Inpatient at 12:10 AM, will have a huge negative value of (-3560 minutes) instead of the intended value of (40 minutes).
      Measure Observation

      Median (
      /Time from ED visit arrival to ED departure for patients not admitted to inpatient/

      "Arrival to Observation Order or Departure Time"(Encounter)

      )

      Arrival to Observation Order or Departure Time(Encounter "Encounter, Performed")

      duration in minutes of Interval ["Arrival Time"(Encounter), Coalesce("Observation Services Order"(Encounter).authorDatetime, "Departure Time"(Encounter))]

      Notice that the comment Explicitly says “Time” and not “DateTime”, further the inputs to the function are explicitly called “Arrival Time” and “Departure Time”, which also encourages the use of “Time” and not “DateTime”.

      I would recommend adding some code to these functions to enforce the use of only “DateTime” data types, and to change the comments and the other function and parameter names to suggest that these values ought to only be “DateTime” and not “Time”

            bryn_rhodes Bryn Rhodes
            cquinlan Carsten (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: