|edit ||Avoidable Days (Critical Care) ||
- According to the discussion at Task on 2022-04-20 this will need to be updated once the reporting is updated. Something about 30 minutes grace time for all? Ttenbergen 20:59, 2022 April 20 (CDT)
- I am waiting for the response if not really needed from CC Director and OIT . if so, this will become legacy. --JMojica 16:37, 2022 April 21 (CDT)
|2022-04-21 9:37:55 PM|
|edit ||Query check long transfer delay ||
At the meeting about cross checks (a long time ago) it was decided to change the cut-off to SD*3; if we want to proceed with this check, I will need values for that. Ttenbergen 23:08, 2020 October 15 (CDT)
- the MED above has to changed. I will do a calculation of recent data based on the new process using Mean+3SD. --JMojica 15:16, 2022 February 16 (CST)
|2022-02-16 9:16:09 PM|
|edit ||STB ICUs CAM Rate, VAP Rate, CLIBSI Rate Summary ||
Do we currently still send this, then? To whom? Both in terms of contact info and distribution process... Ttenbergen 10:05, 2022 January 27 (CST)
- haven't heard from the STB team who will continue this request. I am waiting. --JMojica 16:41, 2022 February 4 (CST)
|2022-02-04 10:41:45 PM|
|edit ||Medical Assistance In Dying ||
For a patient at HSC who will receive MAID and is transferred to another ward within HSC for the purposes of MAID do we put our dispo as HSC_ward or Died to Morgue? If we put HSC_ward it will trigger the same error message of needing a disposition of death? Sorry can't recall if we actually addressed this at TASK Lisa Kaita 06:37, 2022 February 4 (CST)
- I think that's a case 3 of Visits to temporary locations, no? Ttenbergen 11:31, 2022 February 8 (CST)
- I have added "Other Procedure Location" as an option for Dispo. How would this be used then? Only for MAID or also for all other cases of case 3 of Visits to temporary locations? And if for all, will that decrease the number of patients dying in our units to a point where Julie needs to be able to explain? Ttenbergen 13:26, 2022 April 20 (CDT)
- What I was referring to is the fact that if you use MAID as an acquired ICD 10 code, your dispo must be death or an error pops up. So we either change the cross check to accept another dispo or consider the boarding location to which they go to, an extension of their medicine admission and then we can use died to morgueLisa Kaita 09:27, 2022 April 28 (CDT)
- At STB site patients are transferred to other facilities for sole purpose of maid; so do not have the option to extend the medicine admission to capture acquired maid/died to morgue dispo. Pamela Piche 10:04, 2022 April 28 (CDT)
- There are two queries (see below) that deal with this, one in CCMDB and one at Pagasa's end. Do we want to change how this code is used, or how those queries cross-check? Signing question over to Julie. Ttenbergen 15:49, 2022 April 28 (CDT)
|2022-05-19 8:19:10 PM|
|edit ||Pre acute living situation field ||
How should the following pre acute living scenarios be coded?
- Residence in mobile homes/parks?
- Residence in rooming houses?
- Permanent residence in hotel rooms?
- bungalow style condos?
- Other, House, Other - my replies --JMojica 17:35, 2022 March 7 (CST)
- is there a reason why "other - known but not listed" would not capture these? Is there a specific concern that drives this question? Ttenbergen 10:44, 2022 March 9 (CST)
- The questions were asked with new collectors in mind; to promote clarity and support consistency with entries. These scenarios (along with any others) could be included as examples in the applicable category whether "other - known but not listed" or an alternative entry.
- OK, we don't have a JALT scheduled so will put it on the list for the next task meeting. Ttenbergen 16:15, 2022 March 17 (CDT)
- I'm not sure this needs to go to TASK, they should be listed as other known but not listed, and add those as examples Lisa Kaita 08:23, 2022 April 28 (CDT)
- If Julie is OK with those definitions then it doesn;t need to go to task. It was initially designated as JALT but those don't seem to be happening. I will flag for Julie. @Julie:If you are OK with this the specifics that have been added above then please remove this discussion. Ttenbergen 10:53, 2022 May 4 (CDT)
|2022-05-04 3:53:26 PM|
|edit ||Collection location documentation ||
How should we now keep track of the ward/unit info on the wiki? More questions on page.Ttenbergen 16:07, 2021 July 14 (CDT)
- Perhaps this can also be included in the Location metadata storage you will set up showing the start and end dates and the bed size. --JMojica 14:32, 2022 February 7 (CST)
- Agreed! This is also why I think where possible we should shift the s_dispo contents to the same name so the Location metadata storage can supply both. I want to discuss how to best encode this with you, hopefully tomorrow at out wiki meeting. Ttenbergen 15:14, 2022 February 8 (CST)
- I need the s_dispo because I am using the other columns as various categories of the detailed numeric locations name and I do not want to drop it for now. I have yet to see the Location metadata storage you are talking about to decide.
- Sorry didn't say that clearly. Don't mean to eliminate s_dispo table at this time, just want to make sure we use same location name as in Boarding Loc where applicable, so we can store the metadata all in one table. Ttenbergen 13:36, 2022 February 9 (CST)
|2022-02-10 7:38:29 PM|
|edit ||S LocationData table ||
I added some sample data to this table. I will eventually add the pulling into CFE of this table to automation CFE, but if you want to test how this data would work in your queries for now, you can link it in manually and work with the sample data in there. Processes to get data in there and all that still to come. Ttenbergen 13:45, 2022 February 10 (CST) ||2022-02-10 7:45:31 PM|
|edit ||Query check long transfer delay ||
If we actually want a cross check like this it needs to be based not on NTU/CTU. We could either base it on specific units or on Level of care hierarchy, ie. add another column to s_level_of_care table. Would that work for you? Ttenbergen 23:08, 2020 October 15 (CDT) ||2022-02-16 9:16:09 PM|
|edit ||SAS Data Integrity Checks ||
Now that we have a structure for cross-checks we should add those you do in SAS to here as well, using the same structure as for those listed in Data Integrity Checks Ttenbergen 20:46, 2018 October 26 (CDT)
- Julie still runs one linking check query that occasionally still flags something. She will start sending these to Tina when they happen so that Tina can update the appropriate check in CFE Data Integrity Checks Ttenbergen 15:44, 2022 February 9 (CST)
|2022-02-09 9:44:05 PM|
|edit ||Query check long transfer delay ||
Requiring notes to have content is really a very soft error check... do we need to consider something better?
- maybe just a pop-up message to confirm if correct is enough? I will assume the date time entry has been confirmed to be correct. --JMojica 15:16, 2022 February 16 (CST)
|2022-02-16 9:16:09 PM|
|edit ||S dispo.loc type ||
Thanks for updating the field description. Do we need more info on this, though, e.g. which indicators use this? In which case it should probably be added to the indicators. It almost seems like taking it to a bit of an extreme to document this, but on the other side, it's one of those things that only you know, Julie, so it would be hard to recreate a report and get this right unless it's documented. Ttenbergen 12:09, 2022 April 27 (CDT) ||2022-04-27 5:09:28 PM|
|edit ||Statistical Analysis ||
This article will likely be one of the more common landing points for external users. What do we want to tell them? Do we have any project articles we want to link in that especially highlight what we can do? ALERT Scale?Ttenbergen 22:50, 2017 June 7 (CDT)
||2022-02-18 2:02:52 AM|
|edit ||Query Import request matcher ||
This one is fairly easy, Pagasa will try to make it. Decided ages ago, but put on Pagasa's list today.
- We only send Vetted data to Allun now.PTorres 14:25, 2022 March 17 (CDT)
- That eliminates the biggest source of errors, but does it eliminate all? Do we still need some kind of cross check for this? What? Will re-route to Julie. Ttenbergen 16:55, 2022 March 17 (CDT)
|2022-03-17 9:55:38 PM|
|edit ||Resource Use ||
This page used to be linked from the front page. It is no longer linked from anywhere. Is it relevant and should we keep it and tie it in with the portals, or delete it? If keep, then which others in Category:Indicators should be added? Ttenbergen 20:46, 2022 February 17 (CST) ||2022-02-18 2:46:27 AM|
|edit ||Chart Review Lists ||
This was linked from the front page (but is no longer linkded from Data_User_Portal_for_the_Manitoba_Critical_Care_and_Medicine_Databases) and intended to give an idea of how one could use our data. Is there anything on Publications that would be a good example for how our DB was used for this? If not, should we take it out? With nothing here it doesn't look very good. Ttenbergen 20:32, 2022 February 17 (CST) ||2022-02-18 2:32:12 AM|
|edit ||Created APACHE Chronic query ||
We could change it to something that deliberately chooses how to derive based on time, but is there any advantage to that?
||2022-04-28 8:55:19 PM|
|edit ||Lab identification in the DSM data ||
We should change this; however, do we only change it going forward or do we also re-import back data? Julie is about to re-import back data until 2019-01-01, so maybe we should reimport back data for all that far?
- shouldn't it be Accept_DtTm and use Arrive_DtTm if [Accept_DtTm is blank. We have discussed that in the Project Boarding Loc, we can still determine the counts in between Accept_DtTm and Arrive_DtTm if needed. --JMojica 10:25, 2019 December 10 (CST)
- That is pretty much what I mean, it should be as you say. Do we want to do this going back in data as you re-import, or just going forward for future imports? Ttenbergen 09:41, 2019 December 11 (CST)
- Yes going forward. also this time using first service dttm. --JMojica 16:36, 2022 February 16 (CST)
- As in, use the Admit DtTm with the definition we have decided in there, right? Ttenbergen 19:48, 2022 February 17 (CST)
|2022-04-21 9:35:14 PM|
|edit ||Template:ICD10 Guideline Transplant Failure ||
We used to not code the past history of transplant if there was a failure because this would be implied. We discussed at Task 2022-05-04 that we should not code it, and that we should consider back-populating this. We will need to decide how. Ttenbergen 12:21, 2022 May 4 (CDT) ||2022-05-04 5:21:01 PM|
|edit ||Change of remaining location names from "our" names to EPR/Cognos names ||
What happens to the ICU Previous Location, Pre-admit Inpatient Institution, Dispo or even Service Location - should they be changed too by the new COGNOS ICU locations? Example current STB_ACCU is SBGH-CCUO in COGNOS, STB_CICU is SBGH_ICCS, STB_MICU is SBGH_ICMS. Should the old labels remain? We need to think hard for its implications to queries of linking and/or matching tables before implementing any change. --JMojica 16:33, 2022 February 2 (CST)
- It would be nice to have this consistent, and yet you are correct that this would tie into a lot of things. I think the benefits of making it consistent win out, though especially when it comes to also thinking about this in terms of that metadata we discussed the other day. Even if we keep the (possibly identical) data in both s_tmp and s_dispo for now, we would then be able to use that metadata table for both. This would require thinking through the details. Julie, I think it only involves you and me, so maybe we should discuss at our wiki meetings? Ttenbergen 13:44, 2022 February 8 (CST)
- Julie and Tina discussed:
- We use the 4 fields Previous Location, Pre-admit Inpatient Institution, Dispo and Service/Location also to map patient flow between laptops, and we very much don't use Cognos values for this (e.g. HSC_Med). We need to retain this ability to use the entries for linking but would also make them the same as Cognos where possible. So we need to keep our "own" values for this for locations where we collect.
- We decided to use manually split CC entries e.g. HSC_MICU vs HSC_SICU since Julie reports in those increments, ie it is hard to pull apart a stay in two ICU types if it is collected as one record. We don't want to lose that.
- We would still like to change these own values to the "modern" values where we use legacy terms, eg. STB ICMS vs STB MICU. As long as we make a clean transition between old and new, or change all old, that should not be a problem, but we need to account for it.
- We could use the Cognos values for all places where we don't collect, e.g. if a pt comes from Ward HSC_A1 and Cognos lists that as HSC-GA1, we could just enter that. However, for locations we don't collect we currently aggregate this to HSC_ward. Do we want the extra detail? It would be easier to enter but might be harder to interpret and possibly even harder to work with for collectors.
- If we want to keep our proprietary value for locations where we collect, and keep aggregate ones for locations where we don't collect, I am not sure which locations that then leaves where we would use the Cognos values?
- Julie, do you agree to that summary? If so, there may be nothing to discuss with Lisa, since we will need to leave this as is. If I am missing something pls update and then pass on to Lisa for her take. Ttenbergen 16:56, 2022 March 23 (CDT)
|2022-03-25 8:23:57 PM|
|edit ||APACHE Acute Diagnoses ||
You and Allan discussed what should be on the list. At some point we will need to integrate the result into this query. Did you end up including Acquireds? Since the first 24hrs might include them, but they might happen later, and the difference is not clear from Dx_Date? Ttenbergen 20:20, 2018 November 24 (CST)
- is this the list which Allan gave about the APACHE Comorbids conditions namely liver, cardiovascular, respiratory, renal and immunocompromised? allan said exclude the admits and include only the comorbids. but we still have to discuss the comparative results. --JMojica 16:45, 2022 February 16 (CST)
|2022-04-21 10:25:56 PM|
|edit ||ER Delay ||
Lisa replied ‘when boarding loc is only ER the arrivedttm equals accept dttm equals first service dttm, dispo time should be the discharge dttm'. I have thought the same – that this is how we were doing it with EMIPs. Can’t find this rule in WIKI.
Before we move to tmp service and boarding loc. I calculated ER delay equals Arrive dttm – accept dttm. Now we added another or second way, ER Delay equals first post-ER Boarding Loc dttm - ER Boarding Loc dttm.
This caused an issue for boarding loc only ER. There is no post-ER boarding loc. if I follow the first way, ER delay is ZERO since arrive dttm is the same as accept dttm.
Should the whole stay at ER be considered as an ER delay or NOT? If yes, then in the past I was underestimating it because all EMIPs have ZERO delay.
If YES in the question above, then we should add this rule for EMIP or ECIP cases
- Arrive dttm equals dispo dttm
- first post-ER Boarding Loc dttm equals dispo dttm
in this way, ER Delay will be consistent in both formulas.
- For discussion. --JMojica 10:17, 2022 March 9 (CST)
- It sounded at task today as if this no longer needs to be discussed, we just need to make sure that this page explains how we now use it in this scenario. Then the question can come out. So, I have moved it to Questions for Julie. Ttenbergen 12:32, 2022 May 4 (CDT)
|2022-05-04 5:32:17 PM|
|edit ||Check CRF vs ARF across multiple encounters ||
Using the ICD10 renal codes, we still need to know when the transition from acute to chronic occurs - so we can decide whether the multiple encounters consistency checking is still relevant. --JMojica 11:51, 2018 November 14 (CST)
- is the transition on the next hospital stay? Example in this hospital stay, patient is diagnosed with ARF and stayed continuously in both ICU and ward in same or different hospital. On the next hospital stay, he is now chronic renal patient.
- Or the transition is on the next ICU or ward stay? Ex. the first stay is ICU and diagnosed with ARF. then patient was transferred in a ward of same or diff hospital - is he now a chronic renal patient?
- The data collection instructions are in the related pages, and additional info is in ICD10 Guideline for Renal Coding, but they are a beast of a network of concepts. Those might tell you how we currently propose to collect the renal codes, but not necessarily what you or the users of the data would want. Usually these cross checks would be driven by what you need for data requests, so do our proposed instructions line up with how you want to use this? Or is this maybe too case-by-case of a concept to even make a cross check? Ttenbergen 18:59, 2019 January 6 (CST)
|2021-12-30 9:31:10 PM|
|edit ||ICU Var 6 - AMA ||Did we transition the following into tmp or otherwise? Ttenbergen 13:58, 2017 June 6 (CDT) If we did not then this question can just be removed, but if we did move this elsewhere we should explain where to.
I can't remember but I can dig up my folders if there is an excel file with this label. or check the data - will put in my to do list --JMojica 17:07, 2022 February 8 (CST) ||2022-02-08 11:07:30 PM|
|edit ||TISS28 data use ||Just came across this page due to a broken link on it. We should clean it out where possible. Most of this is now tracked through indicators etc, so should link there rather than duplicate here. Ttenbergen 16:06, 2022 March 16 (CDT) ||2022-03-16 9:06:59 PM|
|edit ||APACHE Acute Diagnoses ||to be continued by JM ||2022-04-21 10:25:56 PM|