Instructions for importing a batch of DSM Data

Preliminary information, this is not active yet

see Instructions for requesting a batch of data from DSM for counterpart

We receive data from DSM that needs to be imported into our main repository.

Instructions

1. copy files to local, they are large and won't work well on a share.
   • make a new local directory
   • Put the following into the directory
     • Centralized_data.mdb
     • DSM_Labs_Consistency_check.accdb
     • not needed - PHI.mdb is not needed during import because it matches by D_ID
2. copy the newly received batch of data from DSM_Lab_Extract#File_Share to directory
3. Open DSM_Labs_Consistency_check.accdb
4. Set the start and end date of the time range for which you requested and received the file you are about to import
5. click the "Import DSM .csv" button
6. pick the newly received file
7. follow instructions; the import takes about 5 minutes to run now during which the program will not respond to further interaction. There will be a progress indicator at the bottom right of the window, as long as it is going the program is still working. When the program is done it will display a message box to say so, and indicate how long it took.

(once out of testing)

1. Move Centralized_data.mdb back to master directory
2. Move DSM_Labs_Consistency_check.accdb back to its master location; it likely contains new group and lab info now.
3. enter import date in log below

Integrity checks after import

Tina has a task for additional checks that might be set up.

D_IDs in CFE for which no DSM labs exist

This could happen if

• we have a bad MRN / PHIN
• we change/fix a D_ID after we request data

Template:DiscussionThis could also be true where no labs were sent for, eg a patient who dies shortly after arrival. In the past we would have entered a "no labs" for these. Do we want to do something similar? It would have to be Pagasa that does it. Might be a lot of extra work. Need to review. (ex. wrong D_ID when exported but found it error and so fixed it before the data for import comes back).

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.

Duplicate RequestNo

Should never happen due to how import works, but can check anyway.

Known issues

need to re-launch program after every few imports import

If something goes wrong during one import enough garbage is left in the file that subsequent imports won't work unless the program is closed and re-openend, which triggers a compact-repair.

How does it work

• Lab identification in the DSM data

Log

eg copy/paste and fill in the following: 
* ~~~~~ - imported batch