Uploaded image for project: 'eCQM Issue Tracker'
  1. eCQM Issue Tracker
  2. CQM-560

How should length of stay be calculated?

XMLWordPrintable

    • Icon: EH/CAH eCQMs - Eligible Hospitals/Critical Access Hospitals EH/CAH eCQMs - Eligible Hospitals/Critical Access Hospitals
    • Resolution: Fixed
    • Icon: Major Major
    • Guidance
    • None
    • Hide
      Length of stay should be computed according to the guidelines on time intervals in the eCQM implementation guide. The issue you identified was a bug in the cypress code. Thanks.

      The cypress code has been fixed to correctly use the time units.

      https://github.com/pophealth/hqmf2js/blob/develop/app/assets/javascripts/patient_api_extension.js.coffee

      See line 21.
      Show
      Length of stay should be computed according to the guidelines on time intervals in the eCQM implementation guide. The issue you identified was a bug in the cypress code. Thanks. The cypress code has been fixed to correctly use the time units. https://github.com/pophealth/hqmf2js/blob/develop/app/assets/javascripts/patient_api_extension.js.coffee See line 21.
    • CMS100v1/NQF142, CMS102v1/NQF441, CMS104v1/NQF435, CMS105v1/NQF439, CMS107v1/NQF440, CMS108v1/NQF371, CMS109v1/NQF0374, CMS110v1/NQF0375, CMS111v1/NQF0497, CMS113v1/NQF0469, CMS114v1/NQF0376, CMS171v1/NQF0527, CMS172v1/NQF0528, CMS178v1/NQF0453, CMS185v1/NQF0716, CMS188v1/NQF0147, CMS190v1/NQF0372, CMS26v1/NQF0338, CMS30v1/NQF0639, CMS53v1/NQF0163, CMS55v1/NQF0495, CMS60v1/NQF0164, CMS71v1/NQF0436, CMS72v1/NQF0438, CMS73v1/NQF0373, CMS91v1/NQF0437, CMS9v1/NQF0480

      The QDM provides little guidance on the length of stay (LOS) attribute, defining it simply as "The difference of the admission date/time and the discharge date/time."

      Clinical Quality eMeasure Logic and Implementation Guidance v1.3 does not specifically address length of stay either but does go into very helpful detail in Appendix C regarding the interpretation of units of time.

      The use of the length of stay attribute in measures (e.g. length of stay <= 2 days, length of stay < 24 hours) is similar to the ranges used in date comparisons (e.g. <= 2 days starts before start of, < 24 hours ends before start of) so it seems reasonable that length of stay qualifiers would likewise use the unit-dependent calculations described in Appendix C.

      Examination of the Cypress 2.1.0 bundle, however, reveals that it always calculates length of stay the same way, regardless of the units specified in the measure criterion. Specifically, it subtracts the Encounter's start datetime from its stop datetime (both stored in milliseconds), divides by the number of milliseconds in 24 hours, and truncates the result to an integer, yielding a number with granularity of days but calculated in a manner closer to (but not quite the same as) the mechanism described for hours in Appendix C. This approach matches neither the method documented for days (the number of times midnight is crossed) nor the method documented for hours (which ignores seconds).

      Taking an example from the test deck, the Inpatient stay for STROKE ADULT B is "April 2nd, 2012 11:00 - April 5th, 2012 10:30". Here is the calculated length of stay for the three methods:

      • Days method: 3 days (# of times midnight is crossed)
      • Hours method: 71 hours (71.5 hours, truncated to 71)
      • Cypress method: 2 days (71.5 hours, divided by 24, truncated to 2)

      Please provide guidance on how length of stay should be calculated. Is it independent of the units specified in the measure criteria? Should it use the days or hours methods documented in Appendix C or should it use the Cypress approach?

        1. LengthOfStay.xlsx
          11 kB
          Jon Salmon

            saul.kravitz Saul Kravitz (Inactive)
            jon.salmon Jon Salmon (Inactive)
            Chris Millet ONC (Inactive), Saul Kravitz (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: