Intended1stSrvc: Difference between revisions

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


== Background ==
== Background ==
The [[Critical Care Program Quality Indicator Report]]
{{DT | is that the right report? I have added this new data to that report's dependencies. If it's the wrong one it will need to be taken out of there. If other reports also use this, it will need to be added to them. If only that report you can remove this comment. [[User:Ttenbergen|Ttenbergen]] 15:20, 26 September 2025 (CDT)
* Yes,  the plan is to show them here - the intended 1st service along with the other scenarios which will be presented maybe tabular or graphical (preferably).  --[[User:JMojica|JMojica]] 17:06, 18 December 2025 (CST) }}


*This variable essentially replaces [[ICUotherService]]
 
*It is to be used when the ICU service a patients 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.
 
*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 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.
**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]])
*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
*Along with [[Boarding Loc]], [[Service Location]] and [[Intended1stSrvc]] allow clear identification of all types of ICU boarding
*As part of this alteration in collection, we will no longer use [[Service tmp entry]] for the purpose of identifying actual locations or services.  It will ONLY be used for the purpose of keeping track of data collection.
 
**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"
**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 [[Service tmp entry]] is downloaded from Cognos, this will no longer occur
Line 36: Line 37:
*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.
*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.


*Use tmp fields:
 
* Project: {{PAGENAME}} <!-- leave this, it resolves to page name -->
* Item:
{{Discuss | as per [[JALT Meeting - Rolling Agenda and Minutes 2025#JALT 2025-12-18]], needs to be integrated:
* We agreed that the options for the dropdown listings should all be the same for [[Boarding Loc]], [[Service/Location]], and the new field [[Intended1stSrvc]], and that these will be the same as those currently used for [[Boarding Loc]], i.e: HSC-MICU, HSC-SICU, HSC-IICU, STB-MICU, STB-CICU, STB-ACCU and GH-CC
* We recognize that these will then be different from the "official" ADT services listings provided to us in [[Cognos2]]
}}


=== Things to resolve ===
=== Things to resolve ===
Line 50: Line 45:
** I have reviewed the links to [[ICUotherService]] and changed what needs changing. [[User:Ttenbergen|Ttenbergen]] 15:05, 26 September 2025 (CDT)
** I have reviewed the links to [[ICUotherService]] and changed what needs changing. [[User:Ttenbergen|Ttenbergen]] 15:05, 26 September 2025 (CDT)


* We need to move the change-related parts of what Allan wrote in [[Intended1stSrvc]] to [[2025-05 Revision of concept around ICUotherService]] to keep this page on target and keep the explanation in one place. [[User:Ttenbergen|Ttenbergen]] 15:05, 26 September 2025 (CDT)
== Data collection ==
** I think I have done that, mostly, but someone should have a look at [[2025-05 Revision of concept around ICUotherService]] to confirm that the change is explained fully enough to make sense of the before and after data [[User:Ttenbergen|Ttenbergen]] 23:03, 28 September 2025 (CDT).
 
=== Data Entry Instructions ===
*Use tmp fields:
* Project: {{PAGENAME}} <!-- leave this, it resolves to page name -->
* 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


=== 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)  }}
* 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|}}
== Background ==
* A similar concept used to be collected in [[ICUotherService]]; see [[2025-05 Revision of concept around ICUotherService]] for details
* 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 ===
* nothing so far..
{{DL |
* Could you confirm that there are no changes required to the following pages? We discussed that details about them might change as part of all this. [[User:Ttenbergen|Ttenbergen]] 14:44, 23 December 2025 (CST)
** [[Service/Location field]]
** [[Service tmp entry]]
}}
=== can be left until later but may complicate analysis or degrade data ===
{{DJ |
* There is a question that may be related to this on [[ICUotherService]] for you, could you have a look? [[User:Ttenbergen|Ttenbergen]] 14:44, 23 December 2025 (CST)
}}
{{Discuss |
* [[JALT Meeting - Rolling Agenda and Minutes 2025#JALT 2025-12-18 | 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. [[User:Ttenbergen|Ttenbergen]] 14:44, 23 December 2025 (CST)
}}
{{Discuss |
* Can these only be at the same site as the record? If so that may be a relevant cross-check.
}}
=== can be safely left until later ===
{{DJ |
* [[JALT Meeting - Rolling Agenda and Minutes 2025#JALT 2025-12-18 | 2025-12-18 JALT]] - the decision actually also talked about [[Service/Location]] being made the same; did we decide to proceed with this? [[User:Ttenbergen|Ttenbergen]] 14:44, 23 December 2025 (CST)
}}
{{DT |
* We need to move the change-related parts of what Allan wrote here to [[2025-05 Revision of concept around ICUotherService]] to keep this page on target and keep the explanation in one place. [[User:Ttenbergen|Ttenbergen]] 15:05, 26 September 2025 (CDT)
** I moved the information that was on this page that explained the why and how of changing from [[ICUotherService]] to this to its own page, one of the [[Change Explainer Pages]]: [[2025-05 Revision of concept around ICUotherService]]. This is to document the transition and its consequences once. 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 [[User:Ttenbergen|Ttenbergen]] 14:44, 23 December 2025 (CST)
}}
==== resolved ====
* just for tracking
** TT reviewed "what links here" for [[ICUotherService]]


== Log ==
== Log ==
* -> 2026-01-01 - this entry essentially replaces [[ICUotherService]]
* [[JALT Meeting - Rolling Agenda and Minutes 2025#JALT 2025-12-18 | 2025-12-18 JALT]] - decision that dropdown listings for this should be the same as for [[Boarding Loc]]
* 2025-12-23 - broke out [[ICU Service Location Discrepancy]] to document how indicators and metrics will be derived from this
* 2025-12-23 - broke out [[ICU Service Location Discrepancy]] to document how indicators and metrics will be derived from this
* 2025-09-25 - change of [[ICUotherService]] to this way of coding the concept was first discussed, page generated for Allan to update.  
* 2025-09-25 - change of [[ICUotherService]] to this way of coding the concept was first discussed, page generated for Allan to update.  
* See [[2025-05 Revision of concept around ICUotherService]] for decisions leading up to implementation
* See [[2025-05 Revision of concept around ICUotherService]] for decisions leading up to implementation
{{Data Integrity Check List|}}
{{Discuss |
* I don't think any checks are possible for this, or can someone think of one?
}}


== Related articles ==  
== Related articles ==  

Revision as of 14:44, 23 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. I hope to have this set up to start collecting with the new instructions Dec1. For now, continue to use the instructions in ICUotherService. Ttenbergen 14:27, 26 September 2025 (CDT)

  • SMW


  • Cargo


  • Categories

Background

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

  • 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 this record
    • 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.
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.

Transfer to Another ICU Service


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

Special Cases

Service admissions where the situation changes part way through the record

  • 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?--JMojica 17:31, 18 December 2025 (CST)
  • SMW


  • Cargo


  • Categories

Data Integrity Checks (automatic list)

none found

Background

Left to resolve

need to resolve before we can start collecting

  • nothing so far..
  • 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

can be safely left until later

  • SMW


  • Cargo


  • Categories
  • SMW


  • Cargo


  • Categories

resolved

Log

Related articles

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