BedHeldEnd DtTm
| Projects | |
| Active?: | planned |
| Program: | CC and Med |
| Requestor: | ??? |
| Collection start: | 2023-01-01 |
| Collection end: | |
Data Collection
Collect for all patients where beds are held due to AMA or procedure at other sites. This will only be recorded in the situations when:
- patient leaves AMA
or
- patient Visits to temporary locations, we expect them to return so bed is held but they never do come back
Collection Instructions
- Project :BedHeldEnd DtTm
- Items: AMA (AWOL), AMA (Protocol) or Procedure
- Date (field E): Discharge date as per ADT (ie when the bed was released)
- Time (field M): Discharge time as per ADT (ie when the bed was released)
- Not used: Integer, Real, Checkbox, Comment
The date and time for AMA (Protocol) will be the same as the Dispo DtTm, we are collecting it only for completeness and cross-checks.
- AMA (Protocol) is when a consent discussion regarding the patient's choice to leave before a recommended time has been done and the patient is being asked to sign a form that he/she understands the risks of such decision.
- AMA (AWOL) is leaving without consent discussion or permission.
Sources
Use the discharge dttm as per Cognos2 Ender/ADT.
Background
As discussed at JALT, the frequency of people leaving AMA (esp from ward) is not low. And, per Lisa, most of these are without notice. Thus it is not a trivial issue that there is a nontrivial difference between when the patient actually stops being under care vs. when the bed is released for reassignment.
Our previous instructions were to note in the Dispo DtTm field when the person left AMA, or was noted to be gone and assumed AMA. If a bed is "held" and the patient indeed returns, goes back into that bed without being readmitted (because the bed was held), then this isn't to be considered to be an AMA. This follows the same kind of reasoning as Visits to temporary locations. This meant we had no way to report bed times lost to AMA.
We then realized that this issue is the same for bed times lost to beds held when a patient is sent to another hospital for a procedure, expecting to return (so the bed from the sending site is held) but then does not return.
These 2 situations are easy for the DCs to identify and they always do so anyway, so we decided to track this to allow us to report on this more meaningfully.
So we will distinguish between:
- (a) Actual time under care, which is from Admit DtTm to the patient's Dispo DtTm -- we'll call this the patient's length of stay **use for indicators LOS Per Record or LOS Per Service
- (b) What we'll call "Bed Assigned Time", i.e. from Admit DtTm to the time when the bed is released for reassignment, which we will call "BedHeldEndTime". This latter is generally available from Cognos (ADT)
Collection parameters
- End Date: planned as continuous collection without an end date
Data Use
Consistency Checks
We will collect this data for a month or so to have an idea what it looks like after that, we might add a cross check for complete and undeleted records such that if AMA is entered for this, Dispo must be AMA.
With the current data, the converse is not true in case of AMA who signs out, as BedHeld will not be entered if pt signs out AMA following WRHA process. Once we see data we will decide if we want to add a counterpart so we can cross-check that the entry wasn't just forgotten if there is an AMA entry in Dispo. We might add an entry like AMA (protocol) to be able to ensure completion. Data for those would either have no dttm, or the same dttm as [[Dispo DtTm ], we'd have to decide.
No entry for AMA following sign-out protocol
We don't have a special entry for patients who leave AMA following the sign out protocol. For these, no bed hold times are incurred, and we already track that they are leaving AMA in the Dispo field, so nothing would be gained by adding an entry for them here.
Data Integrity Checks (automatic list)
| App | Status | |
|---|---|---|
| Query check tmp BedHeld | CCMDB.accdb | implemented |
To do
|
|
|
|
|
After we have 1 month of data we will review if we need to reconsider any Indicators. |
|
Log
- 2023-01-10 Julie identified data problems in preliminary data and defined required checks, see Query check tmp BedHeld
- 2023-01-01 collection start
- 2022-12-08 made page to validate