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).
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.
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:
Files with the status of 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 rejects the file.
Following pre-acceptance review, Acceptors can elect to accept or reject a 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 Review process is started.
When a file is rejected by the Acceptor the Submitter will be notified and must follow the steps outlined in this document to upload a replacement 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.
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.
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 Accept or Reject codes to individual issues; and
assign control of the issue resolution log to the Submitter.
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.
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.
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.
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 may also necessitate revalidation. These are usually performed as part of the upgrade, however they can be manually initiated by administrative staff.
