Query Import request matcher: Difference between revisions
Jump to navigation
Jump to search
Ttenbergen (talk | contribs) mNo edit summary |
Ttenbergen (talk | contribs) |
||
| Line 27: | Line 27: | ||
Could happen if we change/fix a D_ID after requesting. Problem is, we can find if one doesn’t exist, but not if one was changed, but the one that was in the export is actually in present now. Not sure how we would catch that. | Could happen if we change/fix a D_ID after requesting. Problem is, we can find if one doesn’t exist, but not if one was changed, but the one that was in the export is actually in present now. Not sure how we would catch that. | ||
{{Discuss | who = | {{Discuss | who = tina| | ||
* This one is fairly easy, Pagasa will try to make it. Decided ages ago, but put on Pagasa's list today. | * 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.[[User:PTorres|PTorres]] 14:25, 2022 March 17 (CDT) | ** We only send Vetted data to Allun now.[[User:PTorres|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. [[User:Ttenbergen|Ttenbergen]] 16:55, 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. [[User:Ttenbergen|Ttenbergen]] 16:55, 2022 March 17 (CDT) | ||
**** Discussed with Julie; we will only request vetted (not discontinued) but I need to update the DSM and discuss with Pagasa. [[User:Ttenbergen|Ttenbergen]] 16:47, 2022 June 8 (CDT) }} | |||
=== re-request === | === re-request === | ||
Revision as of 16:47, 2022 June 8
| Data Integrity Checks | |
| Summary: | Records in for which we have patients in L_Log but no lab records from DSM |
| Related: | Instructions for importing a batch of DSM Data, Instructions for requesting a batch of data from DSM, DSM Labs data.accdb |
| Firmness: | |
| Timing: | |
| App: | DSM Labs Consistency check.accdb |
| Coding: | query Import_request_matcher |
| Uses L Problem table: | not relevant for this app |
| Status: | needs review |
| Implementation Date: | |
| Backlogged: | true |
D_IDs in CFE for which no DSM labs exist
Instructions
- Open query Import_request_matcher in pivot chart or pivot table view. The percentage should be higher than 97%, if it is lower, review.
Scenarios
- legitimately no labs done (pt dies before labs are done, palliative, short stay)
- In the past we would have entered a "no labs" for these. Do we want to do something similar? It would have to be something Pagasa enters; not sure based on what. Might be a lot of extra work. Need to review. For now we do not have an entry like that. And it might not be worth it - what would Pagasa do to check that the no-labs are legit?
- Alun unable to match
- eg. we have a bad Chart number / PHIN - Pagasa could review and fix our data and re-request; added benefit would be data validation
- would we expect other reasons why data is present with DSM but Alun would be unable to match?
- we change/fix a D_ID after we request data (ex. wrong D_ID when exported but found it error and so fixed it before the data for import comes back)
- Pagasa would need to #re-request data for this patient
D_IDs in DSM data for which no CFE record exists
Could happen if we change/fix a D_ID after requesting. Problem is, we can find if one doesn’t exist, but not if one was changed, but the one that was in the export is actually in present now. Not sure how we would catch that.
|
|
re-request
We would not want to re-request separately for each problem found, or Alun would get annoyed with us. so Pagasa would need to manually track these somehow to add to the next request. We would need to document that process here (or possibly in a separate page, if any other DSM queries result in need to re-request...).