.. _workflow-reviewer:

Reviewer and Acceptor workflow
==============================

.. contents::
   :local:
   :depth: 2

.. raw:: html

   <style type="text/css">
     span.bolditalic {
       font-weight: bold;
       font-style: italic;
     }
   </style>

.. role:: bolditalic
  :class: bolditalic

Reviewer and Acceptor dashboard
-------------------------------

The Reviewer and Acceptor Dashboard provides access to files that the Submitter has proposed for review or shared with the Reviewer.
  
   .. _figure-reviewer-dashboard:
    
   .. figure:: screenshots/reviewer_dashboard.png
      :alt: Screenshot of Reviewer and Acceptor Dashboard
      :width: 80%
      
      Reviewer and Acceptor Dashboard

.. _reviewer-share-file:

Pre-submission review - shared files
------------------------------------

A Submitter may choose to **share** access to an uploaded file, that they own, before they propose it for review by a Reviewer or Acceptor. Recipients of shared files must be registered in the system and be from the Commonwealth (the department or AIHW).

   .. figure:: screenshots/shared_files.png
      :alt: Screenshot of Shared files page
      :width: 80%
      
      Shared files page


.. _reviewer-propose-review:

Proposed for review
-------------------

Reviewers and Acceptors are notified of files being proposed for review via email. Reviewers then undertake a ‘pre-acceptance review’.

The proposal of files for review is analogous to posting a physical file; it is a formal activity that can only be undone with assistance from the intended recipient.
 

File proposed for review - pre-acceptance checks
------------------------------------------------

Once a file is proposed for review, Reviewers and Acceptors conduct pre-acceptance checks. These checks aim to ensure the supplied information doesn’t contain obvious and significant errors that necessitate a re-submission of the file. Examples of these errors include:
   
   * Incorrect number of variables
   * Mismatch between data and variable types
   * Incorrect formatting of date fields
   * Incomplete information
   * Duplication of key fields
   * Missing link(s) to parent records


Reviewers and Acceptors can use the following tools to review the file:
   
   * :ref:`Data Integrity Reports <data-integrity-reports>`
   * :ref:`Issue Resolution page <issue-resolution>`


**During this phase, the Reviewer(s) can:**

   * View file contents and check validation issues;
   * View resolution codes previously assigned to individual issues.

**During this phase, the Acceptor(s) can:**

   * View file contents and check validation issues;
   * View resolution codes previously assigned to individual issues;
   * :ref:`Accept <reviewer-accept-file>` or :ref:`reject <reviewer-reject-file>` the submission.


Files with the status of :bolditalic:`Proposed for Review` are effectively in control of the Reviewer(s), and can not be un-proposed by the Submitter. If the Submitter needs to replace the file, they must contact the Reviewer(s), advising them to cease work on the file, and request that the Reviewer :ref:`rejects <reviewer-reject-file>` the file.


.. _reviewer-accept-file:

Accept for review
-----------------

Following pre-acceptance review, Acceptors can elect to accept or :ref:`reject a file <reviewer-reject-file>`. 
 
If the file is accepted, Submitters are notified via email when the file is accepted. Control over issue resolution coding transfers to the Submitter, and the :ref:`Review <review>` process is started. 

   .. figure:: screenshots/submission_details_page.png
      :alt: Screenshot of Submission details page
      :width: 70%
      
      Submission details page


.. _reviewer-reject-file:

Reject for review
-----------------

When a file is rejected by the Acceptor the Submitter will be notified and must follow the steps outlined in this document to :ref:`upload a replacement file <replacing-a-file>`.
 
If a file is rejected, control reverts to the Submitter, who is notified that a new file upload is required. Rejection of a file recommences the submission process. Submitters are unable to upload a file that has previously been submitted. 

   .. figure:: screenshots/submission_details_page.png
      :alt: Screenshot of Submission details page
      :width: 70%
      
      Submissions details page - Acceptor view


.. _reviewer-replacement-file:

Replacement file proposed
---------------------------

Submitters may propose a replacement for a file that was previously submitted and accepted if it becomes apparent that updated information should be supplied. 

When a replacement file is accepted, all matching issue resolution statuses and comments are copied to the new submission, preserving the information pertaining to each generation of files. 

If a replacement file is rejected, the submission review process will revert back to the file with the highest batch number that has already been accepted.

.. _review:

Review and issue resolution
-----------------------------

The purpose of the Review is to identify, and explain or rectify inconsistent, anomalous and exceptional issues. During this process the Submitter and Reviewer may assign control over the list of issues to each other as many times as necessary. Assigning control in this manner prevents the Reviewer and Submitter from having write access simultaneously, maintaining the integrity of notes throughout the issue resolution process.

**During this phase, the Reviewer(s) and Acceptor(s) can:**

   * View file contents and check validation issues
   * View resolution codes and comments assigned to individual issues
   * If the Reviewer/Acceptor has control they can also:

      * record comments against individual issues; 
      * assign :bolditalic:`Accept` or :bolditalic:`Reject` codes to individual issues; and
      * assign control of the issue resolution log to the Submitter.

.. _issue-resolution:

Issue resolution list
^^^^^^^^^^^^^^^^^^^^^

The Issue resolution list identifies and explains all inconsistent, anomalous and exceptional issues. This list is used during the Review process with the Submitter assigning control over the list of issues to the Reviewer, and vice versa, as many times as necessary. Assigning control in this manner prevents the Reviewer and Submitter from having write access simultaneously, maintaining the integrity of notes throughout the issue resolution process. 


   .. figure:: screenshots/issue_resolution_page.png
      :alt: Screenshot of Issue Resolution list
      :width: 80%

      Issue resolution list

Clicking on an issue brings up the Issue details modal, via which Submitters assign control over issues to the Reviewer, and vice versa, as many times as necessary. Assigning control in this manner prevents the Reviewer and Submitter from having write access simultaneously, maintaining the integrity of notes throughout the issue resolution process. 

      Issue Resolution list

   .. figure:: screenshots/issue_details_modal.png
      :alt: Screenshot of Issue Details modal
      :width: 70%

      Issue Details modal

      
.. _reviewer-submission-finalised:
      
Finalise submission
-------------------

The submission process is considered complete when all issues have been corrected and/or clarified, and comments and proposed resolutions against each issue are accepted. At this stage, data is regarded as being suitable for reporting and can be manually or automatically transferred to an external data warehouse or reporting system. 

From the **File Details** page, an Acceptor is able to **Finalise** a submission at any point after accepting a file for review. Generally, any issues requiring resolution are addressed first, as once finalised, no further file versions will be accepted as replacements, and issue resolution is locked.

If required, a finalised submission can be re-opened by an Acceptor, allowing for issues to be edited again, and replacement files can be proposed.

   .. figure:: screenshots/reopen_submission_step1.png
      :alt: Screenshot of Submission Details 'Finalise' button
      :width: 70%
      
      Submission Details page 'Finalise' button
      
   .. figure:: screenshots/reopen_submission_step2.png
      :alt: Screenshot of Submission Details 'Re-open' button
      :width: 70%
      
      Submission Details page 'Unfinalise' button
      
Data export 
^^^^^^^^^^^

Processed information is extracted from the data warehouse as it is required, for further use by the data custodians.

Revalidation
^^^^^^^^^^^^

Generally results remain static when a file has been uploaded and validated, however an exception to this is when ALL of the following occur in relation to a file:

   * the MDS Rules for the file type use historical data;
   * a historical file was not found at the time of the original upload; and
   * a historical file was uploaded at a later date.

In those circumstances, a facility exists to revalidate the file.

Users will see a warning explaining that historical checks have not yet been performed, and a button will be present offering revalidation now.

Software updates
****************

Software updates may also necessitate revalidation. These are usually performed as part of the upgrade, however they can be manually initiated by administrative staff.