Property:DiscussQuestion
This is a property of type text.
P
'''ER Delay and Overstay'''
* Need to make sure I do things this way and include this in the right pages, possibly [[Change from Service Location to Service, Boarding Loc and Transfer Ready DtTm tmp entry]] but a lot of other pages touch on this, so maybe it needs to be a template? It may not be consistent everywhere:
Note from email from Julie 2024-20-24:
I do not use any cut-off e.g. 2020-10-15 because the tmp has been populated by boarding data since July 2018 for ICU and Sept 2019 for Med. The cut-off Oct 2020 Patient Follow only applies for tmp Service but not for tmp Boarding loc. By the way. the patient follow started early at Grace Oct 1, 2020 (they piloted it), while HSC and STB started Oct15, 2020. Similar with EMIPs, I have two sources of ER-delay namely 1. from Accept and Arrive 2. from Tmp : first boarding dttm and second boarding dttm. If both have values, I use the one from the tmp source. +
s
* "Hospice - other, WPG" is currently not grouped as Hospital = "Other Institution in WPG" as the other hospices - should it be? [[User:Ttenbergen|Ttenbergen]] 17:03, 11 March 2025 (CDT)
+
B
* ''For the [[Directors Quarterly and Annual Report (Critical Care)]], the [[Dispo DtTm]] is used as the time of reference.
** The record's ICU [[Dispo DtTm]], or the linked ICU Hospitalization's [[Dispo DtTm]]?
+
T
* ''The [[Dispo]] location will be used to define the destination. As per Dr. Garland & Dr. Paunovic.
** I think we discussed at Task that we will do this differently now... right?
+,
* The above is really about stratification, and not the indicator itself. Do you really only use it to stratify delays, or do you also report other indicators such as Length of Stay with it. Even if it is single-use, I think we should probably treat any generated value we use to stratify pretty much as we do Indicators, possibly using the same templates on the wiki. The stratification affects averages and totals, so it needs to be transparent. This is likely a can of worms because there must be much stratification in the reports. [[User:Ttenbergen|Ttenbergen]] 14:50, 7 December 2025 (CST)
+
D
* A possibility to change the current [[Chart]] entry to be the same with SH format (see [[#DSM Inclusion Criteria/ Process]] for reason why in details).
+
O
* According to the draft SOPs we are to provide communication of the results as below. Andrea Thiessen explained that they would want something like a list split by colour. Then people would start manually populating other documents with this. I should follow up to determine the details and possibly set up a better way.
* 2025-07-03 TT emailed to Katherine Graham and Kathy Kwiatkowski how they will use it (include Andrea Thiessen)
+,
*The [https://home.gracehealthcampus.ca/download/56/110-500-400/9589/110-500-411.pdf 110.500.411, Discharge Planning Screening Tool (DPST)] says that we will provide a report or patient colours. The details need to still be worked out.
*** I need to work with Andrea and Katherine Graham on overall reporting, so '''please don't do a separate approach on this'''. Separate emails are awkward for them, I asked to do it like that for now because it's low effort on collector part and you said you are already overwhelmed by all the changes. [[User:Ttenbergen|Ttenbergen]] 12:12, 3 July 2025 (CDT)
*If this remains in email form there may end up being a mailing list for this.
Once the final reports are figured out collectors may or may not be involved in providing these. [[User:Ttenbergen|Ttenbergen]] 00:11, 2 July 2025 (CDT)
** As of July25,2025 collectors were advised they can stop sending the automatically generated emails to Andrea, so we have, TT removed this function Sept 5, 2025 [[User:Lkaita|Lisa Kaita]] 07:28, 6 September 2025 (CDT)
+
S
* As discussed at [[JALT Meeting - Rolling Agenda and Minutes 2025#JALT 2025-11-27]]: Do we need any post-send, cross-record checks relating to [[Service tmp entry]]? [[User:Ttenbergen|Ttenbergen]] 16:44, 27 November 2025 (CST)
+
P
do we have a page for that to also include instructions about province etc. like we have for [[homeless]]... +, I understand the sentiment in the following, but this should either be rules or not mentioned at all, or it will cause confusion, since it would be relevant specifically in the edge cases when it would fall apart. So it might be better to address the specific edge cases and make a rule and cross check where relevant.
Where this bears on data use, we should make sure we define once what we will check for and how we adjudicate or interpret inconsistencies, like we did for [[homeless]] patients. [[User:Ttenbergen|Ttenbergen]] 16:10, 11 July 2025 (CDT)
=== Relationship between [[Province]], PHIN and Postal code ===
When collecting Postal Code, [[PHIN]] number and [[Province]], think about the relationship of this information when you are collecting it.
*if patient has a MB PHIN number, then [[Province]] code should be MB and the postal code should be for MB (MB postal codes start with an "R").
*if [[Province]] code is '''not''' MB then the postal code should not be a MB postal code. Enter "not applicable" or the out of province postal code if available, and also, there should not be a PHIN number. +,
* CCMDB have [[pre_acute_living_situation field]] [[homeless]] with Postal Code, should the Postal code be ignored and replaced by N/A. Should the R_Province entry be affected by Postal Code N/A? --[[User:JMojica|JMojica]] 10:54, 24 June 2025 (CDT)
** We are currently reviewing some of the definitions of [[homeless]]ness. It is possible that details will change as outcome from that. The concept has been broadened to include some ambiguous states and terminology changed to houselessness. Next meeting later this week about that.
** I don't expect that it would change instructions of how to code Postal Code; so, it makes sense to me to update vetted data for postal code to "N/A" if the [[Pre acute living situation]] is "[[homeless]]".
** Also, we have discussed whether it would be better to do this as an actual change in data, or as an logical change by function or encoded data in the [[Data Meaning Layer]]. Julie, you already do some other things in that layer to re-write data, if I interpret your SAS code correctly. [[User:Ttenbergen|Ttenbergen]] 17:11, 18 July 2025 (CDT)
+, …
C
* review, that might need to be consolidated with this page as well.
+,
* Discussed this at [[JALT Meeting - Rolling Agenda and Minutes 2025#JALT 2025-03-11]] but I don't remember if we came to an answer or next step. Just found a note to add that we will also need to decide if any of these are in-patient locations. This would make them collectable as [[Pre-admit Inpatient Institution]], and is relevant as per [[Pre-admit Inpatient Institution field#Data Use / Purpose]].
*are you referring to PCH's because they are not inpt locations or are you referring to chronic health facilities? [[User:Lkaita|Lisa Kaita]] 14:52, 25 June 2025 (CDT)
+, 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.
* Discussed at
** [[Task Team Meeting - Rolling Agenda and Minutes 2025#CHF4]]
** [[Task Team Meeting - Rolling Agenda and Minutes 2025#CHF3]]
** [[JALT Meeting - Rolling Agenda and Minutes 2025#CHF2]]
** [[Task Team Meeting - Rolling Agenda and Minutes 2025#CHF1]] +, …
E
* Do we need to add "Dr. Michael Troncone" to this? Or is it better to not maintain that list here and instead ask collectors to refer to the dropdown?
+
P
* Do we want a regular update process? See comments in that file. [[User:Ttenbergen|Ttenbergen]] 12:15, 4 August 2025 (CDT)
+
* Does that make this one of the [[Indicators]]? If so we should apply [[Template:Reporting Indicators]] so this is linked and tracked appropriately. If it isn't a separate indicator and only a component of [[ICU Interfacility Transfer]] then it should be added to the template there.
+
C
* For now that listing is quite incomplete, we have left quite a trail of these and will need to add them.
+
L
* Found a record from last Oct in this query so emailed Julie and Pagasa to see if we are still running this. Guess that raises the question if [[Correcting suspect links]] is still being followed, and [[Centralized data Vetting Process]] in general. [[User:Ttenbergen|Ttenbergen]] 22:49, 11 March 2025 (CDT)
+
T
* Grace Hospital not filled this out according to instructions documented here, but some old version instead. That makes data between GRA and other sites problematic to compare. Lisa and Gail have more info. We should document which version they have been using so it can be accounted for when using this data.
+
* How about scenario Med(with TR) -> HOBS -> Med(with TR) -> hosp discharge
* According to the definition that would result in two delays but we only get a single Delay metric per record. So is it
::(a) sum (time from TR1 to start of HOBS, time from TR2 to hosp discharge)
::(b) sum (time from TR1 to start of HOBS, entire time at subsequent med level of care locations)
* In [[Beds occupied by transferrable patients (Medicine)]] you state that the metric is per patient, but is it really per patient, per record or per boarding loc? So if a patient goes from a boarding loc to another and back to the first, you presumably report the sum of the time at that loc for that pt, but for an average, would the N be 1 patient or 2 records? To take that further, if the pt goes to ICU and then comes back, would the N become 3? the inclusion criteria on that page don't really clarify how this is resolved.
I realize we were breaking out these indicators and trying to have each explained all on page for ease of use by report users, but this is an example where I think it would be better to define things like 'the transfer delay complex' as individual indicators, individual stratifiers, and then possibly define a compound indicator that combines them, but refers to the earlier definitions. It makes it slightly harder to follow, but hopefully anyone who actually looks at a data definition value coherence of the details over light reading.
* Also, I realize it's more friendly to read in indicators that something is "per patient", but I think it is also important to be specific about this, so suggest we should change this to be the actual N used in any of our indicators.
* in file 20_... for GRA data Julie provides an explanation that may resolve this question. I am putting it below. If I understand that one correctly,
** W1 - W1TR - W2 - H1 - W3 - W3TR - Dispo would result in a delay of dispo-W1TR
** W1 - W2 - W2TR - H1 - W3 - W3TR - Dispo would result in a delay of dispo-W3TR
* Is that the right understanding? If Julie agrees the discussion can go.
E
* I have a hunch that this error may be related to a send failing for one collector and a second collector then also sending, leading to problems with the lock file.
So, when the error happens, please have a look at <span class="info-tooltip">[[Regional Server]]\/output<span class="tooltip-text">\\ad.wrha.mb.ca\WRHA\REGION\SHARED\ICU_DATA_COLLECTION\/output </span></span> and see if there is a second centralized_data file there with an extension .lccdb. See [[Lccmdb and ldb files]] for details. Please log here about what you find. [[User:Ttenbergen|Ttenbergen]] 10:41, 2024 November 30 (CST)
+
S
* We need to clean up this page and likely some linking to it. I don't know the truth on the ground so can't just do it. Something do do in one of the wiki wrangling efforts LK and TT may want to schedule one of these days. [[User:Ttenbergen|Ttenbergen]] 12:35, 20 March 2025 (CDT)
+,
* I have linked this in from several reports based on those having "L2" in them. There might be others where I just don't know that they also use this building location because they word it through stb icu or cardiac unit or something. It would be worth updating and linking those reports so that, when a location related to them changes, we will be easily able to find it on the wiki and know the underlying SAS might need updating. [[User:Ttenbergen|Ttenbergen]] 12:35, 20 March 2025 (CDT)
+
E
* I have re-updated [[Created_Variables_Common_maker_2021 query]], for some reason the change I had made was not reflected in the master version. Ready to test. [[User:Ttenbergen|Ttenbergen]] 13:25, 2022 June 28 (CDT)
** emailed Tina some inconsistencies found in ER Delays Aug 15,2022. --[[User:JMojica|JMojica]] 13:21, 2022 August 29 (CDT)
*** are these still an issue? [[User:Ttenbergen|Ttenbergen]] 11:15, 2024 May 1 (CDT)
**** I will re-check again. Can't remember if have been resolved. --[[User:JMojica|JMojica]] 14:40, 2024 October 2 (CDT)
+,
* I just had a look at that sas file (they open as text files) to see how you define transfer delay. If that file is still being used we may have a problem, it still defines tdelay different if a pt goes to a higher level of care, goes AMA or dies, and we changed that some time ago. So is this still the reference of how you calculate this? [[User:Ttenbergen|Ttenbergen]] 22:50, 2024 November 16 (CST)
+,
* This data is problematic before 2011-Q2,the only reason there are any is because it derives them for EMIPs. Some data may be available in [[Moves for Medicine]], but that would still leave a gap. [[User:Ttenbergen|Ttenbergen]] 23:09, 2024 November 16 (CST)
** OK, will be working on this getting data from [[Moves for Medicine]] from period Sept 2007 to June 3, 2011. will give to Pagasa for upload to [[Arrive DtTm field]]. I will update the WIKI as soon as done. Conclusion: for Medicine, prior Sept 2007, no ER delay while for Critical Care, no ER Delay prior July 1, 2016 -- these are treated as missing. --[[User:JMojica|JMojica]] 16:35, 2024 December 11 (CST)
+, …
Q
* I implemented '''item must not be "not entered"'' and 40 records in the data I had at the time a "not entered" in complete data. Did I misunderstand the instructions? Or are these correct instructions and should be implemented as that?
+, JALT
* if there is referral sent there must be a referral received entry and a consult dealt with entry [[User:Lkaita|Lisa Kaita]] 11:31, 7 August 2025 (CDT)
** pt could die in between? consult could go missing? In a way those would be really the ones we would want to know about, no? I suppose we could make it a soft check... [[User:Ttenbergen|Ttenbergen]] 16:26, 19 August 2025 (CDT)
** this almost sounds like the opposite of how I would have understood the current instructions. I would have thought those to mean to only enter "consult received" if there was no good data for consult sent. How do we actually want to use this?
*** late answer: how did Julie analyze this? at the time all fields were mandatory, unless there was no consult, current status, collect consult sent and if no data found for this then use consult received. [[User:Lkaita|Lisa Kaita]] 12:59, 13 January 2026 (CST)
*** I don't know, flagging for Julie and putting this on the JALT agenda; collection is still going, so we may still want to implement this. [[User:Ttenbergen|Ttenbergen]] 14:58, 13 January 2026 (CST) +