Transfer Delay (Medicine)

Transfer Delay is the difference between Dispo_DtTm and #Time patient is ready for transfer in decimal days. Other terms use to call it are Beds Occupied by transferable patients, Wasted Beds, Avoidable Days.

Indicators
Indicator:	Transfer Delay (Medicine)
Created/Raw:	Created
Program:	Medicine
Start Date:	2003-10-01
End Date:
Reports:	Directors Quarterly and Annual Report (Medicine)
Data Dependencies(Reports/Indicators/Data Elements):

• Cargo

• Helper template:

• Cargo

• Categories

none

• Default form: none, this is populated by Template:Report and Template:Reporting Indicators and their respective forms.

• SMW:

• Categories

• Default form:

See also Transfer Delay (Critical Care).

Use

• The purpose is to determine the amount of time a patient is occupying a bed in at a given Level of care (High Observation ward or a regular ward) when the patient is no longer needing that Level of care.

• This is relevant because:
  • If patients are at a higher level of care than they need this can indicate that beds at a lower level are not available and more might be needed.
  • It might also indicate that beds at a higher (and more expensive) level of care might be reduced if patients could consistently move to the appropriate level of care.
  • A patient who doesn't need to be in a hospital runs the risk of nosocomial complications if they remain in hospital.

Definition

• Transfer Delay is the difference in decimal days between the time the pt is first transfer ready at a Level of care and the time that they leave that level
  • starts at the Transfer Ready DtTm corresponding to the first Boarding Loc of a given Level of care
  • ends as a patient leaves that level of care in one of the following ways:
    • to a Dispo location (ie Dispo DtTm)
    • to a Boarding Loc with a different(higher or lower) Level of care (ie the start of that next Boarding Loc)
      • transfer to another Boarding Loc at the same Level of care does not reset the clock/generate a new delay

Example:

Scenario: arrive HOBS1 -> ready to transfer to reg ward -> regular ward -> ready to transfer out -> HOBS2 -> Home first transfer delay is (start of reg ward) - (ready to transfer to reg ward) second transfer delay is (start of hobs) - (ready to transfer out) three is no transfer ready between HOBS2 and home, so no additional delay

How about scenario Med(with TR) -> HOBS -> Med(with TR) -> hosp discharge According to the definition that would result in two delays but we only get a single Delay metric per record. So is it (a) sum (time from TR1 to start of HOBS, time from TR2 to hosp discharge) (b) sum (time from TR1 to start of HOBS, entire time at subsequent med level of care locations) In Beds occupied by transferrable patients (Medicine) you state that the metric is per patient, but is it really per patient, per record or per boarding loc? So if a patient goes from a boarding loc to another and back to the first, you presumably report the sum of the time at that loc for that pt, but for an average, would the N be 1 patient or 2 records? To take that further, if the pt goes to ICU and then comes back, would the N become 3? the inclusion criteria on that page don't really clarify how this is resolved. I realize we were breaking out these indicators and trying to have each explained all on page for ease of use by report users, but this is an example where I think it would be better to define things like 'the transfer delay complex' as individual indicators, individual stratifiers, and then possibly define a compound indicator that combines them, but refers to the earlier definitions. It makes it slightly harder to follow, but hopefully anyone who actually looks at a data definition value coherence of the details over light reading. Also, I realize it's more friendly to read in indicators that something is "per patient", but I think it is also important to be specific about this, so suggest we should change this to be the actual N used in any of our indicators. in file 20_... for GRA data Julie provides an explanation that may resolve this question. I am putting it below. If I understand that one correctly, W1 - W1TR - W2 - H1 - W3 - W3TR - Dispo would result in a delay of dispo-W1TR W1 - W2 - W2TR - H1 - W3 - W3TR - Dispo would result in a delay of dispo-W3TR Is that the right understanding? If Julie agrees the discussion can go.

• SMW

• Cargo

• Categories

1. If patient stayed in HOBS only to discharge , then its transfer ready dttm is considered, otherwise the first transfer ready from regular ward is used.
2. If patient both stayed first in HOBS then regular ward to discharge, the first transfer ready from regular ward is used.
3. If there are more than one transfer ready dttm from regular ward then to regular ward to discharge, the first transfer ready dttm is used.
4. If there is coming back and forth from High Obs to regular to HOBS to regular to discharge , then the first transfer ready dttm from regular going to regular (same) or lower level of care is used.

Calculation of Transfer Delay

• As agreed in JALT meeting March 22, 2023, transfer delays will be reported based on actual delays at each Level of care with no more allowances of less than n hours.
• Before Jan 2023, Transfer delay calculation is done similarly with the Critical Care calculation which is substracting n hrs from all actual delay time and for Medicine, n is 4 hours.
• In the meeting held Jan 11, 2023, Critical Care agreed to change the calculation of transfer delays which Medicine will do similarly for consistency as follows: (a) ignore such transfer delays < 4 hrs, but (b) for all delays >=4 hrs to use the actual delay time. The process is to be done on the transfer delay at each Level of care.

Implementation

Time patient is ready for transfer

The definition of this has changed between before and after PatientFollow Project.

Starting Oct 1, 2020, it will need to be calculated differently.

It is not reported by ward, it is reported only per episode / profile.

Our statistician sums up the multiple transfer delays that might be present and reports them all aggregated to their Dispo DtTm. It is done this way because only once we have a complete record with a Dispo DtTm we have reliable Transfer Ready data, so it's the only way we can report on this without becoming inconsistent with data reported earlier.

Start time is first transfer ready per level of care; end is either last of this level of care, or dispo.

• Before Oct 1, 2020, it was calculated by Created_Variables_Common_maker_2021 query and stored in Created_Variables_Common_2021 table in CFE.

• The new definition has only been implemented in SAS and is not available in CFE.

Implementation in CFE

For now, a "Transfer Ready Med testing" button on the main form of CFE needs to be pressed to generate this data. Once we are comfortable with it this generating will be included in the Calc created variables button.

Sub populate_created_transferDelay() loads created_TransferReady query (which generates transfer ready dates) and created_BoardingLoc_plus_historical query and writes delays to created_transferDelay table.

Which Transfer Ready DtTm To Use?

This is now implemented in Created_TransferReady query.

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

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

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

• 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, which may or may not be at a different level in the Level of care hierarchy, namely regular wards (CTU or NTU) and High-Obs Wards
• for the purpose of Transfer Delay (Medicine), we will have a transfer delay for each group of Boarding Locs at the same level of care, i.e. there may be more than one per CCMDB record. To accommodate more than one line per record, this is stored in its own table.
• the first Transfer Ready DtTm from a Boarding Loc with the same level of care will be used

Example:

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. Transfer delays for high obs and regular ward will be separately reported.

Reporting of Transfer Delays

• Include all cases with transfer ready dttm (who went to same/lower/higher level of care or died).
• Refer to indicator Beds occupied by transferrable patients

SAS Program

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

Data use

• Transfer Delay
• Beds occupied by transferrable patients

Data Integrity Checks (automatic list)

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

related fields

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