Intended1stSrvc: Difference between revisions

From CCMDB Wiki
Jump to navigation Jump to search
← Older editNewer edit →
No edit summary
No edit summary
Line 6: Line 6:
}}
}}


'''<mark>
* '''<mark>This project is not live yet, do not follow the instructions to stop the old collection yet </mark>
* This project is not live yet, do not follow the instructions to stop the old collection yet.
* '''<mark>Planned go-live is 2025-01-01</mark>
* Planned go-live is 2025-01-01
* '''<mark>For now, continue to use the instructions in [[ICUotherService]] </mark>  
* For now, continue to use the instructions in [[ICUotherService]]  
</mark>  
 
== Background ==
This project encodes when an admission "''should have been''" with a different Critical Care service than where it actually ended up.
 
 
*It is to be used when the ICU service a patient is actually on (MICU, SICU, IICU, ICMS, CICU, Grace ICU) is different from the service the patients '''should be on'''.  This most common reason for this to happen is bed capacity issues.
{{Ex |
**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.
}}
 
*This variable should be left BLANK when the ICU service the patient is on is the one they should be on -- i.e. only fill it in when there is an [[Intended1stSrvc]] that is different from the first service they are actually on (i.e. what's in [[Service/Location]])
*Along with [[Boarding Loc]], [[Service Location]] and [[Intended1stSrvc]] allow clear identification of all types of ICU boarding
 
**those downloaded entries do not actually correspond the the true 6 ICU services that exist (as of 2025) and so are confusing, as they are things like "HSC Critical Care/Medicine A" or "HSC Critical Care/Plastics"
**as [[Service tmp entry]] is downloaded from Cognos, this will no longer occur
*As we create a new ICU profile (record) when the ICU service changes, each time a new ICU profile is created, collectors will need to consider [[Intended1stSrvc]] anew
**although we considered carrying over the prior value of [[Intended1stSrvc]] when a patient is transferred ICU-to-ICU, we decided against this as it creates other ambiguities
*Here is the most complex subtlety of this issue of what service a patient "should be on"
**It can change during the course of the episode of ICU care (across ICUs, or within a single ICU).  Sometimes such a change might be clearcut (e.g. due to occurrence of a surgical procedure) but other times the fact that the service the patient should be on changes is just within the heads of the attending physicians.  Because of this uncertainty 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"


== Data Collection Instructions ==
== Data Collection Instructions ==
* Code it as the ICU service that the patient '''SHOULD HAVE BEEN under upon initial admission to the ICU Service in this hospital''', i.e. at the start of [[Definition of a Critical Care Program Admission | this record]]
=== When to code ===
** Leave it blank if the very first day in ICU in that hospital, the patient was, in fact under the "correct" ICU service, i.e. the service that ''should have'' been taking care of the patient -- and as this is the majority of all ICU records, this variable will usually be left blank.
* Collect this if the initial service, as encoded in [[Service/Location]] for records under the [[Definition of a Critical Care Program Admission]], is '''''not the service the patient "should" have been on
{{Ex | x=
* No consistency or "not applicable" entry is required when applicable
* 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. }}
* Reconsider this for each new ICU record for the same patient
 
=== Transfer to Another ICU Service ===
*This is important regarding this variable [[Definition of a Critical Care Program Admission | as a new ICU database record is created]] when a patient goes from one ICU [[Service tmp entry | service]] to another, but not if the patient goes from one ICU [[Boarding Loc]] to another while staying under the same service.
 


=== Changes during the ICU stay ===
* only consider initial intent per record (see [[#Changes within an ICU service admission]])
* apply a new consideration for each new record (see [[#Changes between successive ICU service admissions]])


=== Things to resolve ===
=== Things to resolve ===
Line 57: Line 34:
* all other fields are not used for this project
* all other fields are not used for this project


=== Special Cases ===
==== Service admissions where the situation changes part way through the record ====
* [[Definition of a Critical Care Program Admission]] lays out when a new record should be created
* How does that play into this?
{{Discuss |
* This [[Intended1stSrvc]] assumes a whole stay on the borrowed service.  How about the case where there is only partial stay being taken care by borrowed service and then the patient now becomes a legit patient of that service.  Example, [[Intended1stSrvc]] is STB ICSM taken care by ACCU service (May 24,2023 13:17) boarding at ACCU bed , then by May 26,2023 15:40 became an ACCU patient taken care by ACCU in same ACCU bed until discharge to ward June 5,2023 16:22.  This is currently just one record.  For me to breakdown the days, there is a need to enter the  start dttm and/or end dttm aside from  the intended unit.  OR Should this case be two records, thus there is no need to enter dttm?--[[User:JMojica|JMojica]] 17:31, 18 December 2025 (CST)  }}


{{Data Integrity Check List|}}
{{Data Integrity Check List|}}


== Background ==
== Background ==
* A similar concept used to be collected in [[ICUotherService]]; see [[2025-05 Revision of concept around ICUotherService]] for details
* 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
* 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
* When demand exceeds capacity a patient may end up 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'''. 
{{Ex |
**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.
}}
 
=== Possible Responsibility/Location Scenarios ===
::{| class="wikitable"
! 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 fact that the service the patient should be on changes 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"
{{Ex | x=
* 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 the patient was initially on a service they should not have been on, and is then changes status such that the present service is the intended one, there is no change in service (so no new record), and the initial status for the record as [[Intended1stSrvc]] stays. 
{{Ex |  [[Intended1stSrvc]] is STB ICSM taken care by ACCU service (May 24,2023 13:17) boarding at ACCU bed , then by May 26,2023 15:40 became an ACCU patient taken care by ACCU in same ACCU bed until discharge to ward June 5,2023 16:22. }}
 
=== Changes between successive ICU service admissions ===
* As per [[Definition of a Critical Care Program Admission]] we create a new ICU profile (record) when the ICU service changes
* We considered carrying over the prior value of [[Intended1stSrvc]] when a patient is transferred ICU-to-ICU, but decided against this as it creates other ambiguities
* The decision of whether this project applies will have to be re-assessed for each new record under the [[Definition of a Critical Care Program Admission]]
 
=== 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


== Left to resolve ==
== Left to resolve ==
Line 108: Line 120:
== Data Use ==
== Data Use ==
* see [[ICU Service Location Discrepancy]]
* see [[ICU Service Location Discrepancy]]
* for legacy context also consider [[ICUotherService]], a similar concept that used to be collected; see [[2025-05 Revision of concept around ICUotherService]] for details


== Log ==
== Log ==

Revision as of 03:27, 24 December 2025

Projects
Active?: planned
Program: CC
Requestor: Bojan Paunovic
Collection start:
Collection end:
  • SMW

(inline)

  • Cargo


  • Categories
  • Form


  • This project is not live yet, do not follow the instructions to stop the old collection yet
  • Planned go-live is 2025-01-01
  • For now, continue to use the instructions in ICUotherService

Data Collection Instructions

When to code

  • Collect this if the initial service, as encoded in Service/Location for records under the Definition of a Critical Care Program Admission, is not the service the patient "should" have been on
  • No consistency or "not applicable" entry is required when applicable
  • Reconsider this for each new ICU record for the same patient

Changes during the ICU stay

Things to resolve

{{Discuss| Things we need to resolve:

  • We need to review anything that links to ICUotherService, and anything that page lists to. The "anything that links there" can be accessed by expanding the "related articles (expand)" at the bottom of ICUotherService. Ttenbergen 10:59, 25 September 2025 (CDT)

Data collection

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


Data Integrity Checks (automatic list)

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 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.

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 fact that the service the patient should be on changes 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"
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 the patient was initially on a service they should not have been on, and is then changes status such that the present service is the intended one, there is no change in service (so no new record), and the initial status for the record as Intended1stSrvc stays.
Example:    
 Intended1stSrvc is STB ICSM taken care by ACCU service (May 24,2023 13:17) boarding at ACCU bed , then by May 26,2023 15:40 became an ACCU patient taken care by ACCU in same ACCU bed until discharge to ward June 5,2023 16:22.

Changes between successive ICU service admissions

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

Left to resolve

need to resolve before we can start collecting

  • SMW


  • Cargo


  • Categories

can be left until later but may complicate analysis or degrade data

  • There is a question that may be related to this on ICUotherService for you, could you have a look? Ttenbergen 14:44, 23 December 2025 (CST)
  • SMW


  • Cargo


  • Categories
  • 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)
  • SMW


  • Cargo


  • Categories
  • Can these only be at the same site as the record? If so that may be a relevant cross-check.
  • SMW


  • Cargo


  • Categories
  • SMW


  • Cargo


  • Categories

can be safely left until later

  • SMW


  • Cargo


  • Categories
  • SMW


  • Cargo


  • Categories

resolved

Data Use

Log

Related articles

Related articles:
Retrieved from "https://ccmdb.kuality.ca/index.php?title=Intended1stSrvc&oldid=168220"