IT notes related to the N2QOD project

Steps to produce the N2QOD reports (as of October 1, 2019)

$ cd ~/project

$ ./download_data

$ ./check_changes

 $ make enroll_reports 

 $ make audit_reports 

 $ ./zip_numbers_reports yyyy-mm-dd 

 $ ./zip_audit_reports yyyy-mm-dd 

 $ ./upload_reports numbers WEEK MONTH YEAR DATE 

 $ ./upload_reports audit WEEK MONTH YEAR DATE 

• CLASS is either numbers or audit
• WEEK is either "12" or "34".
  • use "12" for 1st Friday numbers reports
  • use "12" for 2nd Friday audit reports
  • use "34" for 3rd Friday numbers reports
  • use "34" for 4th Friday audit reports
• MONTH is the name of the month ("january", "february",...,"december"). Not abbreviated and all lower case.
• YEAR is the year in 2 digits (e.g. "19" for 2019)
• DATE ( as yyyy-mm-dd) is the date that the data was pulled.
• URL is https://redcap.vanderbilt.edu/api/
• TOKEN is biweekly_report.token

./upload_reports numbers 34 september 19 2019-09-19 https://redcap.vanderbilt.edu/api/ biweekly_report.token

Process Review

10 Oct 2019

22 Feb 2016

1. Add code to detect incorrectly formatted dates. Evidently, the date format checking in Redcap does not always work which allows personnel in the field to enter incorrectly formatted dates. Currently, these end up as blank fields after the data conversion step of the reporting process is done. Thomas will add code to detect these bad dates and note them in the reports.
2. Refresh Dale's mirror of the code
3. Produce a diagram for the process used to produce the PQRS surgeon report
4. Produce a diagram for the process used to produce the PQRS XML file
5. Produce a script that Dale can follow to produce the PQRS surgeon report
6. Produce a script that Dale can follow to produce the PQRS XML file

21 Oct 2016

1. surgeon report
2. QCDR patient reports
3. QCR final report
4. xml file production

• Add code to detect incorrectly formatted dates. Evidently, the date format checking in Redcap does not always work allowing personnel in the field to enter incorrectly formatted dates. Currently, these end up as blank fields after the data conversion step of the reporting process is done. Thomas will add code to detect these bad dates and note them in the reports.
• Refresh Dale's mirror of the code
• Produce a diagram for the process used to produce the PQRS surgeon report
• Produce a diagram for the process used to produce the PQRS XML file
• Produce a script that Dale can follow to produce the PQRS surgeon report
• Produce a script that Dale can follow to produce the PQRS XML file

1 Sep 2016

• Make a test run of numbers and audit reports (Dale) (added 9/12/2016). The goal here is to make sure Dale still knows how to do this.
• Make a report that lists the participating centers as of the time the report is run (added 9/12/2016). Came up when we were thinking about the issue where a center did not receive a PQRS report and it is not clear why.
• Document (script) production of XML submission files. The goal is to make it possible for a backup person to produce these.
• Produce flow chart of process of production of XML submission files
• PQRS scripting and documentation
• Documentation and scripting of preparation of data for quarterly reports. The goal is to make it possible for a backup person to produce these.
• More thoroughly comment all the code
• Pay special attention to commenting code that uses regular expressions
• Consolidate common code
• Send an updated flow diagram
• Continue to work on scripts/procedures so backup can run reports when Thomas is on vacation.
• Use a special comment (e.g. ##HARDCODED) to call attention to code that contains hardcoded values. These are possible sources of failure if the condition that requires the hard coding changes. For example, there is a place where a surgeon can be associated with up to 9 hospitals. A periodic sweep of all hard coded values should be made.
• Remove as many uses of hard coded values as possible.

11 Aug 2016

• Thomas will copy latest code to my directory.
• I will see if I can run numbers reports
• Thomas will document procedure to produce data for quarterly reports.

21 July 2016

• Need to know about quarterly reports. What are they? What is the schedule? How produced? Etc.
• It appears that a schema change was made in REDCap between 7/19/2016 and today (7/21/2016). This is causing the report build to fail because there are different variables in one or more of the tables. I was surprised that there was a schema change when the programmer is out of town and a backup is doing the reports?

11 July 2016

Steps to produce the N2QOD reports

$ cd ~/project

$ ./download_data

$ ./check_changes

$ make audit_reports

$ ./zip_audit_reports yyyy-mm-dd

$ ./upload_audit nn month yy yyyy-mm-dd

• nn is either "12" or "34".
  • use "12" for 1st Friday numbers reports
  • use "12" for 2nd Friday audit reports
  • use "34" for 3rd Friday numbers reports
  • use "34" for 4th Friday audit reports
• month is the name of the month ("january", "february",...,"december"). Not abbreviated and all lower case.
• yy is the year in 2 digits (e.g. "16" for 2016)
• yyyy-mm-dd is the date that the data was pulled.

$ R --slave -f out_of_range_report_lumbar.R

$ R --slave -f out_of_range_report_cervical.R

$ R --slave -f out_of_range_report_cerebrovascular.R

Notes on report production

$ ~/project$ find . -type f -name "*csve"
./patient_lumbar.csve
./n2qod_pqrs.csve
./patient_cervical.csve
./surgeon.csve

$ ~/project$ cat download_data
#!/bin/bash

make update

sed -ie 's/^AtlanticNS/Atlantic_NS/' patient_lumbar.csv patient_cervical.csv

make archive

8 June 2016

• More thoroughly comment all the code
• Pay special attention to commenting code that uses regular expressions
• Consolidate common code
• Send an updated flow diagram
• Continue to work on scripts/procedures so backup can run reports when Thomas is on vacation.
• Use a special comment (e.g. ##HARDCODED) to call attention to code that contains hardcoded values. These are possible sources of failure if the condition that requires the hard coding changes. For example, there is a place where a surgeon can be associated with up to 9 hospitals. A periodic sweep of all hard coded values should be made.
• Remove as many uses of hard coded values as possible.

18 May 2016 and 16 May 2016

11 May 2016

9 May 2016

4 May 2016

1. lumbar module
   1. weekly numbers report "numbers report" (PDF) 1&3 Fridays
   2. NPA weekly numbers report "NPA numbers report" (PDF) 1&3 Fridays
   3. NPA accrual numbers report "accrual numbers spreadsheet" (a CSV file) 1&3 Fridays
   4. Quality Audit reports (2 & 4 Fridays) "audit report"
2. (lumbar) deformity module
   1. weekly numbers report "numbers report" (PDF) 1&3 Fridays
   2. NPA weekly numbers report "NPA numbers report" (PDF) 1&3 Fridays
   3. NPA accrual numbers report "accrual numbers spreadsheet" (a CSV file) 1&3 Fridays
3. cervical module
   1. weekly numbers report "numbers report" (PDF) 1&3 Fridays
   2. NPA weekly numbers report "NPA numbers report" (PDF) 1&3 Fridays
   3. NPA accrual numbers report "accrual numbers spreadsheet" (a CSV file) 1&3 Fridays
   4. Quality Audit reports (2 & 4 Fridays) "audit report"
4. cerebrovascular module
   1. weekly numbers report "numbers report" (PDF) 1&3 Fridays
   2. NPA weekly numbers report "NPA numbers report" (PDF) 1&3 Fridays
   3. NPA accrual numbers report "accrual numbers spreadsheet" (a CSV file) 1&3 Fridays
   4. Quality Audit reports (2 & 4 Fridays) "audit report"

2 May 2016

cd work_shop/N2QOD/project
./download_data
./check_changes

make audit_reports
make enroll_reports

./upload_audit ## month yr yyyy-mm-dd
./upload_numbers ## month yr yyyy-mm-dd

• "##" is either "12" or "34". For numbers reports "12"=1st Friday reports, "34"=3rd Friday reports. For audit reports "12"=2nd Friday reports, "34"=4th Friday reports.
• "month" is the month (march, april, may, etc.)
• "yr" is the 2-digit year (e.g. 16)
• "yyyy-mm-dd" is the date used to select the files containing the reports to be uploaded

Issues and Resolutions

11 May 2016