Intended1stSrvc

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

• • Intended1stSrvc only applies when a patient is initially admitted to an ICU service from a non-ICU location (e.g. ED) or non-ICU service (e.g. ward), thus it does not apply upon direct ICU-to-ICU transfer. If such a patient is transferred to the receiving ICU service for bed management reasons, that patient should have coding as Transfer for bed management
  • 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 the patient has Intended1stSrvc of MICU and Service/Location of SICU. Two days later, SICU has a bed crunch and the patient is transferred to Grace ICU, so then in that SICU database record Transfer for bed management is coded as an Acquired Diagnosis.

Examples

Example:

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 is SICU and Intended1stSrvc is MICU. Example#2: Patient admitted from HSC ED with severe pneumonia, and while in ED is officially admitted to MICU service (as ECIP). She/he should go to MICU but it is full, so decision is made for patient to go from ED (on MICU service) to SICU on SICU service. So, for the initial MICU service record, Service/Location is MICU and Intended1stSrvc is blank. For the SICU service record, Service/Location is SICU, and Intended1stSrvc does not apply and is left blank, but the patient should be coded as Transfer for bed management. Example#3: Patient in ED at Grace still on the ED service. Should go to Grace ICU but it's full, so goes to HSC MICU. Here upon admission to HSC MICU, Service/Location is MICU and Intended1stSrvc is Grace ICU. This example shows that the Intended1stSrvc can be at a different hospital altogether. Example#4: Patient in ED at Grace still and has been officially admitted to the Grace ICU service. So, for that Grace ICU record Service/Location is Grace ICU and Intended1stSrvc is blank because the patient has been admitted to her/his intended first service. But Grace ICU is full, so decision is made for patient to go t HSC MICU. Here upon admission to Grace ICU MICU, Service/Location is Grace ICU, and Intended1stSrvc is blank because the patient HAS been admitted to the intended ICU service. Upon admission to HSC MICU, that record has Service/Location of MICU, and Intended1stSrvc does not apply and is left blank, but the patient should be coded as Transfer for bed management. Example#5: Patient with pneumonia was admitted from ED to HSC MICU, with Service/Location as MICU and Intended1stSrvc is left blank. Due to bed issues, later on the day of initial MICU admission, patient is transferred to SICU on SICU service. For the SICU record, Service/Location is SICU, Intended1stSrvc is left blank, but patient should be coded as Transfer for bed management.

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

• 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

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

• 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

• -> 2026-01-01 - this entry essentially replaces ICUotherService
• 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.
• See 2025-05 Revision of concept around ICUotherService for decisions leading up to implementation

Related articles