Thank you for your follow-up question.
Yes, you are correct that the timing calculation here uses “interval” operator. However, a key word “day of” is applied in the “1 day or less on or after day of start”, where it is counting the calendar by day not by hour. Therefore, the = Interval [global.”ToDate”(04/05/2019 10:00 AM), global.”ToDate”( (04/05/2019 10:00 AM + 2 day)), means the Comfort measures starts from any time on the day of admission (including prior to admission time) to 1 day after admission datetime and will qualify for the condition.
Your example should return True as Bonnie shows.

Thanks for the explanation. It seems however the eCQMs may not be using the same method of timing calculations in different elements within the measures.

Could you help explain what would be the result for the following logic in the example provided below?

VTE-1

Intervention Comfort Measures on Day of or Day After Start of Hospitalization

        "Encounter With Age Range and Without VTE Diagnosis or Obstetrical Conditions" QualifyingEncounter

               with "Intervention Comfort Measures" ComfortMeasures

                              such that Coalesce(start of ComfortMeasures.relevantPeriod, ComfortMeasures.authorDatetime)1 day or less on or after day of start of Global."Hospitalization"(QualifyingEncounter)

 __ 

Example 2

Inpatient start: 04/05/2019 10:00 AM
Comfort measures start: 04/05/2019 4:00 AM (comfort measures starts before inpatient start)

 If you apply the interval calculation as you have described above, I would think it would evaluate to

= Interval [04/05/2019 10:00 AM, (04/05/2019 10:00 AM *+ 1*)]

= Interval [04/05/2019 10:00 AM, (04/*06*/2019 10:00 AM)]

Which means if the Comfort Measures starts on or after 04/05/2019 10:00 AM and on or before 04/06/2019 10:00 AM then this logic should return true.

However, in this example the Comfort Measure Start is not in this range, so it should return false.

The Bonnie tool returns true. That would mean that it is not following the interval calculation method described above for this logic. In which case it would mean that different logic elements are expecting different ways of calculating the timing but no specific guidance is provided for calculation of each one.

What is the expectation for this type of calculation? How will TJC and CMS (QualityNet) calculate this? And if there is an implicit assumption for different calculation methods for timing statements in different logic elements how can the community know what those assumptions are? This could lead to a lot of confusion.

Thanks in advance for your review.

We continue to investigate the issue noted in your ticket and will provide a response as soon as we are able. Thank you for your patience.

To add to the commentary on CYPRESS-1737, I've further updated that ticket. Cypress does calculate according to the CQL, but the CQL in this case actually evaluates to false if there are greater than 60 minutes between the end of the first referenced interval and the start of the second referenced interval.
X "1 hour or less before or on" Y, according to CQL logic, indicates that X should be between Y and Y- 1 hour, so if X is 61 minutes before Y, this would evaluate to false. This is how Cypress calculates this statement.

There is further CQL explanation of this type of logic here:
https://cql.hl7.org/02-authorsguide.html#timing-relationships

For reference - I have created a separate ticket - https://oncprojectracking.healthit.gov/support/browse/CQM-3642- for other similar time calculation issues.

Albert, as FYI - 

We have also logged the question to Cypress (Cypress QRDA Validation Utility) https://oncprojectracking.healthit.gov/support/browse/CYPRESS-1737 and the tool is evaluating the measure according the CQL guidance, following the 'hour' no 'minutes' calculation for ED end to IP start timing. 

We agree the 'intent' is to consider '60min', but the measures have been released using 'hour'. Therefore, changes on how to evaluate the timing calculation should be done directly in the measure CQL logic (replace 1 hour with 60min) in future releases. On previous submissions, the timing calculation has been done based on 'hour' guidance. 

Thanks.

Agree that AMI-8a and ED-2 have critical calculations that either require or suggest measurement in minutes rather than hours.  The other measures refer to an ED visit that occurs within an hour of pertinent inpatient visit when the critical measured events happen.  On these latter measures, the exact timing of the ED visit relative to the inpatient visit is less critical.

In the case of AMI-8a, it is clear that the calculation needs to be in minutes and <=90 minutes is the critical time factor for the PCI intervention.  Although the logic states "hour or less" it's clear that 60 minutes or less indicate the most recent ECG.

Will followup with input from measure developers and CQL experts.

I'm re-posting this comment for reference my the measure developers and CQL experts - I believe the following Denominator logic in AMI-8a falls in the same category as the ED Visit logic discussion above. Please consider both these items when reviewing the logic. Anxiously waiting for a response.

I'll ask the measure developers and CQL experts, but from what I see in the original ticket, the submissions are being made, or are planning on being made, in median hours, not median minutes.  Either way, it's important to avoid a submission that rounds all times down to the hour, allowing submitters to exceed the recommended time (an hour or less) by nearly double (less than two hours).

This type of ambiguity within the definition of the logic in the specifications and the clinical expectation is going to cause a lot of confusion and mismatched results when files are submitted to CMS and TJC.

Can someone clarify what CMS (QualityNet) is expecting - as in when a file submitted to CMS has an episode with 119 minutes (or 61 minutes) difference between end of ED and start of Inpatient, will QualityNet calculate it using minutes (and therefore remove the episode from the population) or will they calculate using hours (and therefore include the episode in the population)?

Everyone will also need to find out TJC expectations for the above since file are also submitted to TJC.

 Thank you for submitting your question. We will review your ticket and provide a response as soon as possible

I am looking forward to hear from the measure developers and CQL experts. If the intent of evaluating  'one hour or less' as '60min or less', then the specification should be '60 minutes or less' instead of 'one hour...'

CQL guidance:

'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'.

*Adding a Jira with previous guidance provided on this matter: https://oncprojectracking.healthit.gov/support/browse/CQM-2729

Thanks.

The measure does state "calculate duration in minutes", and the CQL instruction does state "1 hour = 60 minutes".  The highlighted CQL logic in the various measures state, variably "ends one hour or less" or "starts one hour or less".  This means 60 minutes or less.  The intent of the measure to calculate the time as less than one hour as an indicator of quality of care.  Because using the CQL method of calculating duration in hours truncates the results, allowing almost double the acceptable duration of the measure intent, this method is inappropriate.  I assert that Calculate Duration in Minutes is a more appropriate to meet the measure intent.

 I will forward this ticket to both the measure developers and the CQL experts for their awareness.

Hello Albert,

As a measure implementer, I would like to provide our feedback on this matter as we recently found some discrepancies among our evaluation of the logic and TJC measure evaluation (2019 reporting year submission):

The 'Rate Aggregation' statement refers to the duration of the ED encounter 'Calculate the ED encounter duration in minutes for each ED encounter in the measure population; report the median time for all calculations performed'. It does not seem that this guidance applies to the portion of the logic in question 'EDVisit.relevantPeriod ends 1 hour or less before or on start of Encounter.relevantPeriod'. That portion of the logic determines if the Inpatient encounter should be included in the population, it is not related to the median time calculation.
On the same page, ED-2 'rate aggregation' statement states 'Calculate the duration in minutes between the Decision to Admit time and the departure time for each ED encounter in the measure population; report the median time for all calculations performed.' No mention of the '1 hour or less...' logic either.

Even if the wording on the metadata section was intended to be applied to the CQL logic, historically the approach has been to follow the CQL logic, and if needed, the specifications would get updated in future releases to align with the intent of the measure. The guidance for the 'Hour' calculation is pretty clear and that is what has been followed so far.

If the intent is to do the calculation in 'minutes', the logic should be updated to account for it. However, as a measure implementer, we disagree with the expectation of having implementers 'changing' the evaluation of this portion of the logic '1 hour or less' to calculate it in minutes instead of hour. We support the update of the future specifications, but until then the evaluation should be based following the 'hour' calculation.

Thanks.

I agree that the logic and descriptions should be perfectly clear that the goal is <=60 minutes.  In the interim, I recommend changing the method of calculation to duration/interval in minutes and not in hours.

We, at the Joint Commission have also received the same disagreement/confusion comments from our data submitters regarding this issue which "hour" being written on eCQM when minutes are intended.   We'd like to support Manish's suggestion to modify the logic as <=60minutes. 

Thanks Albert.

For reference by the measure development team -

A similar check is there in the AMI-8a measure in the Denominator for ECG -

The specification states to check for 1 hour or less. So we are using the CQL "hour" function logic according to which 119 minutes (1 hour and 59 minutes) gets truncated to 1 hour and the statement would return true. That result would be different if the specification used the function in minutes - 60 minutes or less. In this case 119 minutes would return false.

I agree that the specification should be clear the the method of calculation accurately capture the intent, which is that the duration be less than one hour (or other intended duration limit).  This ticket has been assigned to the measure development team for clarification and action.  I may also warrant broader discussion given the number of measures it applies to.

Thanks for your response Albert.

A follow up question - The check for the ED visit end date/time to be 1 hour or less on or before start of inpatient encounter is used in several other measures besides the ED measures in the following functions -

The measures in which it is used besides the ED measures are the following 9 measures - 

All STK measures (6)

All VTE Measures (2)

AMI-8a measure (1)

Is it the expectation that anywhere we do this ED visit calculation we need to always calculate time in minutes (ED Visit. relevant period ends <= 60 minutes on or before start of Encounter.relevant period)  instead of the time in hours as specified in the eCQM logic? I would think we would want to do this consistently across ED and all other measures it is used.

Also, if we do need to use the time calculation in minutes I would make a recommendation for the eCQM developers to update the specification to reflect the time calculation in minutes instead of hours.

Thanks!

The goal is <= 1 hour, but it is calculated in minutes, according to the rate aggregation statement.  The intent is that the duration is within an hour, so using a method that allows for the duration to be almost two hours but be reported as one hour does not meet the intent of the measure.  Therefore, the duration should be calculated in minutes.

A proposed solution has been provided.  Please validate this solution for the submitter.

I will change the issue type for you.  The rate aggregation statement states "Calculate the ED encounter duration in minutes for each ED encounter in the measure population", therefore you should use the CQL instruction for Calculating Duration in Minutes.  In your example, the interval/duration would be > 60 minutes.

I need to change the Issue Type of this item to - EH/CAH eCQMs/Logic/Intent/Data Elements/Value Set. I have not found out how I can do that. I tried to clone this item but even in the clone I could not modify. You can close the clone - https://oncprojectracking.healthit.gov/support/browse/CQM-3626.