Query Import request matcher: Difference between revisions

From CCMDB Wiki
Jump to navigation Jump to search
mNo edit summary
Line 12: Line 12:


=== D_IDs in CFE for which no DSM labs exist ===
=== D_IDs in CFE for which no DSM labs exist ===
This could happen if
Scenarios
* legitimately no labs done (pt dies before labs are done, palliative, short stay)
* 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?'''
**  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
 
* we have a bad MRN / PHIN
* 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, to a point
 
* 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)
* 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


{{Discuss |  
{{Discuss |  
* We are expecting proportion of unmatched records each time. Last email from Alun had 1%, not sure what it has been over time. So, anything that shows up on this list might just be something Alun could not match, and it might even be a case of a patient legitimately not having any labs. So, what do we actually want to list, and what would Pagasa do with any contents of the list? }}
* We are expecting proportion of unmatched records each time. Last email from Alun had 1%, not sure what it has been over time. So, anything that shows up on this list might just be something Alun could not match, and it might even be a case of a patient legitimately not having any labs. So, what do we actually want to list, and what would Pagasa do with any contents of the list? }}


==== D_IDs in DSM data for which no CFE record exists ====
=== 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.  
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.  


{{DT | This part of the cross-check is now well understood and ready to program. }}
{{DT | This part of the cross-check is now well understood and ready to program. }}
=== 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...).


[[Category:DSM Labs Extract]]
[[Category:DSM Labs Extract]]
[[Category:DSM check‎‎]]
[[Category:DSM check‎‎]]

Revision as of 15:45, 2019 April 17

Data Integrity Checks
Summary: Records in for which we requested DSM data but did not receive any.
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 NDC_DSM_Unmatched_records
Uses L Problem table: not relevant for this app
Status: needs review
Implementation Date:
Backlogged: true
  • Cargo


  • SMW


  • Categories: 
  • form:

D_IDs in CFE for which no DSM labs exist

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, to a point
  • 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)
  • We are expecting proportion of unmatched records each time. Last email from Alun had 1%, not sure what it has been over time. So, anything that shows up on this list might just be something Alun could not match, and it might even be a case of a patient legitimately not having any labs. So, what do we actually want to list, and what would Pagasa do with any contents of the list?
  • SMW


  • Cargo


  • Categories

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.


This part of the cross-check is now well understood and ready to program.

  • SMW


  • Cargo


  • Categories

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...).