Instructions for requesting a batch of data from DSM

This article describes how to generate the requestor file for the DSM Lab Extract. The file is stored on a file share that DSM can access.

How frequently to request

We will request quarterly.

Initially our DSM contact had concerns about workload and wanted a lower frequency, but then he said "Send on the ‘requestor’ file as often as you want to see the output and I will make the time." (as per email from Alun Carter, Monday, February 06, 2017 10:50)

Instruction/steps for requesting data

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
     • PHI.mdb
     • CCMDB.mdb
2. open DSM Labs Consistency check.accdb
3. Reconnect all the tables
   • right click L_Log and then click Linked table manager
   • Click Select all then OK.
   • Template:Discussion Steps
4. pick the SentDtTm field range for which you want to export
   • "SentDtTm beginning" should be the day after the last end date as per #Log below
   • "SentDtTm ending" should be at least 28 days ago (see #why SentDtTm field and 28 days)
5. click the "Export requestor file" button
6. follow the wizard, which will export a file to the shared folder and start an email to DSM
7. close Access and delete files you had copied
8. enter at the top of the log below when you requested data, and for what range

why SentDtTm field and 28 days

SentDtTm field was used because if we used the dispoDtTm we would miss patients that were collected late due to vacation or missed record.

28 days was used because the request includes incomplete records and the delay reduces the chances that new and unsettled data is included in the request. For example, a collector may have incomplete PHINS and charts on recent and incomplete patients. By 28 days later even any long-stay patient who is still incomplete should have this data, and it should have been corrected via Pagasa's Centralized data Vetting Process if there were errors initially.

Also, this should prevent having anyone with a missing Dispo_DtTm in the batch, where the dispo date later gets filled in but turns out to be before the end of the batch sendDtTm range. (not sure if that's important... the import would then limit it to the DispoDtTm once it arrives, so for this it would be more relevant to not import until 28 days after, not to not export request until 28 days after.

missing dispo dates

if at import time a dispo dttm is still missing it will be replaced with Now().

Log

eg copy/paste and fill in the following: 
* ~~~~~ - requested labs for SendDtTm from ... until ...

• 10:08, 2017 September 6 (CDT) - requested labs for SendDtTm from 2016-12-31 until 2017-07-26.
• 14:10, 2017 March 14 (CDT) - requested labs for SendDtTm from 2016-09-01 until 2016-12-31
• 16:05, 2016 October 17 (CDT) - requested labs for SendDtTm from 2016-08-01 (but use 1980-01-01 for import because first one) until 2016-08-31
• 2015-12-?? - Discharge date 2015-04-01 - 2015-04-30