Intended1stSrvc: Difference between revisions

From CCMDB Wiki
Jump to navigation Jump to search
No edit summary
Line 13: Line 13:
{{DJ | 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)
{{DJ | 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)
}}
}}
contains information about patients who are '''taken care of by a critical care service other then the one that normally would''', generally due to capacity limitations. The actual service taking care of the patient is encoded in [[Service tmp entry]], this variable encodes which service should have taken care of a patient initially upon admission, but did not. Along with [[Boarding Loc]] and [[Service tmp entry]], this data allows keeping track of every type of boarding (also called bed borrowing) and "double-boarding" bed-days reported.
contains information about patients who are '''taken care of by a critical care service other then the one that normally would have taken care of them''', generally due to capacity limitations. The actual service taking care of the patient is encoded in [[Service tmp entry]], this variable encodes which service should have taken care of a patient initially upon admission, but did not. Along with [[Boarding Loc]] and [[Service tmp entry]], this data allows keeping track of every type of boarding (also called bed borrowing) and "double-boarding" bed-days reported.


== Data Collection Instructions ==
== Data Collection Instructions ==
* quarterly for each ICU. 
*With the initiation of this new variable, the old variable [[ICUotherService]] is retired/discontinued.
*With the initiation of this new variable, the old variable [[ICUotherService]] is retired/discontinued.
*Code it as the ICU service that the patient '''SHOULD HAVE BEEN ON on their very first day in any ICU while in that hospital'''
*Code it as the ICU service that the patient '''SHOULD HAVE BEEN under on their very first day in any ICU while in that hospital'''
**Leave it blank if the very first day in ICU in that hospital was, in fact on the "correct" ICU service, i.e. the one they ''should have'' been on -- and as this is the majority of all ICU records, this variable will usually be left blank.   
**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.   
**e.g. Patient with acute MI admitted via ED.  He should have been on ACCU service in ACCU but ACCU was full. So he got admited to ICMS instead on the ICMS SERVICE.  Thus here [[Intended1stSrvc]] = ACCU
**e.g. 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 ===
=== Transfer to Another ICU Service ===
*This is important regarding this variable as a new ICU database record is created when a patient goes from 1 ICU service to another, but not if the patient goes from 1 physical ICU to another while staying on the same service.
*This is important regarding this variable as a new ICU database record is created when a patient goes from one ICU service to another, but not if the patient goes from one ICU to another while staying under the same service.
*Instructions relating to coding this variable when a patient transfers from 1 ICU service to another:
 
**For ICU-to-ICU transfers ''between hospitals'', code this variable anew at the new hospital
'''Instructions relating to coding this variable when a patient transfers from one ICU service to another:'''
**For ICU-to-ICU transfers ''within a single hospital'', just carry over the value of this variable from the prior ICU record
*For ICU-to-ICU transfers ''between hospitals'' (inter-facility), code this variable anew at the receiving hospital
***continuation of above example: While he was in ICMS on the ICMS service he developed cardiogenic shock and emergently went for bypass surgery, after which he went to CICU on the CICU service.  As he stayed in the same hospital and just went ICU-to-ICU within it, for the new database record begun when he went to the CICU service, again [[Intended1stSrvc]] = ACCU, as carried over from his first ICU record at St. B.
*For ICU-to-ICU transfers ''within a single hospital'' (intra-facility), carry over the value of this variable from the prior ICU record
*We note that the ICU service that a patient ''should be on'' can change, and so simply carrying over the [[Intended1stSrvc]] from the first day in any ICU can misrepresent where the patient "should be".  But we discussed and are OK with that, as such changes represent only a fraction of a fraction of patients, and trying to keep better track of what service ''should be'' on throughout their episode of ICU care is difficult and very confusing.
***continuation of above example: While he was in ICMS under the ICMS service he developed cardiogenic shock and emergently went for bypass surgery, after which he went to CICU under the CICU service.  As he stayed in the same hospital and went ICU-to-ICU within it, the new CICU profile would begin when he went to the CICU service, the [[Intended1stSrvc]] = ACCU, as carried over from his first ICU profile at SBGH
 
*We note that the ICU service that a patient ''should be under'' can change, and so simply carrying over the [[Intended1stSrvc]] from the first day in any ICU can misrepresent where the patient "should be".  But we discussed and are OK with that, as such changes represent only a fraction of a fraction of patients, and trying to keep better track of what service ''should be'' on throughout their episode of ICU care is difficult and very confusing.





Revision as of 20:38, 27 September 2025

Projects
Active?: proposed"proposed" is not in the list (active, planned, legacy, aborted in planning) of allowed values for the "ProjectActive" property.
Program: CC
Requestor:
Collection start:
Collection end:

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 Oct 1. For now, continue to use the instructions in ICUotherService. Ttenbergen 14:27, 26 September 2025 (CDT)

  • SMW


  • Cargo


  • Categories

Background

The Critical Care Program Quality Indicator Report

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. Ttenbergen 15:20, 26 September 2025 (CDT)

  • SMW


  • Cargo


  • Categories

contains information about patients who are taken care of by a critical care service other then the one that normally would have taken care of them, generally due to capacity limitations. The actual service taking care of the patient is encoded in Service tmp entry, this variable encodes which service should have taken care of a patient initially upon admission, but did not. Along with Boarding Loc and Service tmp entry, this data allows keeping track of every type of boarding (also called bed borrowing) and "double-boarding" bed-days reported.

Data Collection Instructions

  • With the initiation of this new variable, the old variable ICUotherService is retired/discontinued.
  • Code it as the ICU service that the patient SHOULD HAVE BEEN under on their very first day in any ICU while in that hospital
    • 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.
    • e.g. 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

  • This is important regarding this variable as a new ICU database record is created when a patient goes from one ICU service to another, but not if the patient goes from one ICU to another while staying under the same service.

Instructions relating to coding this variable when a patient transfers from one ICU service to another:

  • For ICU-to-ICU transfers between hospitals (inter-facility), code this variable anew at the receiving hospital
  • For ICU-to-ICU transfers within a single hospital (intra-facility), carry over the value of this variable from the prior ICU record
      • continuation of above example: While he was in ICMS under the ICMS service he developed cardiogenic shock and emergently went for bypass surgery, after which he went to CICU under the CICU service. As he stayed in the same hospital and went ICU-to-ICU within it, the new CICU profile would begin when he went to the CICU service, the Intended1stSrvc = ACCU, as carried over from his first ICU profile at SBGH
  • We note that the ICU service that a patient should be under can change, and so simply carrying over the Intended1stSrvc from the first day in any ICU can misrepresent where the patient "should be". But we discussed and are OK with that, as such changes represent only a fraction of a fraction of patients, and trying to keep better track of what service should be on throughout their episode of ICU care is difficult and very confusing.


  • Use tmp fields:
  • Project: Intended1stSrvc
  • Item:

Things to resolve

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)


  • SMW


  • Cargo


  • Categories

Log

Data Integrity Checks (automatic list)

none found

Related articles

Related articles: