Skip to content

Latest commit

 

History

History
99 lines (80 loc) · 6.26 KB

SCAN.md

File metadata and controls

99 lines (80 loc) · 6.26 KB
Raw

Documentation on the Seattle Coronavirus Assessment Network (SCAN) project

Return of results portal

Currently, we return SCAN participant's results via a dedicated page for SFS at the UW LabMed SecureLink portal. (See the private securelink GitHub repo.)

A SCAN participant must provide their collection barcode and date of birth in order to retrieve their results.

The following example data can be entered at the SecureLink dev instance to see a live view what a SCAN participant sees for each of the result codes:

barcode date of birth result pdf
AAAAAAAA 2020-01-01 not-received no
BBBBBBBB 2020-01-01 pending no
CCCCCCCC 2020-01-01 never-tested yes
DDDDDDDD 2020-01-01 negative yes
EEEEEEEE 2020-01-01 inconclusive yes
FFFFFFFF 2020-01-01 positive yes

Note that only the SecureLink dev instance, not the live site, is compatible with these (fake) example data. These example barcodes may one day reflect a real participant's collection barcode, therefore no test data are used on the live production site.

Adding a new study arm

  1. First, answer the questions listed in the barcodes documentation pertaining to creating new collections.
  2. Create a new identifier set.
  3. Create a new barcode label layout for the labelmaker.
  4. Enable REDCap DETs for the new project once testing is complete and it's ready for production.
  5. Update the REDCap DET ETL with the new study's project ID and purview (see example).

    Note: If the new REDCap project is not identical to existing SCAN projects, this may required additional updates to the ETL.

  6. Update the FHIR ETL with the new study's collection identifier set.
  7. Add a new cronjob for the new REDCap DET ETL.
  8. Decide if we need to manually generate DETs (for e.g. if the new study arm uses the REDCap mobile app or API for enrollments)

    Note: we may not have to manually generate DETs if we receive at least one DET for an instrument containing a manually-updated field. If we have other required instruments, then that DET must come after those instruments are complete. This works fairly well if the manually-updated field is in a later instrument, like kit unboxing.

  9. Update the manifest ETL expected collection identifier sets
  10. Update the SCAN RoR shipping view.
  11. Update the reportable conditions shipping view with the new collection identifier set.
  12. Update the backoffice export-redcap-scan script.
  13. Update the export-record-barcodes script in the sfs-switchboard repo with the new language's project ID and purview.
  14. Update the ID3C Glossary with new definitions of how Encounters, Samples, Individuals (etc.) get created for this project.

Adding a new language

Checklist

  1. Insert <span> tags into the REDCap project fields while the project is still in development mode.
  2. Enable REDCap DETs for the new project once testing is complete and it's ready for production.
  3. Update the REDCap DET ETL with the new language's project ID and ISO code (see example).
  4. Add a new cronjob for the new REDCap DET ETL.*
  5. Create a new LaTeX PDF template in lab-result-reports. Translations for the results PDFs live in a Google drive folder accessible via this Trello card.
    • Rebuild the Docker image and push it to Docker Hub (see README).
    • Validate the newly generated PDFs with native speakers.
  6. Update the SCAN RoR workflow in the backoffice repo:
  7. Manually generate PDFs for all data on the S3 results file for the new language.†‡
  8. Update securelink portal:
    • Add new "Next steps" translation and PDF button.†‡ Translations are viewable via the Google drive link at this Trello card.
    • Add new mock results PDFs for local development (e.g. CCCCCCCC-2020-01-01).†
    • Update the get_pdf_report() function in the python module to allow the new language code.
  9. Update the export-record-barcodes script in the sfs-switchboard repo with the new language's project ID and ISO code.

*: Depends on #3

†: Depends on #5

‡: Depends on #6