Australian Mental Health Outcomes and Classification Network
Sharing Information to Improve Outcomes

Skip to content | A+ | A- | Reset

Current Size: 136%

NOCC data set business rules

The NOCC Technical Specifications (insert link) requires non-overlapping episodes i.e.

  1. One episode of care at a time

  2. Change of setting implies a change of episode

When the source data hasn’t been collected in this manner then some massaging could correct Sequence errors and reduce overall data loss. These guidelines are suggestions for possible ways to resolved some of these issues, but the details of the resolution used is best judged by the submitting jurisdictions in light of their collection systems and protocol.

From Appendix B. “Where a person might be considered as receiving concurrently two or more episodes of mental health care by virtue of being treated by the organisation in more than one setting simultaneously, the following order of precedence applies: Inpatient, Community Residential, Ambulatory”.

The NOCC validator and other data processes apply these rules strictly to submitted data, which in cases of overlapping care periods in submitted data leads to errors and the filtering of conflicting data. Within the Validator these are called “Sequence” errors and are attached to the COD records causing the conflict.

While clinical practice and data collection commonly accept overlapping data, overlaps should be removed for the purposes of NOCC submissions. As a matter of policy, we don’t edit submitted data, but we would like to enable submitters to better analyze, correct and filter NOCC data submissions to reduce or eliminate all Sequence errors.

Reporting of Sequence issues has evolved over the years, but using the Online Validator we hope to be able to provide timely and useful reports on episode sequencing problems, aiding their resolution and removal.

To that end we are emphasising the issue and hope to enlist the help of jurisdictional submitters.

Goal 1: Improve Reporting of Sequence Errors

There is already basic reporting of “Sequence” errors, but we would like to improve this. Submitter feedback on the type of reports or documentation that would be useful in building a protocol complying file would be invaluable. We hope to improve reporting within this cycle, but some improvement will no doubt have to be deferred.

Details of changes that we apply will be sent to jurisdictions as we progress.

Goal 2: Reduce Sequence Errors

The reporting in Goal 1 is primarily to enable submitters to build Sequence error free files. We envisage that some informed massaging of data may be required and would like to know what support is needed to do so.