Intended1stSrvc: Difference between revisions

From CCMDB Wiki
Jump to navigation Jump to search
← Older editNewer edit →
Agarland (talk | contribs)
CCMDB_legit, approved, Administrators
3,377 edits
(78 intermediate revisions by 5 users not shown)
Line 1: Line 1:
{{Project
{{Project
|ProjectActive=proposed
|ProjectActive=Active
|ProjectProgram=CC
|ProjectProgram=CC
|ProjectRequestor=
|ProjectRequestor=Bojan Paunovic
|ProjectCollectionStartDate=
|ProjectCollectionStartDate=2026-01-01
|Project={{PAGENAME}}
|Project={{PAGENAME}}
}}
}}
{{Discuss|
'''<mark>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]]. '''[[User:Ttenbergen|Ttenbergen]] 14:27, 26 September 2025 (CDT) </mark> }}
== Data Collection Instructions ==
== Data Collection Instructions ==
*This variable was first created in October 2025.  Along with [[Boarding Loc]] and [[Service tmp entry]], it allows keeping track of every type of boarding (also called bed borrowing) and "double-boarding" bed-days reported quarterly for each ICU.
=== When to code ===
*With the initiation of this new variable, the old variable [[ICUotherService]] is retired/discontinued.
*Collect this if the ''initial'' ICU service to which the patient was admitted to (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.  
*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'''
**Example:  MICU-type patient is in HSC ED, but due to MICU being full, the patient is admitted to the SICU service.  Here [[Service/Location]] is HSC-SICU and [[Intended1stSrvc]] = HSC-MICU
**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.
**This variable is left blank when the patient's first ICU service is, in fact, the ICU service they "should" be on -- obviously this is most ICU admissions
**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
*So, this variable only applies UPON ADMISSION to an ICU service -- regardless of the patient's physical location when that occurs (e.g. can include ECIP situations)
**BUT this variable CANNOT be coded until the patient was offically admitted to an ICU service -- irrespective of care advice being provided by an ICU team, and irrespective of any role ICU team members have in facilitating eventual admission to an ICU service
*Reconsider the [[Intended1stSrvc]] for each new ICU profile for the same patient


=== Transfer to Another ICU Service ===
=== Changes of "intended service" during the ICU stay ===
*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.
* 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.
*Instructions relating to coding this variable when a patient transfers from 1 ICU service to another:
*This is why this variable is called intended FIRST service.
**For ICU-to-ICU transfers ''between hospitals'', code this variable anew at the new hospital
*Thus, only consider the '''initial intent'''<!-- turning this into a reference to this project is circular, the point is that _the_intent_ a t the beginning of the admission counts --> for each new profile (see [[#Changes within an ICU service admission]] and [[#Changes between successive ICU service admissions]] )
**For ICU-to-ICU transfers ''within a single hospital'', just carry over the value of this variable from the prior ICU record
***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.
*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.


=== Relationship between [[Intended1stSrvc]] and [[Transfer for bed management]] ===
*Keeping track of this requires remembering that ICU database records are according to ICU service, not location.  Thus, when the service changes the patient gets a new ICU record, while a change of physical location with no change in ICU service is ''not'' a new record (it's just a change in [[Boarding Loc]].
*[[Intended1stSrvc]] ''only'' applies when a patient is initially admitted to an ICU service from a non-ICU location (e.g. ED, ward) -- it DOES NOT apply to direct transfer from one ICU service to a different ICU service (i.e. ICU-to-ICU transfer).  If a patient undergoes direct ICU-to-ICU transfer for bed management reasons, the sending ICU record should have [[Transfer for bed management]] as an [[Acquired Diagnosis]], while the receiving ICU record should have [[Transfer for bed management]] as an [[Admit Diagnosis]]
*[[Transfer for bed management]] only applies to direct ICU-to-ICU service transfers.
**and this is regardless of the physical location of the patient upon that transfer, e.g. a patient who is "ECIP", still physically in ED but has been officially admitted to an ICU service, can have [[Transfer for bed management]], but cannot have [[Intended1stSrvc]] because such a patient has already been admitted to an ICU service and any opportunity to code [[Intended1stSrvc]] would apply to that initial ICU record when they were admitted to that first ICU service.
*Although it IS possible for a single ICU record to include BOTH of these, they would be for ''different ends'' of the ICU record, i.e. the beginning vs. the end
**e.g. Patient with pneumonia in HSC ED is admitted to SICU on SICU service due to lack of MICU beds.  So that SICU service record has [[Intended1stSrvc]]=MICU and [[Service/Location]]=SICU.  Two days later, SICU has a bed crunch and the patient is transferred to Grace ICU, so the SICU database record [[Transfer for bed management]] is coded as an [[Acquired Diagnosis]], while the Grace ICU record will have [[Transfer for bed management]] coded as an [[Admit Diagnosis]]


=== Examples ===
*Example#1:  Patient admitted from HSC ED with severe pneumonia, is still on ED service in ED.  She/he should go to MICU but it is full, so goes to SICU and is taken care of by the SICU service.  Here [[Service/Location]]=SICU,  [[Intended1stSrvc]]=MICU, [[Boarding Loc]]=SICU.
*Example#2: Patient admitted from HSC ED with severe pneumonia, and while in ED is officially admitted to MICU service (i.e. is ECIP). So this initial ICU record has: [[Service/Location]]=MICU,  [[Intended1stSrvc]]=left blank as it doesn't apply for direct ICU service-to-ICU service transfers, [[Boarding Loc]]=HSC ED.  But MICU but it is full, so decision is made for patient to go from ED (having already been admitted to the MICU service) to SICU on SICU service.  For the SICU service record, [[Service/Location]]=SICU,  [[Intended1stSrvc]]=left blank since it doesn't apply to direct ICU service-to-ICU service transfers, [[Boarding Loc]]=SICU, plus [[Transfer for bed management]] as an [[Admit Diagnosis]].  The earlier MICU service record should have [[Transfer for bed management]] as an [[Acquired Diagnosis]].
*Example#3: Patient in ED at Grace still on the ED service.  Should go to Grace ICU but it's full, so is instead initially admitted to HSC MICU, upon which [[Service/Location]]=MICU,  [[Intended1stSrvc]]=none, [[Boarding Loc]]=MICU.  This example shows that the [[Intended1stSrvc]] can be at a different hospital altogether.
*Example#4: Patient in ED at Grace but has been officially admitted to the Grace ICU service.  So, for that Grace ICU record [[Service/Location]]=Grace ICU, [[Intended1stSrvc]]=Grace ICU, [[Boarding Loc]]=Grace ED .  But Grace ICU is full, so decision is made for patient to go to HSC MICU.  Upon admission to HSC MICU, that record has [[Service/Location]]=MICU,  [[Intended1stSrvc]]=left blank since it doesn't apply to direct ICU service-to-ICU service transfers, [[Boarding Loc]]=MICU, and [[Transfer for bed management]] coded as [[Admit Diagnosis]].  The earlier Grace ICU service record should have [[Transfer for bed management]] as an [[Acquired Diagnosis]].
*Example#5:  Patient with pneumonia was admitted from ED to HSC MICU, so [[Service/Location]]=MICU, [[Intended1stSrvc]]=left blank because this patient WAS admitted to the intended first service, [[Boarding Loc]]=MICU.  Due to bed issues in MICU, later on the day of that initial MICU admission, patient is transferred to SICU on SICU service.  For the SICU record, [[Service/Location]]=SICU,  [[Intended1stSrvc]]=left blank since this is a direct transfer not an initial admission to an ICU, [[Boarding Loc]]=SICU, [[Transfer for bed management]] as an [[Admit Diagnosis]].  The earlier MICU service record should have [[Transfer for bed management]] as an [[Acquired Diagnosis]].
*Example#6:  Patient with pneumonia in HSC ED should go to MICU but is admitted to SICU on SICU service due to lack of MICU beds.  So for this SICU record [[Service/Location]]=SICU,  [[Intended1stSrvc]]=MICU, [[Boarding Loc]]=SICU. Two days later, SICU has a bed crunch and the patient is transferred to MICU, so in the MICU database record has [[Service/Location]]=MICU,  [[Intended1stSrvc]]=left blank as it doesn't apply to direct ICU transfers, [[Boarding Loc]]=MICU, [[Transfer for bed management]] as an [[Admit Diagnosis]].  The earlier SICU service record should have [[Transfer for bed management]] coded as an [[Acquired Diagnosis]].
*Example#7:  Patient admitted from STB ED to STB-ICMS service for surgical problem.  Then goes to surgery ward where he develops a postop complication and again goes to STB-ICMS service. Because of the intervening surgical ward admission, this patient will have 2 separate STB-ICMS service records.  For each of them [[Intended1stSrvc]]=blank because for both the patient WAS admitted to the intended first service.  As the 2nd ICU record was not a direct ICU-to-ICU transfer, there is no [[Transfer for bed management]].
*Example#8:  Patient admitted from STB ED to STB-SICU service for surgical problem.  Then goes to surgery ward where he develops a postop complication and although he ''should'' go to SICU, it's full so he goes to MICU but under the care of the SICU service, i.e. he's an SICU service patient boarding in MICU -- for this ICU record: [[Service/Location]]=SICU,  [[Intended1stSrvc]]=blank as he was admitted to the intended service, [[Boarding Loc]]=MICU; and since there was no direct ICU-to-ICU transfer, there is no [[Transfer for bed management]].
*Example#9: Patient admitted to SBGH ACCU for complete heart block and had a permanent pacemaker inserted.  Subsequently had multiple, severe complications and was transferred to HSC MICU because it was felt that the ACCU service had insufficient expertise to handle all these complications.  After awhile in MICU, was transferred to IICU.  This is a complicated situation:
**For the initial ACCU service record:  [[Service/Location]]=ACCU,  [[Intended1stSrvc]]=blank as he was admitted to the intended service, [[Boarding Loc]]=ACCU.
**For the MICU service record:  [[Service/Location]]=MICU,  [[Intended1stSrvc]]=blank as it doesn't apply to direct ICU transfers, [[Boarding Loc]]=MICU.  Here the transfer was judged to be for medical necessity, so no [[Transfer for bed management]] -- and the same would be the case if the patient had gone to STB-ICMS instead of HSC MICU.
**For the IICU service record: [[Service/Location]]=IICU,  [[Intended1stSrvc]]=blank as it doesn't apply to direct ICU transfers, [[Boarding Loc]]=IICU.  Here [[Transfer for bed management]] doesn't apply since IICU is a lower level than MICU and (except for ward to LAU transfers) it only applies to service transfers at the SAME level.
*Example#10: Patient with severe pneumonia admitted from Grace ED to SICU service in SICU because both Grace ICU and MICU are full.  A few days later patient remains physically in SICU but care is taken over by MICU service.  Initial SICU service record: [[Service/Location]]=SICU,  [[Intended1stSrvc]]=MICU, [[Boarding Loc]]=SICU  Subsequent MICU service record:  [[Service/Location]]=MICU,  [[Intended1stSrvc]]=left blank, [[Boarding Loc]]=SICU.
*Example#11:  Grace ICU patient goes to MICU for an EEG, with an official transfer from Grace ICU service to MICU service for this relatively brief interval.  This is a transfer for medical necessity, and MICU service record has: [[Service/Location]]=MICU,  [[Intended1stSrvc]]=left blank, [[Boarding Loc]]=MICU.  For the transfer back to Grace ICU, this is a [[Transfer for bed management]] with [[Service/Location]]=Grace ICU,  [[Intended1stSrvc]]=left blank, [[Boarding Loc]]=Grace ICU.


=== Data Entry Instructions ===
*Use tmp fields:
*Use tmp fields:
* Project: {{PAGENAME}} <!-- leave this, it resolves to page name -->
* Project: {{PAGENAME}} <!-- leave this, it resolves to page name -->
* Item:  
* 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]]
 
{{Data Integrity Check List|}}
 
== 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'''. 
 
=== 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 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]]
{{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 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 ===
* 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]]
 
=== Bed Borrow Only ===
* When only a bed is being borrowed, the correct service is following the patient, so ''do not make an [[Intended1stSrvc]] entry''. [[#ICU Bed Borrow]]
 
=== 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
{{Discuss | JALT
* [[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)
}}
 
== Left to resolve ==
=== need to resolve before we can start collecting ===
* nothing


=== Things to resolve ===
=== can be left until later but may complicate analysis or degrade data ===
{{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]]. [[User:Ttenbergen|Ttenbergen]] 10:59, 25 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)


{{Discuss | 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.
}}
{{DJ |
* 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 [[User:Ttenbergen|Ttenbergen]] 14:44, 23 December 2025 (CST)
}}
}}
==== resolved ====
* just for tracking
** TT reviewed and resolved "what links here" for [[ICUotherService]]
** LK reviewed and updated [[Service/Location field]], [[Service tmp entry]] as needed
== Data Use ==
* 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 ==
* -> 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-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 also [[STB Cardiac Care patients]]
 
{{Data Integrity Check List|}}


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

Revision as of 10:54, 29 January 2026

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:
  • SMW

(inline)

  • Cargo


  • Categories
  • Form


Data Collection Instructions

When to code

  • Collect this if the initial ICU service to which the patient was admitted to (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.
    • Example: MICU-type patient is in HSC ED, but due to MICU being full, the patient is admitted to the SICU service. Here Service/Location is HSC-SICU and Intended1stSrvc = HSC-MICU
    • This variable is left blank when the patient's first ICU service is, in fact, the ICU service they "should" be on -- obviously this is most ICU admissions
  • So, this variable only applies UPON ADMISSION to an ICU service -- regardless of the patient's physical location when that occurs (e.g. can include ECIP situations)
    • BUT this variable CANNOT be coded until the patient was offically admitted to an ICU service -- irrespective of care advice being provided by an ICU team, and irrespective of any role ICU team members have in facilitating eventual admission to an ICU service
  • Reconsider the Intended1stSrvc for each new ICU profile for the same patient

Changes of "intended service" 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 )

Relationship between Intended1stSrvc and Transfer for bed management

  • Keeping track of this requires remembering that ICU database records are according to ICU service, not location. Thus, when the service changes the patient gets a new ICU record, while a change of physical location with no change in ICU service is not a new record (it's just a change in Boarding Loc.
  • Intended1stSrvc only applies when a patient is initially admitted to an ICU service from a non-ICU location (e.g. ED, ward) -- it DOES NOT apply to direct transfer from one ICU service to a different ICU service (i.e. ICU-to-ICU transfer). If a patient undergoes direct ICU-to-ICU transfer for bed management reasons, the sending ICU record should have Transfer for bed management as an Acquired Diagnosis, while the receiving ICU record should have Transfer for bed management as an Admit Diagnosis
  • Transfer for bed management only applies to direct ICU-to-ICU service transfers.
    • and this is regardless of the physical location of the patient upon that transfer, e.g. a patient who is "ECIP", still physically in ED but has been officially admitted to an ICU service, can have Transfer for bed management, but cannot have Intended1stSrvc because such a patient has already been admitted to an ICU service and any opportunity to code Intended1stSrvc would apply to that initial ICU record when they were admitted to that first ICU service.
  • Although it IS possible for a single ICU record to include BOTH of these, they would be for different ends of the ICU record, i.e. the beginning vs. the end

Examples

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

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

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


  • Cargo


  • Categories

Left to resolve

need to resolve before we can start collecting

  • nothing

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


  • Cargo


  • Categories


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


  • Cargo


  • Categories

resolved

Data Use

Log

Related articles

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