| ||check summary||question||app|
|Check CCI CXR vs LOS||Confirm that a Category:Labs Imaging count is not unreasonably high||would we not use Accept DtTm here? Because we could have CXRs on days before arrival...||CCMDB.accdb|
|Check ICD10 some cant be primary||Dxs in Category:Pathogens or Category:Antibiotic resistance must not be Primary Admit Diagnosis.||Como Admit Acquired Primary Limits - Category:Mechanism would need to be excluded as well, and so would past history, and quickly the list gets so large again that we are back at discussing Controlling Dx Type for ICD10 codes where we should simply include "Primary"-ability.
- AG OBSERVATION --- we will just take care of this when we take care of Admit/Comorbid/Acquired
|Check VAP acquired only first encounter||VAP should only be Acquired Diagnosis on the first encounter.||We decided that VAP can actually happen in medicine if pt admitted from ICU. How would we deal with that for this check?||Centralized data front end.accdb|
|Check pre acute consistent||consistency of Pre acute living situation; Dispo; Postal Code and Previous Location||what exactly do we want to check for? Please also have a look at the stuff below that doesn't specifically have your name. This requested check ties into a bunch of things and if we want the check we need to be sure that instructions stay consistent and lose ends are tied up.|
from a data perspective, what do you mean by "admitted directly"? If I were to build a check, where would I find that? OR maybe I don't need to know, but then I need to have a definition of what combination of data would be an error.
- ... unless they are discharged somewhere else entirely, like another ward. So what do we really mean with this? That they can't come from one PCH and go to another or maybe "home" after all?
- I realize this maybe hard to do. what I mean here is that if one is already a PCH resident, when leaving the hospital, the dispo location must be a PCH location too. or is a patient is already in CHF, the destination when leaving the hospital must either be a CHF or another PCH.
- The listed postal codes are correlated to the items ‘PCH’ and ‘Chronic Health facility’ of the Pre-Acute Living Situation. Since the data collectors are collecting the postal code from the patient’s address, will it be possible to automatically fill up the Pre-Acute Living Situation as PCH or Chronic Health facility if the PCH postal codes are entered or ‘other ways’ to link the two fields and make them consistent. Info about PCH is now getting more attention/request. Tina, Will this be hard to do? Any suggestions?
- I have changed my mind to add the PCH postal code to the Postal_Code_Master due to the possible effect on its size (when adding a new column containing text where most of the records will only be blanks). It is better to have it in separate table since this pertains to Winnipeg area only. I have added the exact address of these PCH facilities - link to table in email sent on Jan 12.18 at 1224 hrs from p:Julie Mojica
- Is any change to CFE still required then? If not, please remove this discussion and heading. Ttenbergen 15:47, 2019 July 4 (CDT)
How does Chronic Health Facility fit into this? Or Imprisonment/incarceration and other info in Prison / Jail / Correctional Institution?
There was talk about comparing Postal Codes to known PCH Postal Codes. Since these might include other buildings at the same site that are not PCHs, this check can at best be a soft check. Please add the list of these postal codes here.
|Controlling Dx Type for ICD10 codes||Controlling Dx Type for ICD10 codes||Como Admit Acquired Primary Limits 1/ Dx grouping - this is part of both of those discussion
- I have emailed Allan the table with all Dxs to set them as Como_allowed, Admit_allowed, Acquired_allowed. Will set up infrastructure to contain this once I have data. Ttenbergen 12:31, 2019 February 13 (CST)
- Allan won't have a chance to review until at least mid Sept 2019
|Function long LOS()||LOS/Length of Stay should not be unlikely long based on historical LOS for a given ward (Service/Location field).||Change from Service Location to Service, Boarding Loc and Transfer Ready DtTm tmp entry changed Service/Location to aggregate values for the whole stay in a program. The values used in s_dispo table for the longest likely LOS were filled with previous entries from the same program, but should likely be longer now, since an aggregate stay would on average be longer. Once we have some data with the new aggregate model we should update these values.||CCMDB.accdb|
|Query check ER Delay not too big||Unusually long ER Delay||CCMDB.accdb|
|Query Import request matcher||Records in for which we have patients in L_Log but no lab records from DSM||This one is fairly easy, Pagasa will try to make it. Decided ages ago, but put on Pagasa's list today.||DSM Labs Consistency check.accdb|
|Query NDC CLI vs DX but no TISS17 CentralLine||Checks for patients who have a Iatrogenic, infection, central venous catheter-related bloodstream infection (CVC-BSI, CLI) but no T17 - Central venous catheter (TISS Item).||
T17 has been retired and replaced by CVC presence, any location. There is discussion on whether some changes in that batch will need to be reverted. If they are, then this cross-check would need to be re-defined.
|Query NDC Dxs vs TISS Dialysis||If there is a TISS28 entry for Hemodialysis there should be a corresponding Dx.||Would we need to add COVID to this before implementing?||CCMDB.accdb|
|Query NDC Trach Dx TISS||Tracheostomy ICD10s and CCIs must be consistent with Trach TISS.||CCMDB.accdb|
|Query NDC cardioversion dx vs TISS||If pt has Acquired Procedure Cardioversion (EXCLUDE defibrillation-we are not tracking), then the TISS28 item T41 - Cardioversion (TISS Item) (T41) must be marked.||
|Query TISS Errors CAM positive vs Dx||Checks that each T9 - CAM positive (TISS Item) goes with an ICD10 code from Category:Delirium||AJTT
- I started implementing this and then started wondering if there might be many more dxs that may or may not cause CAM positive (eg Encephalopathy, NOS). Is this a reasonable check to run?
|Query TISS Errors ETT consistent||Checks that ETTs are only removed if previously present and only added when not present.||
A patient might arrive intubated, so there would be no intubation. Does this check really make sense? Ttenbergen 23:23, 2019 March 25 (CDT)
- I have revised the conditions, pls check if they now make sense.--JMojica 16:38, 2019 July 9 (CDT)
- Actually, no: Someone can arrive intubated from another ICU and then be extubated their first day here. I don't see how Insertion can be included in these two. Ttenbergen 20:13, 2020 December 2 (CST)
|Query TISS Errors NrTISSDays NE LOS||Length of stay (LOS) for all ICU patients must be consistent with their number of TISS days, incl no TISS days at all (ie missing forms).||Is this check actually needed?
|Query check CCI must have entry||There must be at least 1 CCI entry in L_CCI_Picklist table (which might be No procedure performed)||
Patients without CCI entries are slipping through and found by PL missing L Tables content , must fix PTorres 09:42, 2019 February 7 (CST)
- I seem to remember discussing this with Pagasa. There was a misconception that a "no CCIs" had to be present in both component and picklist, but that is not true: it only needs to be in the Picklist. Is this still a problem? If so, please tell me an example when one comes up.
- Michelle sent email 2019-10-31 that she was able to click "D" with no CCIs entered. I tested on my copy and got an error when I tried. Will need more info about the scenarios where this can slip through.
|Query check ICD10 duplicates||ICD10 Diagnoses (except for Category:Pathogens or Category:Antibiotic resistance and Category:Mechanism) can't be entered in duplicate.||CCMDB.accdb|
|Query check ICD10 trach dxs consistent||Tracheostomy related CCI and ICD10 codes must be consistent with each other.||CCMDB.accdb|
|Query check has service entry||make sure each record has at least one Service tmp entry||
- This probably needs to be considered in context of Minimal Data Set - if it is part of that it changes the check time (ie for all records or only for complete records?).
|Query check has transfer ready date or checkbox||Each Transfer Ready DtTm tmp entry has to have either a dttm, or its checkbox checked.||
- Currently only implemented without the comment cross checks because almost all collectors are not following the instructions.
- I had a hunch that at least some collectors aren't entering the comment field as instructed and wanted to know how common a problem this cross check would find, so I tweaked it to run in CFE and checked (SQL at bottom). There were over 1000. People seem to be using the field to indicate which TRDT is for which Boarding Loc. Which is reasonable, because hard to keep track of otherwise, but it means I can't do that check for now.
- Do we want to change the instructions to match what people are doing? Or change the cross check?
|Query check long transfer delay||Is the Transfer Delay unreasonably long?||
- Requiring notes to have content is really a very soft error check... do we need to consider something better?
- 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)
- 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)
|Query check tmp Service and Boarding Loc during admission timeframe||Service tmp entry and Boarding Loc date and time var need to be between Accept DtTm resp Arrive DtTm and Dispo DtTm.||
- Accept DtTm resp Arrive DtTm are largely duplication of the Service tmp entry and Boarding Loc dates and times. I believe we had discussed that we should therefore remove those fields eventually. So we should not implement a check now on fields we are planning to get rid of shortly.
- Even if we kept the fields, Accept DtTm is only to be entered for pts from ER, so would not always be there, and the Service tmp entry start dttm could well be before the arrive dttm.