JALT Meeting - Rolling Agenda and Minutes 2025
List of items to bring to JALT meeting
Add to this by adding the following to the article where the problem is documented:
{{DiscussTask | JALT
* <question details>}}(this will bring it to Task if not addressed at JALT)
or
{{Discuss | JALT
* <question details>}}(this will not bring it to Task) Toggle columns: Last modified
| wiki page | question | Last modified |
|---|---|---|
| wiki page | question | Last modified |
| Check pre acute consistent | JALT
| 2025-12-17 6:30:28 PM |
| Chronic Health Facility |
| 2025-11-28 1:43:16 PM |
| Chronic Health Facility |
| 2025-11-28 1:43:16 PM |
| Chronic Health Facility | We have discussed lately that we might want to become more nuanced about some chronic care locations (Deer Lodge (DLC) and Riverview). I have removed the details from the above linked fields and consolidated here. Once this page is cleaned up this discussion entry can be removed.
| 2025-11-28 1:43:16 PM |
| Data Processor Portal | JALT
| 2026-01-06 6:31:16 PM |
| Definition of a Medicine Program Admission | JALT
| 2025-12-09 12:55:39 AM |
| Discharged to community | JALT
Just a placeholder for now because the idea of how we define dispo to community (or for that matter, re-admit Previous Location) in data came up re. things like Readmission to MedWard and others. We have the obvious "Home" but if someone is discharged to something like Dialysis, would that also count? How do we define? Ideally by a column in s_dispo table such as s_dispo.loc_type, but that one uses "non-patient" which it also uses for Deceased patients (should we just split that out?). There is probably even more to this. Likely Julie has more than one approach in reporting. This came up because we were looking to define this for LAU collection readmission data.
| 2026-01-22 3:40:32 AM |
| Dispo field | JALT
I thought we had decided at JALT to collect this as presented by EPR... do I remember this wrong? I had already added it in CCMDB.accdb Change Log 2025#2025-03-11-1. Ttenbergen 22:52, 11 March 2025 (CDT)
| 2026-01-27 5:10:08 PM |
| Intended1stSrvc | JALT
| 2026-01-29 4:54:48 PM |
| Intended1stSrvc | JALT
| 2026-01-29 4:54:48 PM |
| Patients residing in Manitoba with ambiguous MH Health coverage | JALT
| 2025-08-14 5:06:29 PM |
| Project NonTradLoc | JALT
| 2026-01-13 8:28:31 PM |
| Project Overstay2 |
| 2025-12-17 5:44:01 PM |
| Query check tmp AHC | JALT
| 2026-01-13 8:58:25 PM |
| Selkirk Mental Health Centre | JALT - Mental Health Facilities in Addition to Selkirk
| 2025-12-17 6:03:11 PM |
| Selkirk Mental Health Centre | JALT - Mental Health Facility Coding vs PCH
| 2025-12-17 6:03:11 PM |
| Sending Patients | JALT
| 2025-12-17 5:50:08 PM |
| Service tmp post-send consistency checks |
| 2025-11-27 10:44:27 PM |
| Service/Location field |
| 2025-12-24 8:46:05 AM |
| Standard data cleaning process |
| 2025-03-12 2:51:43 AM |
| STB Medicine Collection Guide | There was a discussion about the beds that had been "handed to" them... what was the outcome, should it go here?
| 2026-01-06 4:43:51 PM |
_
_
- New Item Collector Coding- Patient and laptop profiles- ADL and Charlson discrepancy, See Tina's email forwarded to JALT members May 29, 2025
- ICD10 categories, see Tina's email Nov 6, 2024, forwarded to JALT members
JALT 2025-12-18
- Present: Tina, Julie, Jen, Lisa, Allan
- Minutes by: Allan
1. We finalized decisions relating to concepts around service, location and ICU reporting.
- 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 Cognos
2. There was extensive discussion about ward patients on non-GIM services, particularly Nephro, Neuro, Resp
- This is very confusing for many reasons, including:
- Some of these patients are physically on Medicine wards, but others are not
- Nephro, Neuro and Resp have their own wards, in some hospitals
- Some of these patients might be on a GIM ward and cared for by GIM housestaff but the official attending is not GIM (e.g. Nephro)
- Other of these patients might be on a GIM ward cared for as non-teaching by a subspecialty attending (e.g. Nephro) -- but as we don't know about this, they are included in GIM ward reporting by Julie
- The mixture of all these alternatives change over time
- The ICU Database is not kept up to date on all of this confusion
- The Service tmp entry from ADT via Cognos provides some clarity on the actual service caring for each patient, though Julie has found that for ward patients this is incorrect in a minority of cases (probably correct in >90%)
- Some of these issues relate to data that might be useful for the work being done by Dan & Tina on moving patients through the system
- We are unsure how much of such detailed, cumulative data, about all t his is desired by the administrative heads of the Department of Medicine and some of the Sections
- although per Julie and Lisa, Nick H. did request that we collect on the new Nephrology Transplant patients on B2 at HSC
- ACCORDINGLY -- given all this confusion, Allan has sent an email to the leadership of: Department, GIM, Neuro, Nephro, Resp, along with Dan --- proposing that a meeting get set up to:
- First -- understand the wishes of those stakeholders for cumulative data on their various ward patients
- Second -- Figure out how we could provide such reporting
- Third -- come back to the stakeholders to explain what ongoing information would be needed for us to provide that reporting (e.g. being kept appraised of the agreements between GIM and the subspecialties about use of GIM ward beds).
JALT 2025-11-27
- Present: Tina, Julie, Jen, Lisa, Allan, Dan
- Minutes by: Allan
1. 2025-05 Revision of concept around ICUotherService - Followup about service identification:
- Tina identified that Service tmp entry, as part of Cognos EPR Report, is used for purposes other than identifying the service. Thus we will NOT remove it, but it will no longer be used for service identification for records following the Definition of a Critical Care Program Admission, and the data collectors no longer will need to check or ensure that it represents "the truth" about the service.
- TT reviewed the cross checks in Service tmp entry#Data Integrity Checks; there are a number of checks contained to the laptops that should continue since the dttm of the first Service tmp entry serves as start of the record for a number of cross checks. We can stop post-completion checks from the main office, though. Ttenbergen 16:27, 27 November 2025 (CST)
- We agreed, that starting in either late December 2025 or Jan 1, 2026, we will use the following 3 variables for service and location identification for critical care records, and to enable Julie to supply the counts of bed-days for all 5 of the categories:
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
- Service/Location -- will be the service that the patient is actually being care for by. For ICU this is 1 of: MICU, SICU, IICU, ICMS, ICMS, ACCU, Grace ICU
- Boarding Loc -- actual location of the patient
- New variable Intended1stSrvc -- represents the service that the person SHOULD HAVE BEEN ON at the start of ICU care; Only listed if different from the actual Service Location. This will also be chosen from a dropdown list with the same options as for Service/Location
- We will then cease collecting or using ICUotherService
2. Starting ASAP, we will begin using a new ICD10 diagnosis Z75.3, to be called Transfer for bed management
- This is to distinguish transfers for bed management reasons (e.g. to clear a bed from the sending unit so it can admit a patient), as opposed to transfers for medical reasons (e.g. patient transferred from Grace ICU to MICU because she needs dialysis)
- It should be coded as:
- An Acquired Diagnosis from a collection unit that is transferring a patient out
- An Admit Diagnosis from a collection unit that is accepting the patient in transfer. The unit sending the patient to the accepting unit could be a database unit (ICU or Medicine ward) or it could be an ED or OR or other procedure location in the sending hospital
- We decided that instead of doing a consistency check to ensure that the sending and receiving units both have this diagnosis coded, that in doing reporting Julie will consider the transfer to be for bed management if it was coded in EITHER the sending or receiving unit
- Other decisions made about this code:
- All transfers to Low Acuity Units (LAU), and well as similar location types, should have this code included from the sending unit
- We will NOT use this code for repatriations of patients back to their local hospitals
- added Transfer for bed management to the wiki
JALT 2025-10-08
- Present: Tina, Julie, Jen, Lisa, Allan
- Minutes by: Allan
1. In followup of the first item from the prior JALT meeting, Allan, Julie and Jen arranged to meet to discuss how exactly to program identifying the various types of boarding and double-boarding.
2. Collection of locations on the spectrum between home and PCH / Chronic Health Facility - Regarding identifying the "subsets" of location types within Riverview and Deer Lodge
- It was related that this issue dovetails with a meeting yesterday with Dan discussing types of discharge locations that are "in between" and home and PCH. The plan from that meeting was to do Project NonTradLoc, a 2-3 month temp project where the collectors record (in a free text field) the specific identity of such in-between locations --> after which we can assess their frequency and types.
3. Regarding s_dispo table disparate options for Previous Location field and Dispo field.
- Lisa will (again) send around the full lists of "admit from" and "disposition" locations currently in use in the ADT system. We will look at these to decide on additional possible changes
4. 2025-05 Revision of concept around ICUotherService - We had a long discussion about the ICU services
- Currently, we have a cumbersome system with multiple variables that sometimes overlap considerably: Service tmp entry, Service/Location and now Intended1stSrvc
- It's important to note that currently we generate a new record whenever a patient changes ICU services
- The current status is that
- There are just 7 actual ICU services: MICU, SICU, IICU, ICMS, CICU, ACCU and Grace ICU. However, downloaded (via Cognos) from the ADT system are >20 different ICU-related services, e.g. HSC Critical Care/Plastics. But per his meeting a few weeks ago with the ICU leadership, they only use information based on the 7 services. Tina brought up the regional
- Service Location is a single entry per ICU record, which is chosen manually from a dropdown list of the 7 services by the data collectors
- Service tmp entry is populated from Cognos/ADT. It can have multiple entries, which can get confusing, e.g. if an SICU patient starts on plastics and then the vascular surgery team gets involved instead it will include listings of: HSC Critical Care/Plastics and HSC Critical Care/Vascular
- After considerable discussion, we agreed that a reasonable way of simplifying all of this is:
- Maintain Service Location as the actual service the patient is on -- coded as one of the 7 true ICU services
- Delete the Service tmp entry altogether -- as we currently create a new record when a patient changes service, and it's first entry is always the same as Service Location, this will cause no problems
JALT 2025-09-25
- Present: Tina, Julie, Jen, Lisa, Allan
- Minutes by: Allan
1. Continued discussion related to 2025-05 Revision of concept around ICUotherService
- This entire meeting was taken up with discussing the 1st bullet point of the prior JALT meeting (see below), i.e. related to creating new variable Intended1stSrvc and retiring its predecessor ICUotherService
- After this is implemented Allan and Julie must meet to discuss exactly how to code the 4 categories of ICU-specific patient bed-days desired by the ICU director group, i.e.:
- bed-days of patients on that ICU's service but boarding in a different physical location -- this uses Service tmp entry and Boarding Loc
- bed-days of patients physically in that service's ICU location but under the care of a different ICU service -- this uses Service tmp entry and Boarding Loc
- bed-days of of patients whose ICUotherService indicates they should be on that ICU service, but per Service tmp entry and Boarding Loc are on a different ICU service and in a different physical ICU -- these are that services's "double boarders"
- bed-days of of patients on that ICU service and physically in that service's physical ICU location, but whose ICUotherService indicates they should be on a different ICU service -- these are "double boarders" of other ICU services
- We scheduled another JALT meeting in 2 weeks to discuss the other items from the prior JJALT meeting
JALT 2025-07-25
- Present: Tina, Julie, Jen, Lisa, Allan
- Minutes by: Allan
1. Continued discussion related to 2025-05 Revision of concept around ICUotherService
- See June 25, 2025 minutes
- Allan raised the idea of having all ICU-to-ICU transfers remain part of the original ICU database record, both for ICU-to-ICU transfers within a site (e.g. MICU to SICU) and between sites (e.g. GH ICU to MICU).
- By use of the 3 variables: Boarding Loc, Service tmp entry and modified ICUotherService --- we would be able to slice and dice ICU days any way desired for reporting.
- This would include NOT re-calculating the APAPCHE scoring -- which makes sense not to do as the APACHE system is entirely based on scoring at the very first admission to any ICU.
- But 1 thing we might have to re-visit is identifying the reason for ICU transfer, i.e. the "new admit diagnosis". This is quite complicated, as some ICU-to-ICU transfers are NOT because of a new problem mandating different care, while others are for new problems. Of course, given that we track acquired diagnoses with their dates of onset, along with CCI-coded procedures (e.g. surgical procedures), it's likely we could do a good job of inferring the reason for both physical location changes and service changes.
- On July 28 Allan spoke with Bojan about these issues:
- He is open to the idea of NOT starting a new record upon ICU-to-ICU transfer (even between hospitals), and thus with NOT recalculating APACHE scores upon such transfers. One idea from this conversation was to create a 4th category of diagnoses, i.e. a single, "most responsible" Transfer Diagnosis, with date.
- He will talk with the ICU Directors group about this, including revisiting all aspects of the ICU quarterly reporting, to include whether they desire reporting by physical ICU or by ICU service.
2. Regarding identifying the "subsets" of location types within Riverview and Deer Lodge (DLC).
- It always has been, and remains virtually impossible to accurately know which segment of those locations sent a patient to hospital. While Allan previously queried Bojan, who indicated that the ICU program has no deep need to know that, Tina has identified that other efforts she and Dan are involved with DO have such a need. This is made even more complicated because, as in other sites, a given ward/floor at Riverview or Deer Lodge (DLC) can change its "type" over time. However, to date she has not been able to identify/locate anyone who can help us with this. Tina will continue to seek this information
3. Regarding Dispo field -- there are disparate options for Previous Location and Dispo.
- We went through those, and made some (minor) alterations.
- Lisa will find, and send around, the full lists of "admit from" and "disposition" locations currently in use in the ADT system. We will look at these to decide on additional possible changes
JALT 2025-06-25
- Present: Tina, Julie, Jen, Lisa, Allan
- Minutes by: Allan
1. 2025-05 Revision of concept around ICUotherService - We spent most of this meeting continuing discussion about tracking services and locations.
- BACKGROUND:
- There are 3 basic variables to track: Service the patient should be on; Service the patient is on; Actual physical location of the patient. From the POV of any given ICU (e.g. MICU) there are then 5 relevant patient categories:
| 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 |
|
Group E should be different - mine - my ICU. Example - SICU patient taken care by MICU service at MICU bed. in contrast with Group C: SICU patient taken care by SICU service at MICU bed. - --JMojica 15:09, 14 August 2025 (CDT) |
- B+D means insufficient beds in my ICU; C+E means insufficient beds in other unit(s)
- The current quarterly reporting "by unit" is currently (per Julie) actually by service (i.e. A+B+E), but in discussion with Bojan, he told Allan that he has always wanted and assumed he was getting by physical unit (i.e. A+C+E).
- We currently have 4 variables that have been, or are, used to identify services and locations:
- Boarding Loc -- tracks the patient's actual physical location; can change
- Service tmp entry -- tracks the service taking care of the patient; can change
- Service Location -- is the INITIAL service that cared for the patient at hospital admission; does not change. Of note, this field is used to create the unique record identifier and for other purposes unrelated to the service caring for the patient. Thus, not only would it be problematic to delete it, but even renaming it would cause problems.
- ICUotherService -- this is a temp entry that can change over time, and is currently only used at St. B. It contains 2 bits of information, e.g. "ACCU under MICU" means that the patient should be in ACCU on ACCU service but is in MICU on MICU service.
- We recognize that this data infrastructure is confusing and contains some duplication. Here is a suggestion of being able to accurately track all of A, B, C, D and E in the simplest way and with the smallest amount of modifications to existing data infrastructure:
- Keep the current meaning of Service/Location but make very clear in the Wiki that it is a legacy-type field we still use but not to consider it part of the clarification of actual service or location
- Keep Boarding Loc and Service tmp entry with their current meanings
- Alter the meaning of ICUotherService to be the service the patient SHOULD be on. With this simplifying change to the coding of this field, we can unambiguously use these 3 variables to partition care into A, B, C, D and E. We then must re-decide on the criterion that leads us to create a new ICU record. Currently it is when the actual service changes.
|
just came across Proposed future changes to Location and Transfer Ready and related fields about a previous consideration to changing related fields. Ttenbergen 13:28, 27 June 2025 (CDT) |
JALT 2025-05-29
- 2025-05 Revision of concept around ICUotherService - This entire 2.5 hour meeting was about the very complicated issues that relate to patient's: physical location (Boarding Loc), actual care service (Service tmp entry), and where the patient "should be" (which is currently coded in "Other ICU", and Service Location).
- This is made even more complicated in that Service Location also serves functions related to "grouping" for reporting.
- Other issues that relate include: what alterations in locations and/or service should result in starting a new record; how to code Dispo field and Previous Location in the case of ICU-to-ICU transfers with creation of a new record.
- After discussion we agreed that the next step will be to clarify precisely what kinds of reports are desired by our users. In this regard, Allan has worked out a schema for classifying patients based on 3 binary characteristics, and will discuss it with Bojan
- Physical location of patient
- Current care service of patient
- Which service the patient "should be on"
JALT 2025-03-11
- Visit Admit dttm discrepancies, see Visit_Admit_DtTm_differences_within_same_admission
- TT to build Link_suspect_visitAdmitDtTm_mult_to-from-home query
- we have no record of Julie's Standard data cleaning process and should document that
- New disposition options- barriers to discharge and how best to capture this, Dispo_field
- Chronic_Health_Facility⚓
- Alternative_Integrated_Accommodation_(AIA)
- 2025-05 Revision of concept around ICUotherService: Service/Location field Revisit MICU overflow in SICU
- in context also of ICUotherService, Service tmp entry and Boarding Loc and STB CC
- Allan spoke on March 14 with Bojan about the wishes/needs of Critical Care regarding this:
- The "basic" information provided by Boarding Loc and Service tmp entry enable tracking patient-days boarding (defined as a patient cared for by Service A but in location B) -- but they do NOT need to know which location B (e.g. an MICU patient boarding in SICU vs. JK)
- They do want to be able to track the number of patient-days in which a patient who would normally go to ICU A, instead is in ICU B where they are cared for by Service B. This is something that is now tracked by the complicated Service Location field. A simpler alternative to track this could be to have for each ICU record an optional field that identifies it (perhaps called "ICU other service") which has options such as "ICU other service-MICU", "ICU other service-SICU", etc, indicating the ICU service the patient "should have been on"
- Example: A patient that would normally be cared for in ICCS, but ICCS is full. So the patient goes to ICMS on the ICMS service. Here loc=ICMS, Service=ICMS and this database record has a flag for "ICU other service-ICCS".
|
|
|
Previous
For earlier minutes see JALT Meeting - Rolling Agenda and Minutes 2024