Transfer Delay (Critical Care)

Data Element (edit)
Field Name:	Transfer Delay
CCMDB Label:	not stated
CCMDB tab:	not stated
Table:	Created_Variables_Common table
Data type:	number
Length:	single
Program:	Med and CC
Created/Raw:	Created
Start Date:	1999-01-15
End Date:	2300-01-01
Sort Index:	7

Transfer Delay is the difference between Dispo_DtTm and Transfer_Ready_DtTm in decimal days.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

Transfer Delay

Indicators
Indicator:	Transfer Delay
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:

• Categories

• Default form:

Before Oct 1, 2020, it is calculated by Created_Variables_Common_maker query and stored in Created_Variables_Common table in CFE.

Meaning of Transfer Delays (to a lower level of care)

• This is especially relevant given the start on October 1, 2020 of the the PatientFollow Project, where within a single hospital, patients who move from location to location at the same level of care (e.g. ICU or ward) have a single database record, but we keep track of Boarding Loc and Service tmp entry as they move from place to place.
• As described in Transfer Ready DtTm tmp entry, collectors make a notation about transfer ready in each separate boarding loc, looking solely at whether or not the patient was recorded as transfer ready from that location (i.e. collectors should not "carry over" knowledge about transfer readiness at prior boarding locs).
• BUT, when calculating "wasted days", Julie will only use the FIRST transfer ready date/time:
  • example 1: Mr. Jones spent 7 days in MICU and then directly transferred to SICU where he stayed another 7 days. On MICU day 3 a progress note said he was ready to go to ward, but he didn't. At no time during his SICU stay did any notes indicate transfer readiness. Julie will calculate this as 4 wasted MICU days, and 7 wasted SICU days.
  • example 2: Mr. Jones spent 7 days in MICU and then directly transferred to SICU where he stayed another 7 days. On MICU day 3 a progress note said he was ready to go to ward, but he didn't. On SICU day 1 a progress note indicates transfer readiness. Julie will calculate this as 4 wasted MICU days, and 7 wasted SICU days.
  • example 3: Mr. Jones spent 7 days in MICU and then directly transferred to SICU where he stayed another 7 days. On MICU day 3 a progress note said he was ready to go to ward, but he didn't. On SICU day 5 a progress note indicates transfer readiness. Julie will calculate this as 4 wasted MICU days, and 7 wasted SICU days.
  • ALL 3 of these examples have the same # of wasted days.

• QUESTION: Why record a transfer ready date/time from each boarding loc if we are only actually going to use the first of them?
  • ANSWER: 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.

Definition Details

• Transfer Delay Over 2 hours for Critical Care (ie subtract 2 hrs from transfer delay)

Use

• The purpose is to determine the amount of time the patient is occupying a bed in an ICU or an IICU or a High Observation ward or a regular ward setting when the patient is no longer needing that level of care (also refer as wasted bed) from the Transfer Ready DtTm until the Dispo DtTm.

Which Transfer Ready DtTm To Use?

Before Oct 1, 2020

• For each patient in ICU and Medicine ward, the transfer date and time is taken from the Transfer Ready DtTm field.

Starting Oct 1, 2020

• For each record and each boarding location in ICU and Medicine, the transfer date and time is taken from the Transfer Ready DtTm tmp entry.
• For each record, it is possible to have one or more entries of Transfer Ready DtTm corresponding to one or more boarding locations.
• if the patient moves to various locations, the first Transfer Ready DtTm from a Boarding Loc the same level of care will be used
  • For example, a Med patient stays in high obs bed and then move to regular ward bed and then another regular ward bed. There are two levels of care - one for high obs and another which is lower, for the regular ward. At least two Transfer Ready DtTm intent are expected here - first intent for high obs ready to go to a regular ward and the second intent is from a regular ward to be discharged to another lower level of care or home or PCH. Assuming that there are transfer orders both at regular ward 1 and regular ward 2 and both are with same level of care, the first Transfer Ready DtTm time will be used in calculating the wasted bed for that lower level of care. There will be another wasted bed to be calculated for the high Obs level of care from the Transfer Ready DtTm to the time the patient left the high obs bed (ie the Dispo DtTm or the next Boarding Loc start DtTm. The sum of the two scenarios will be the total wasted bed for that patient.
  • if the Med patient stays in more than one regular wards (or boarding location) or a CC patient stays in more than one ICU location (or boarding ICU location), all locations are considered with the same level of care, the wasted bed is calculated from the first Transfer Ready DtTm until Dispo DtTm.

IICU and H6 Reporting

For the ICU annual and quarter reports, the transfer ready delay to the IICU and to HSC H6 (LTV) will be reported separately from the transfer delay to the other Wards and home. This imply that in addition to the total transfer delay, there will be two more 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.

Calculation when transfer time missing

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.

Data use

• Avoidable Days (Critical Care)

Data Integrity Checks (automatic list)

	App	Status
Query check long transfer delay	CCMDB.accdb	needs review

related fields

• Arrive_DtTm
• Dispo_DtTm
• Transfer Ready DtTm tmp entry
• LOS
• Transfer Delay