The Submitter Dashboard provides access to files that the Submitter has recently worked on, or that have upcoming deadlines for action, along with a summary of their status.
After the file is uploaded and the validation process is complete, an email is sent to the Submitter informing them of the file’s status and providing a link to the online validation reports.
Files are uploaded in .DAT format. Files can also be uploaded in .ZIP format, however these files can not be password protected. The upload link is encrypted, protecting information in the file throughout the submission process.
The data file must have a formal name consistent with the format of Tsssyyyybbbbb.DAT. Note that the filename is case sensitive. The T, sss, yyyy, and bbbbb components are defined as:
T - File type (CMHC, MHE, NOCC, RMHC, or SKL)
sss - Jurisdiction code (ACT, NSW, NTE, QLD, SAU, TAS, VIC, or WAU)
yyyy - Year of the end of the financial year for the batch submission
bbbbb - Yearly incremental batch number (leading zeros present) indicating the sequence number of the submission. Note that
successive quarterly files and any resubmitted files must have a batch number greater than all preceding files for that year.
Example
Suppose that the ACT submitted quarterly data files to AMHOCN in respect of the 2020-21 financial year, then submitted a
final submission; their first NOCC data file would be named NOCCACT2021000001.DAT, whilst the second would be named
NOCCACT202100002.DAT, and so on. If no resubmissions were made the final submission for that year would be named
NOCCACT202100005.DAT. If that file then had to be resubmitted for some reason, then it would be named NOCCACT202100006.DAT.
Their first submission for the 2021-22 financial year would then be named NOCCACT202200001.DAT.
The Online Validator provides two types of validation: record integrity validation and consistency validation. Record integrity validation issues may prevent a file from being proposed; please see Record integrity report for more information.
A Submitter may choose to share access to an uploaded file, that they own, with other users at any time. Recipients of shared files must be registered in the system, and be either from the Submitter’s jurisdiction or from the Commonwealth (DoH or AIHW). Sharing options are accessed via the File Details page.
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.
After a file is proposed for review, it can automatically be viewed by other jurisdictional users with access to the same dataset. Users with identical access privileges as the file’s Submitter can comment, delete and propose new files for review.
Reviewers are notified of file submissions via email. Reviewers will then undertake a ‘pre-acceptance review’.
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
During this phase, the Submitter can:
View file contents and check validation issues;
View resolution codes previously assigned to individual issues.
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.
If the file is accepted, submitters are notified via email. 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 proposed for review.
Submitters may propose a replacement for a file that was previously proposed for review and either accepted or rejected, if it becomes apparent that updated information should be supplied.
When a replacement submission 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 submission is rejected, the proposal review process will revert back to the file with the highest batch number that has already been accepted.
The replacement file must meet the following criteria:
Successfully uploaded and validated
Batch number must be higher than the current proposed file
No other file can be pending as a replacement. If you have already proposed a file, you will need to have it accepted or rejected before you can propose another.
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.
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 Entity Mapping Tool enables entities to be mapped across time in the SKL files. This in turn enables the Online Validator to suppress ‘child’ issues that are caused by entity changes. For example, a change to an organisation’s name and ID will generate an issue for that change, and for each of that organisation’s ‘children’, whose parent ID has now also changed. Mapping the organisation to its historical name and ID will then suppress the issues against the organisation’s children.
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 marked by an Acceptor as Finalised and is regarded as being suitable for reporting. The data can be manually or automatically transferred to an external data warehouse or reporting system.
Acceptors are 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.
