Service/Location field: Difference between revisions

From CCMDB Wiki
Jump to navigation Jump to search
← Older edit
No edit summary
No edit summary
 
(11 intermediate revisions by 2 users not shown)
Line 3: Line 3:
| CCMDB_label = Service Location
| CCMDB_label = Service Location
| CCMDB_tab = Dispo
| CCMDB_tab = Dispo
| element_description = Legacy field replaced by [[Boarding Loc]] and [[Service tmp entry]]
| element_description = Encodes which program a record is part of.
| in_table = L_Log table
| in_table = L_Log table
| data_type = number
| data_type = number
Line 12: Line 12:
| data_element_sort_index = 40
| data_element_sort_index = 40
}}
}}
The field was changed as part of  [[Change from Service Location to Service, Boarding Loc and Transfer Ready DtTm tmp entry]].
{{DL|
* Now that we have decided to leave this as separate wiki pages, should we remove the above line? [[User:Lkaita|Lisa Kaita]] 06:45, 2024 April 11 (CDT)
** How about this. But we still have a problem: what do we put into the element_description for this in the template call? That's kind of important since it drives the auto data dictionary. [[User:Ttenbergen|Ttenbergen]] 17:22, 2024 April 11 (CDT)
** need to chat about this T [[User:Lkaita|Lisa Kaita]] 14:38, 2024 October 2 (CDT)}}
*'''This does not apply to [[STB_MICU]], [[STB_CICU]], [[STB_ACCU]] or [[HSC MICU]], [[HSC SICU]], [[HSC_IICU]]'''. Service Location field will not change.


== Collection Instruction ==
== Collection Instruction ==
''see [[Change_from_Service_Location_to_Service,_Boarding_Loc_and_Transfer_Ready_DtTm_tmp_entry#The_change]] for how to code during the transition to the new scheme
When entering from [[CSS]] or [["Add Patient with Serial Helper" button]], or in [[Patient Viewer Tab Dispo]], under {{PAGENAME}} select the generic site/program entry:  
When entering from [[CSS]] or [["Add Patient with Serial Helper" button]], or in [[Patient Viewer Tab Dispo]], under {{PAGENAME}} select the generic site/program entry:  
* [[GRA_Med]], [[HSC_Med]], [[STB_Med]] for medicine
* [[GRA_Med]], [[HSC_Med]], [[STB_Med]] for medicine
* [[GRA_CC]], [[HSC_MICU]], [[HSC_SICU]], [[HSC_IICU]], [[HSC_IICU]], [[STB_MICU]], [[STB_ACCU]], [[STB_ICCS]] for critical care (see [[STB_CC#Decision to not combine collection of STB CC on one laptop]])  
* [[GRA_CC]], [[HSC_MICU]], [[HSC_SICU]], [[HSC_IICU]], [[HSC_IICU]], [[STB_MICU]], [[STB_ACCU]], [[STB_ICCS]] for critical care (see [[STB_CC#Decision to not combine collection of STB CC on one laptop]])  


==Bed Borrow==
== ICU Bed Borrow ==
* When a service borrows a bed in another unit/ward but still follows them the [[Service Location]] should be the location where the patient would have been had there been enough beds/space for them.  example. ACCU patient, followed by ACCU service but physically located in CICU, service location=ACCU. The [[Boarding Loc]] in the Tmp will identify that they are "borrowing" a bed in CICU.  If this patient is then transferred to their normal unit, ACCU, add this location as a [[Boarding Loc]] in the tmp, this would be a single profile. If the patient was NOT followed by ACCU but by CICU, see [[ICUotherService]] for instructions on how to collect.
'''Bed Borrow Only'''
* second example- HSC MICU often overflows or borrows a bed in SICU, but MICU follows them, the [[Service/Location]] would be HSC MICU, the [[Boarding Loc]] would reflect the real physical location HSC SICU, and the [[Service tmp entry]] should be HSC Critical Care Medicine.  If the patient is later transferred to HSC MICU, this location would be added as a [[Boarding Loc]], this would remain a single profile.  However, iF the Service changes to an SICU service and they take over care, then a new profile would be started showing the new [[Service Location]] and the new [[Service tmp entry]] and [[Boarding Loc]]  
* When a service borrows a bed in another unit/ward but still follows them, the [[Service Location]] should be the location where the patient would have been had there been enough beds/space for them.   
**examples: 
1. ACCU patient, followed by ACCU service but borrowing a bed in CICU:
* [[Service Location]] =ACCU  The [[Boarding Loc]] in the Tmp will identify that they are "borrowing" a bed in CICU.  If this patient is then transferred to their normal unit, ACCU, add this location as a [[Boarding Loc]] in the tmp, this would be a single profile.  
*If CICU service takes over care, then a new profile would be started, showing the [[Service Location]]= CICU and the new CICU [[Service tmp entry]] and CICU [[Boarding Loc]]
2. HSC MICU borrows a bed in SICU, but MICU follows them:
* [[Service/Location]]= HSC MICU, the [[Boarding Loc]] in the Tmp will identify that MICU is borrowing a bed in HSC SICU, If the patient is later transferred to HSC MICU, this location would be added as a [[Boarding Loc]], this would remain a single profile.   
*If the Service changes to an SICU service and they take over care, then a new profile would be started showing the new [[Service Location]]= SICU and the new SICU [[Service tmp entry]] and SICU [[Boarding Loc]]  


The concepts that used to be stored in this are essentially now stored as:
* [[Service tmp entry]] for the service
* [[Boarding Loc]] for the physical location


{{Location dropdown cleanup}}
'''Bed and Service Borrow Scenarios'''
* see [[ICUotherService]]


{{DL|
* is this section still current? [[User:Ttenbergen|Ttenbergen]] 11:13, 6 March 2025 (CST)
* It up for discussion tomorrow at [[JALT Meeting - Rolling Agenda and Minutes 2025]] [[User:Lkaita|Lisa Kaita]] 21:04, 10 March 2025 (CDT)
* Allan spoke with Bojan, to be discussed at next JALT [[User:Lkaita|Lisa Kaita]] 14:48, 16 April 2025 (CDT)
* still being dicussed at JALT [[User:Lkaita|Lisa Kaita]] 21:45, 9 September 2025 (CDT)}}
{{Guideline Minimal Data Set}}
{{Guideline Minimal Data Set}}


== Adding a new service/location entry ==
== Implementation ==
The field is populated with options from the [[s_dispo table]].
 
=== Adding a new service/location entry ===
* add to ''[[s_dispo table]]''
* add to ''[[s_dispo table]]''
* consider all checks in [[:Category:Service/Location check]] to see if they need to be modified to work right for the new location.
* consider all checks in [[:Category:Service/Location check]] to see if they need to be modified to work right for the new location.
 
{{Collapsable | always=
== Data Use / Purpose ==
* the name for a service location must be no longer than 8 characters, ie 3 for the hosp identifier, an underscore, and at most 4 for the local identifier |
See [[Site and Location table]] for possible entries.
full=
 
The Service/Location field is one of the components that make up the [[D_ID field]] when a record is sent. That field has a length of 18. For 5 digit identifiers:
Used to determine the location or services the patient went during a hospital stay.
* [[D_ID]] field length:  18
 
* H5_SOH_Geriatrics-19866 length: 24
Used to categorize/stratify the distribution of patients across hospitals and wards/units when reporting summary statistics.
* [[Laptop identifier]] and [[Pat_ID]] for a record, eg H5_-19866, lenght: 10
 
** this is assuming a 5 digit [[Pat_ID]]; as of 2025-03 our largest is 43865 so this will be OK for some time
== Integrity checks ==
** so our new s_dispo entry can be max 8 for service_locations
{{Data Integrity Check List}}
** 4 of that is always e.g. HSC_, so the local descriptor portion is max 4
 
*** e.g. HSC_AAAA will work, HSC_BBBBB will not
== Implementation ==
* if a Service_Location is used that results in a [[D_ID]] length > 18 the error will be a counterintuitive [[Error "Invalid SQL statment..." when sending | "Invalid SQL statement; expected 'DELETE', 'INSERT', 'PROCEDURE', 'SELECT', or 'UPDATE'. "]].
The field is populated with options from the [[s_dispo table]].
}}


=== Retiring an available Service/Location field entry ===
=== Retiring an available Service/Location field entry ===
Line 64: Line 67:
Another option might be to keep old location available, at risk of manual mistakes and continuing to use the old location, and of location-number Pool mix-ups. Either way, '''needs to be planned'''.
Another option might be to keep old location available, at risk of manual mistakes and continuing to use the old location, and of location-number Pool mix-ups. Either way, '''needs to be planned'''.


== Legacy ==
{{Location dropdown cleanup}}
 
== Data Use / Purpose ==
This essentially only encodes which [[program]] and [[site]] a record belongs to. It has additional meanings in legacy data, see [[Change from Service Location to Service, Boarding Loc and Transfer Ready DtTm tmp entry]].
 
Used to categorize/stratify the distribution of patients across [[program]] and [[site]] when reporting summary statistics.
 
== Integrity checks ==
{{Data Integrity Check List}}
 
== Log / legacy ==
This field is subject to [[Change from Service Location to Service, Boarding Loc and Transfer Ready DtTm tmp entry]]. However, we still need it because of how we decided to collect patients at HSC and STB CC.
This field is subject to [[Change from Service Location to Service, Boarding Loc and Transfer Ready DtTm tmp entry]]. However, we still need it because of how we decided to collect patients at HSC and STB CC.
The concepts that used to be stored in this are essentially now stored as:
* [[Service tmp entry]] for the service
* [[Boarding Loc]] for the physical location


This field is part of the [[2016 Time and Place changes]] and corresponds to to the old Location field, resp L_Log.R_Location.
This field is part of the [[2016 Time and Place changes]] and corresponds to to the old Location field, resp L_Log.R_Location.
Line 72: Line 89:
{{Related Articles}}
{{Related Articles}}


[[Category: 2016 Time and Place changes]]
[[Category:2016 Time and Place changes]]
[[Category: Registry Data]]
[[Category:Registry Data]]
[[Category: Data Collection Guide]]
[[Category:Data Collection Guide]]

Latest revision as of 21:45, 9 September 2025

Data Element (edit)
Field Name: Service_Location
CCMDB Label: Service Location
CCMDB tab: Dispo
Table: L_Log table
Data type: number
Length: long integer
Program: Med and CC
Created/Raw: Raw
Start Date: 2016-07-01
End Date: 2300-01-01
Sort Index: 40
Data Dependencies(Reports/Indicators/Data Elements):

Encodes which program a record is part of.

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


Collection Instruction

When entering from CSS or "Add Patient with Serial Helper" button, or in Patient Viewer Tab Dispo, under Service/Location field select the generic site/program entry:

ICU Bed Borrow

Bed Borrow Only

  • When a service borrows a bed in another unit/ward but still follows them, the Service Location should be the location where the patient would have been had there been enough beds/space for them.
    • examples:

1. ACCU patient, followed by ACCU service but borrowing a bed in CICU:

2. HSC MICU borrows a bed in SICU, but MICU follows them:

  • Service/Location= HSC MICU, the Boarding Loc in the Tmp will identify that MICU is borrowing a bed in HSC SICU, If the patient is later transferred to HSC MICU, this location would be added as a Boarding Loc, this would remain a single profile.
  • If the Service changes to an SICU service and they take over care, then a new profile would be started showing the new Service Location= SICU and the new SICU Service tmp entry and SICU Boarding Loc


Bed and Service Borrow Scenarios


  • SMW


  • Cargo


  • Categories

Minimal Data Set

This entry is part of the Minimal Data Set. Special collection instructions apply, see that page for more info.

Implementation

The field is populated with options from the s_dispo table.

Adding a new service/location entry

* the name for a service location must be no longer than 8 characters, ie 3 for the hosp identifier, an underscore, and at most 4 for the local identifier   

The Service/Location field is one of the components that make up the D_ID field when a record is sent. That field has a length of 18. For 5 digit identifiers:

Retiring an available Service/Location field entry

Sometimes a ward may close or change names, or we may stop collecting somewhere. In that case, an entry for Service/Location needs to be made unavailable by editing the s_locations_allowed_collection table.

If a location is no longer available on a laptop records with that location can't be set to "complete". So, if we transition from one location to a new one, we need to get collectors to change the locations for all existing records to the new one, and change the number to using the new number series. Another option might be to keep old location available, at risk of manual mistakes and continuing to use the old location, and of location-number Pool mix-ups. Either way, needs to be planned.

"Can we remove the items that are no longer Service/Locations, Previous Locations, Pre-admit Inpatient Institutions or dispo locations from the dropdowns?"

We can and will remove them, but that can only happen once no more laptops use them. We will need to keep track of this and then remove them when ready. If I removed them now, then any box that currently has them enter would misbehave.

SQL query of what is currently available    
SELECT s_dispo.location_name, s_dispo.Site, s_dispo.active, s_dispo.inpatient, s_dispo.previous_location, s_dispo.s_location, s_dispo.dispo
FROM s_dispo
WHERE (((s_dispo.Site)>"") AND ((s_dispo.active)=True) AND ((s_dispo.inpatient)=True)) OR (((s_dispo.Site)>"") AND ((s_dispo.active)=True) AND ((s_dispo.previous_location)=True)) OR (((s_dispo.Site)>"") AND ((s_dispo.active)=True) AND ((s_dispo.s_location)=True)) OR (((s_dispo.Site)>"") AND ((s_dispo.active)=True) AND ((s_dispo.dispo)=True));
  • query of what is currently used: query z_s_dispo_inactivatable

Data Use / Purpose

This essentially only encodes which program and site a record belongs to. It has additional meanings in legacy data, see Change from Service Location to Service, Boarding Loc and Transfer Ready DtTm tmp entry.

Used to categorize/stratify the distribution of patients across program and site when reporting summary statistics.

Integrity checks

Data Integrity Checks (automatic list)

 AppStatus
Query check minimal data set incompleteCCMDB.accdbimplemented
Check function location NE dispoCCMDB.accdbimplemented
Check function previous NE LocationCCMDB.accdbimplemented
Check function preAdmit NE LocationCCMDB.accdbimplemented
Query s tmp ABO TEE checksCCMDB.accdbimplemented
Query send check centralized is ownerCCMDB.accdbimplemented
Query s tmp EuroSCORE II checksCCMDB.accdbimplemented
Query Check_from_ED_and_prev_location_same_siteCCMDB.accdbready to implement
Query s tmp Boarding Loc no borrow but entryCCMDB.accdbretired
PL SameCHART Site Diff PHINCentralized data front end.accdbimplemented
Link suspect mismatch pre inpt ours incomplete queryCentralized data front end.accdbimplemented
Link_suspect_not_same_visitAdmitDtTm queryCentralized data front end.accdbimplemented
Reconnect check orphans queryCentralized data front end.accdbimplemented
Link_suspect_visitAdmitDtTm_mult_to-from-home queryCentralized data front end.accdbready to implement

Log / legacy

This field is subject to Change from Service Location to Service, Boarding Loc and Transfer Ready DtTm tmp entry. However, we still need it because of how we decided to collect patients at HSC and STB CC.

The concepts that used to be stored in this are essentially now stored as:

This field is part of the 2016 Time and Place changes and corresponds to to the old Location field, resp L_Log.R_Location.

Related articles

Related articles:
Retrieved from "https://ccmdb.kuality.ca/index.php?title=Service/Location_field&oldid=167544"