| Projects
|
| Active?:
|
Active"Active" is not in the list (active, planned, legacy, aborted in planning) of allowed values for the "ProjectActive" property.
|
| Program:
|
CC
|
| Requestor:
|
Bojan Paunovic
|
| Collection start:
|
2026-01-01
|
| Collection end:
|
|
Data Collection Instructions
When to code
Changes during the ICU stay
- Although it occasionally happens that the "intended" service for an ICU patient changes after initial admission to an ICU service, we will NOT attempt to keep track of such changes. The reason is that such changes often reside only in the heads of the ICU attending physicians, i.e. they're not reliably reflected in the progress notes.
- This is why this variable is called intended FIRST service.
- Thus, only consider the initial intent for each new profile (see #Changes within an ICU service admission and #Changes between successive ICU service admissions )
Data Entry Instructions
- Use tmp fields:
- Project: Intended1stSrvc
- Item: one of (HSC-MICU, HSC-SICU, HSC-IICU, STB-MICU, STB-CICU, STB-ACCU, GH-CC)
- all other fields are not used for this project
- although the service tmp entry is not used for this project, continue to enter service tmp entries from COGNOS as per Service tmp entry
none found
Background
- Usually Boarding Loc and Service/Location fully explain a patient's admission's impact on bed capacity; Service tmp entry contents from Cognos2 do not actually contain data that is relevant for our use
- When demand exceeds capacity a patient may end up being cared for by a different critical care service than the one they would have usually been assigned to.
- Without an additional signal, it would appear as if the capacity was sized right and accommodated the load, when really the sending service was over capacity, and the receiving service had (possibly excess) capacity to absorb the admission.
- This project encodes when the ICU service a patient is actually on (as encoded in Service/Location: MICU, SICU, IICU, ICMS, CICU, Grace ICU) is different from the service the patient should be on.
| Example:
|
- e.g. patient admitted from ED ventilated with severe pneumonia, should go to MICU but it is full, so goes to SICU and is taken care of by the SICU service. Here Service/Location is SICU and Intended1stSrvc is MICU
- e.g. patient in ED at Grace and should go to Grace ICU but it's full, so goes to HSC MICU. Here Service/Location is MICU and Intended1stSrvc is Grace ICU. This example shows that the Intended1stSrvc can be at a different hospital altogether.
|
|
JALT
- this second example, what is the relationship of Intended1stSrvc at a different hospital with the interfacility transfer due to bed management. Should all receiving service due to bed management must also have an entry in Intended1stSrvc? if so then it must also have an admit code transfer due to bed management. --JMojica 15:56, 13 January 2026 (CST)
|
Possible Responsibility/Location Scenarios
| Group |
Service should be on |
Actual service |
Actual location |
Meaning
|
| A |
mine |
mine |
my ICU |
my natural patients
|
| B |
mine |
mine |
different ICU |
my boarders elsewhere
|
| C |
different |
different |
my ICU |
somebody else's boarders in my ICU
|
| D |
mine |
different |
different |
my "double boarders" elsewhere
|
| E |
different |
mine |
my ICU |
somebody else's "double boarders" in my ICU
|
Changes within an ICU service admission
- As per Definition of a Critical Care Program Admission the same ICU profile (record) is maintained if a patient changes Boarding Loc while remaining under the care of the same service
- It is possible that the notion who "should" have cared for the patient changes over the course of the admission.
- Sometimes such a change might be clear-cut (e.g. due to occurrence of a surgical procedure) but other times, the service the patient should be on changes and is just within the heads of the attending physicians.
- The notion may not have been recorded at all, and would be hard to abstract from charts consistently even if it was implied
- Adding the ability to maintain multiple entries for this relatively rare event would significantly increase reporting complexity
- We explicitly decided NOT to try and track the service a patient should be on as time goes by, but only upon initiation of an ICU profile, which is why this variable is called "Intended1stSrvc"
- The exception to this is when the patient, changes to a new service or the service they "should" have been under, and also has a new Boarding Loc
| Example:
|
- Patient with acute MI admitted via ED. He should have been under the ACCU service in ACCU but ACCU was full. So he was admitted to ICMS instead under the ICMS Service. Thus here Intended1stSrvc = ACCU.
- If this same patient is then changed to the ACCU service, while still in ICMS, do not create a new profile, ignore this service change and leave Intended1stSrvc as initially entered
- If the same patient, has a service change to ACCU and is physically moved to the ACCU, then a new profile would be created and we would not code Intended1stSrvc, as the patient is under the intended service
|
Changes between successive ICU service admissions
Bed Borrow Only
Terminology for services inconsistent with EPR
- We recognize that the drop-downs we chose are different from the standardized terms in EPR; it was decided that this is OK because the perception is that our terms are what leadership actually wants
|
|
JALT
- 2025-12-18 JALT - We may want to discuss the discrepancy of our naming and its implications with the recipients of our reports and possibly the team that reports similar out of EPR. Ttenbergen 14:44, 23 December 2025 (CST)
|
Left to resolve
need to resolve before we can start collecting
can be left until later but may complicate analysis or degrade data
|
|
JALT
- Can these entries only be at the same site as the record (eg would "Gra ICU" be a legit entry for a patient at HSC MICU)? If only same siet that may be a relevant cross-check.
|
|
- We need to confirm that the change is properly linked and contextualized on 2025-05 Revision of concept around ICUotherService (one of the Change Explainer Pages) to allow a user of our data to reconstruct a continuous conceptual timeline. Someone other than me should review that page to confirm that the change is explained fully enough to make sense of the before and after data Ttenbergen 14:44, 23 December 2025 (CST)
|
resolved
Data Use
Log
Related articles