Transfer Delay (Critical Care): Difference between revisions

From CCMDB Wiki
Jump to navigation Jump to search
Line 32: Line 32:


{{DT|
{{DT|
I have not yet added this part to the query. Does this just mean that before Oct 1 2020 it was reported this way, or is it still reported this way for values from before? If the latter, would it make sense to generate these values and update the old transfer ready dttms to this? If I include it in the question this will forever run slowly. Having said that... the same is true for the other values: I use an iif function to determine if we are before or after, and functions like that are slow. Should we automatically generate transfer ready tmp entries for the old data once and then not have to worry about this again? Especially for the second part, we have nothing to lose, the data would remain the same, just stored in new place. For the first part we would change data, but if you have always reported it that way that is just as well.  
* I have not yet added this part to the query. Does this just mean that before Oct 1 2020 it was reported this way, or is it still reported this way for values from before? If the latter, would it make sense to generate these values and update the old transfer ready dttms to this? If I include it in the question this will forever run slowly. Having said that... the same is true for the other values: I use an iif function to determine if we are before or after, and functions like that are slow. Should we automatically generate transfer ready tmp entries for the old data once and then not have to worry about this again? Especially for the second part, we have nothing to lose, the data would remain the same, just stored in new place. For the first part we would change data, but if you have always reported it that way that is just as well.  
**I have checked my program and the substitution applies only when the entry in the transfer ready dttm field is just date which presumably  when the entry of dt and tm are in  separate two fields.  now when the entry became in the format dttm , the substitution no longer happened. so this was a long time ago then, even before Oct 2020.    what was the entry when there is no time?  00:00??  
**I have checked my program and the substitution applies only when the entry in the transfer ready dttm field is just date which presumably  when the entry of dt and tm are in  separate two fields.  now when the entry became in the format dttm , the substitution no longer happened. so this was a long time ago then, even before Oct 2020.    what was the entry when there is no time?  00:00??  
**  if you want to do the old data once, I am OK with that.   
**  if you want to do the old data once, I am OK with that.   

Revision as of 15:57, 2022 June 28

Transfer Delay is the difference between Dispo_DtTm and #Transfer Ready DtTm in use at different times in decimal days.

Indicators
Indicator: Transfer_Delay_CC
Created/Raw: created
Program: Critical Care and Medicine
Start Date: 1999-01-15
End Date:
Reports: Critical Care Program Quality Indicator Report, Directors Quarterly and Annual Report (Critical Care), HSC ICUs Data by Patient


  • Cargo


  • SMW:
    • "created" is not in the list (Created, Raw) of allowed values for the "IndicatorCreatedRaw" property.
  • Categories
  • Default form:

There is a similar concept in medicine, Transfer Delay (Medicine).

It is stored in the Transfer_Delay_CC field in Created_Variables_CC_2021 table.

Use

Transfer Ready DtTm in use at different times

Admit DtTm or Dispo DtTm < 2020-10-01 00:00

Calculation for reporting when transfer time missing

Before Oct 1,2020 -The following definitions are used by Julie in reporting from SAS, and by centralized_data_front_end.accdb to calculate the created_variables query.

  • if discharge time < 1000 HR then dummy=0001 HR (12:01 am),
  • else if discharge time >= 1000 HR dummy=1000HR (10:00 am)

This was based on Critical Care Vital Sign Monitor.

This is as per approval by Dr. Dan Roberts.

Starting Oct 1,2020, transfer ready time is always present.


  • I have not yet added this part to the query. Does this just mean that before Oct 1 2020 it was reported this way, or is it still reported this way for values from before? If the latter, would it make sense to generate these values and update the old transfer ready dttms to this? If I include it in the question this will forever run slowly. Having said that... the same is true for the other values: I use an iif function to determine if we are before or after, and functions like that are slow. Should we automatically generate transfer ready tmp entries for the old data once and then not have to worry about this again? Especially for the second part, we have nothing to lose, the data would remain the same, just stored in new place. For the first part we would change data, but if you have always reported it that way that is just as well.
    • I have checked my program and the substitution applies only when the entry in the transfer ready dttm field is just date which presumably when the entry of dt and tm are in separate two fields. now when the entry became in the format dttm , the substitution no longer happened. so this was a long time ago then, even before Oct 2020. what was the entry when there is no time? 00:00??
    • if you want to do the old data once, I am OK with that.
  • SMW


  • Cargo


  • Categories

Not tested yet, but the code to update this would be something like

Update L_Log
Set Transfer_Ready_DtTm = Transfer_Ready_DtTm + iif(timevalue(Dispo_DtTm) < #10:00#, #12:01#, #10:00#)
Where timevalue(Transfer_Ready_DtTm) = 0

Admit DtTm or Dispo DtTm >= 2020-10-01 00:00

Background

Why collect per boarding loc when we only report per admission?

To make it easier for data collectors. This way, collectors don't have to try and go back and figure out if there was or was not a transfer ready in a prior location. They only need be concerned about the notes and orders from THIS boarding loc.

Reporting of Transfer Delays

  • Reported as count, Mean (average), Sum (Total), and Cumulative counts and percentage
  • A - Determine the patients who left alive to a lower level of care in the Dispo field and
    • A1 - Have transfer delays
    • A2 - Have no transfer ready dttm - assign them as zero transfer delay
    • Total True delays = Transfer delays from A1 + zeroes from A2 ; Total N = A1 + A2; Average True Delays=Total True Delays / Total N
    • Total transfer delays > 2 hours - sum up those patients from A1 but excluding those with transfer delays <= 2 hours and compute the Average.
    • Distribution of true transfer delays - counts, cumulative counts and percentage
      • zero
      • <= 4 hours
      • >4h - 12h
      • >12h - 1d
      • >1d - 2d
      • >2d - 3d
      • >3d - 7d
      • >10d - 14d
      • >10d
  • B - Determine and report the number of patients with transfer delays who had left alive and went to same level of care in the Dispo field .
  • C - Determine and report the number of patients with transfer delays who died in the Dispo field before going anywhere.

JALT one of the DC mentioned in the TASK meeting that GRA Med patient with transfer ready dttm and went to GRA ICU should be considered as bed wasted. In the current process, all with transfer ready dttm are included as bed wasted regardless where the patient went or died. but in this new way of reporting, this is not the case. can we discuss again which is the final way? --JMojica 13:28, 2022 June 24 (CDT)

  • SMW


  • Cargo


  • Categories

IICU and H6 Reporting

For the ICU annual and quarter reports, the transfer ready delay to the IICU and to HSC H6 (LTV) are reported separately from the transfer delay to the other Wards and home. Thus two derived delay variables, namely:

  1. to HSC IICU/H6, and
  2. to other wards/Home (including nursing home/long term care facility)

The Dispo location will be used to define the destination. As per Dr. Garland & Dr. Paunovic.

SAS Program

  • S:\MED\MED_CCMED\Julie\SAS_CFE\CFE_macros\logphi_TR.sas
    • macro %CC_tready
  • S:\MED\MED_CCMED\Julie\SAS_CFE\CFE_macros\prep_Tmp_BoardServiceTransfer.sas (macro %boardtransf)

Data use

Data Integrity Checks (automatic list)

 AppStatus
Query check long transfer delayCCMDB.accdbneeds review

related fields

Related Articles

Related articles:

Legacy

Legacy Content

This page contains Legacy Content.
  • Explanation: xxx
  • Successor: No successor was entered