Link suspect negative transit time query: Difference between revisions
Jump to navigation
Jump to search
Ttenbergen (talk | contribs) |
Ttenbergen (talk | contribs) m (→log) |
||
Line 21: | Line 21: | ||
== log == | == log == | ||
* 2022-04-05 - updated to use [[Admit DtTm]] | |||
* 2021-10-07 - changed overlap threshold to 1s because we were getting false positives since arrive dttm and dispo dttm come in at different precision/resolution from Cognos | * 2021-10-07 - changed overlap threshold to 1s because we were getting false positives since arrive dttm and dispo dttm come in at different precision/resolution from Cognos | ||
Revision as of 13:19, 2022 April 5
Data Integrity Checks | |
Summary: | Used in Correcting suspect links to find records where an earlier record for a patient with that PHIN has a Dispo DtTm that is later than the next record's Arrive DtTm. |
Related: | PHIN, Arrive DtTm field, Dispo DtTm field |
Firmness: | hard check |
Timing: | always |
App: | Centralized data front end.accdb |
Coding: | link_suspect_negative_transit_time query |
Uses L Problem table: | no |
Status: | implemented |
Implementation Date: | not entered |
Backlogged: | No |
Generally follow steps in Processing errors in patient data to fix errors found.
Specific error fixing info for this query
- You have to click the hand shake to see the admission the patient
- Most of the error on this query the discharged date of the first admission is after the second admission, if the case is this scenario, I just change the discharged date without looking the EPR
- Sometimes this query triggers as a side effect for errors that are actually link_suspect_mismatch_pre_inpt_should_be_ours_incomplete query, ie error continuous admission the second admission was admitted to ER
Still shows records after errors are fixed
If after correcting the errors in this query it still shows entries, re-do Populate linking pairs and it will update the linking error.
log
- 2022-04-05 - updated to use Admit DtTm
- 2021-10-07 - changed overlap threshold to 1s because we were getting false positives since arrive dttm and dispo dttm come in at different precision/resolution from Cognos
- 08:58, 2019 January 30 (CST): fixed problem with field name in query