[QRDA-1125] Guidance on use of 'offset' during daylight saving Created: 02/03/23 Updated: 03/02/23 Resolved: 03/02/23 |
|
| Status: | Resolved |
| Project: | QRDA Issue Tracker |
| Component/s: | Implementation Guidance |
| Type: | Question/Guidance | Priority: | Moderate |
| Reporter: | Isbelia Briceno | Assignee: | Yan Heras |
| Resolution: | Resolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
In 2022 DST happened in Mar 13, 2022 and Nov 6, 2022. Can you please provide guidance about the proper way to include UTC offset ( assuming QRDA file includes UTC Time Zone Offset in Datetimes) when the QRDA includes data elements that happened before and after DST. Example: ICU location times: Based on the times (without UTC offset), ICU location is NOT during the 'day or day after admission'. However, when the UTC offset is added as shown below (due to DST on 3/13), and after the times are truncated, the ICU location start time is 'moved' to 3/13 and it is evaluated by CMS as being 'the day or day after admission' for CMS108v10. This is how the offset is included in the QRDA file (offset changed from -0500'to -0400 after 3/13 due to DST). The files include datetimes before and after DST: Inpatient encounter times: ICU location
Your guidance is greatly appreciated. |
| Comments |
| Comment by Isbelia Briceno [ 02/22/23 ] |
|
yanheras thank you for the response. |
| Comment by Yan Heras [ 02/22/23 ] |
|
Hi isbelia, It is the intent of the measure that both of the two scenarios you have described should not meet the denominator exclusion. However, scenario 1 now meets denominator exclusion due to how this piece of measure logic was written in CMS108v10. This is a known issue that will also apply to CMS108v11.
The measure logics around "Location.locationPeriod starts during Interval[start of QualifyingEncounter.relevantPeriod, Global."ToDate" ( start of QualifyingEncounter.relevantPeriod + 2 days ) )" will be __ revised to address this issue, however, this particular revision will not occur until the 2025 Annual Update. Hope this address your question. |
| Comment by Isbelia Briceno [ 02/20/23 ] |
|
Understandable, thank you for the update. |
| Comment by Yan Heras [ 02/20/23 ] |
|
Isbelia, there is a meeting scheduled this Wed. afternoon to discuss this further with the measure developers and receiving systems, we won't have update on this until then. I think any potential updates related to addressing edge cases like this will most likely inform future improvement rather than affecting the current submissions. |
| Comment by Isbelia Briceno [ 02/20/23 ] |
|
Have you received any updates that can be shared? One more week before submission deadline, your guidance is greatly appreciated. |
| Comment by Yan Heras [ 02/16/23 ] |
|
Hi Isbelia, we are still discussing with the measure developers. Thanks for your patience. |
| Comment by Isbelia Briceno [ 02/16/23 ] |
|
Any update about our question? |
| Comment by Yan Heras [ 02/14/23 ] |
|
Thank you. I see what you are asking now and will provide an update as soon as possible. |
| Comment by Isbelia Briceno [ 02/14/23 ] |
|
Thank you for sharing HQR team feedback. However, we already knew how HQR processed this scenario as we received that outcome during our submission testing. Our request for guidance/clarification is related to the fact that when truncating a date/time to the day, it generates different outcomes due to the shift of the date from the input date/time . Similar to https://oncprojectracking.healthit.gov/support/browse/CQM-4581. For example, if the ICU start time was 2022/03/14 01:47:00 (instead of 2022/03/14 00:47:00, <low value="20220314014700-0400"/>, then ICU start date time is 3/14 00:47:00 (after converted to -0500). and it would not qualify for the 'Location.locationPeriod starts during Interval[start of QualifyingEncounter.relevantPeriod, Global."ToDate" ( start of QualifyingEncounter.relevantPeriod + 2 days ) )'
|
| Comment by Yan Heras [ 02/14/23 ] |
|
Hi Isbelia, As noted earlier, the format for sending datetimes before and after DST that you provided is correct. The HQR team provided details on how this would be processed given your example. For this logic in CMS108v10 : Location.locationPeriod starts during Interval[start of QualifyingEncounter.relevantPeriod, Global."ToDate" ( start of QualifyingEncounter.relevantPeriod + 2 days ) ) After the timezone offsets are normalized and the times are truncated, the Interval is (3/12 04:15:00-0500, 3/14 00:00:00-0500) and the ICU start date time is 3/13 23:47:00 (after converted to -0500).
|
| Comment by Isbelia Briceno [ 02/13/23 ] |
|
Hello yanheras, any feedback from HQR? |
| Comment by Yan Heras [ 02/09/23 ] |
|
Hi Isbelia, The format for before and after that you provided above look right. We are looking for some implementation details from HQR that might be helpful to share. |
| Comment by Isbelia Briceno [ 02/09/23 ] |
|
Thanks yanheras. Your prompt feedback would be greatly appreciated as submission deadline is approaching. |
| Comment by Yan Heras [ 02/07/23 ] |
|
Hi Isbelia, We are checking with HQR and TJC implementation and will keep you updated. |
| Comment by Isbelia Briceno [ 02/07/23 ] |
|
Can we please get an update on this question? Your guidance will help us to complete our 2022 reporting period submission. Thanks! |
| Comment by QRDA-ICF [ 02/04/23 ] |
|
Thank you for submitting a ticket to the QRDA JIRA Issue Tracker. Our experts are reviewing your ticket and will provide feedback as soon as possible. Thank you for your patience. |