TOOCS Coding Is Data Quality, Not a Liability Finding

A TOOCS code can improve national data and still prove nothing about liability. Use AI after human entry to test version, evidence traceability and cross-field consistency. Keep every correction with a human coder and every statutory finding with the delegate.

Bad coding rarely announces itself. The code exists, the description looks plausible and the extract runs. The defect appears when an analyst groups unlike events or a reviewer cannot trace the choice.

AI can expose that defect after entry. It can confirm that a code exists in the approved TOOCS version, compare linked fields and show where the source trail is missing. It must not select the first code, rewrite an entered code, infer causation or turn an administrative classification into a finding under the Safety, Rehabilitation and Compensation Act 1988.

For a self-insured bank, insurer or superannuation organisation, use a source-to-code proof strip. Record the version, source phrase and location, coding rule, human reviewer and change history. That is stronger than asking whether a code "looks right".

What is TOOCS actually classifying?

Safe Work Australia describes the Type of Occurrence Classification System as the primary Australian system for classifying work-related injury and disease incidents across workers compensation systems and supporting national work health and safety statistics. The current version is Edition 3 Revision 2, or TOOCS3.2. The catalogue records the data as updated in July 2025.

The TOOCS3.2 detailed coding manual contains four hierarchical classification structures, applied in order:

1. Nature of injury or disease
2. Bodily location of injury or disease
3. Mechanism of incident
4. Agency of injury or disease

Four structures produce five linked outputs. The Agency structure supplies the Breakdown Agency, meaning the object, substance or circumstance principally involved in, or most closely associated with, the point at which things started to go wrong, and the Agency of Injury, meaning what was directly involved in inflicting the injury or disease. Collapsing those two fields destroys useful information.

The order matters because the later fields relate to the most serious injury or disease identified at the first step. Nature describes the harm. Bodily Location identifies where that harm occurred. Mechanism captures the overall action, exposure or event. The two Agency outputs describe different roles within the occurrence.

This creates legitimate QA questions. Does a lower-limb location conflict with a source phrase identifying a hand? Are both Agency values identical because the evidence supports that result, or because one value was copied?

Those are questions, not corrections. The manual requires sufficient detail, warns that mechanism keywords can mislead and reserves unspecified location codes for cases where efforts to obtain detail have failed. A short extract cannot safely reconstruct the necessary human enquiries.

Comcare's Entering TOOCS codes guidance applies to its claims environment. Codes are entered at registration, then checked during initial determination. The final code reflects the primary accepted condition and may change when that condition changes.

That sequence supplies the control boundary. The human claims process controls the final coding position. The code does not control the legal outcome. A licensed corporation should apply the same distinction through its own approved claims platform, coding instructions and reporting extract, not assume that Comcare's Pracsys workflow is its local process.

Why can a code never answer the SRC Act question?

The current Safety, Rehabilitation and Compensation Act 1988 is Compilation No. 82, in force from 1 July 2026. Section 5A defines injury and includes the employment connection for a physical or mental injury or aggravation, together with the reasonable administrative action exclusion. Section 5B defines disease by reference to employment contribution to a significant degree. Section 14 states the core compensation liability for an injury that results in death, incapacity for work or impairment, subject to Part II. Those provisions carry their own clocks and evidence demands, which is why statutory timeframes deserve their own AI controls.

TOOCS does none of that legal work. A Nature code describes classified harm. A Mechanism code describes the occurrence for data purposes. Neither proves that employment contributed to an ailment to the statutory degree, that an injury arose out of or in the course of employment, that an exclusion applies, or that section 14 liability exists.

Apparent agreement does not itself prove a statutory finding. A mental-stress mechanism does not establish a disease under section 5B. A workplace-harassment description does not establish events, credibility or the section 5A exclusion. Apparent conflict does not itself prove an error either. It should open an exception, never amend a code or determination.

Licensee reporting makes the separation concrete. The SRCC's Commission Data Warehouse Specifications, version 3.0, dated March 2024, assigns the five TOOCS-based outputs to claim fields, with determination data held separately:

Its validation system checks legitimate codes and specified logical combinations. A failed load is rejected for correction and full resubmission. These are data controls, not merits findings.

Version control needs care. Appendix A.9 still lists TOOCS3.1 for claims with a received by claims processing date on or after 1 July 2008, while also permitting the latest version for any claim. Safe Work Australia identifies TOOCS3.2 as current. Preserve receipt date, recorded version and current manual, then confirm the live warehouse implementation with Comcare before changing or resubmitting data. Do not assume historical claims require bulk recoding.

Comcare's Report 66 page similarly reports liability status and decision date separately from TOOCS-based fields, but it is a Customer Information System report for agency customers. It is not a licensee submission standard. A licensed corporation should use its controlled local and warehouse extracts.

What should AI check after a human has entered the code?

Start after entry and before analytical reuse. Use de-identified entered values, controlled source anchors and approved tables. Return exception types, not replacements. The same source-anchor discipline that governs statement summaries and assertion ledgers applies here: every field points to a document, page or paragraph.

Use five gates:

• Version gate. Record the version applicable to the record, receipt date, local table release and lookup identifier. Do not assume current-version recoding.
• Existence gate. Confirm that each entered code and description pair exists in that controlled version. Flag truncated codes, mismatched descriptions and deprecated local aliases.
• Proof gate. Require a source phrase and anchor for each field. An anchor can be [SOURCE_DOCUMENT_ID], page or paragraph, not a model-generated summary.
• Relationship gate. Test Nature against Bodily Location, Mechanism against the occurrence description, and Breakdown Agency against Agency of Injury. Treat every anomaly as a human-review question.
• Change gate. Preserve the previous code, new code, reason, source, reviewer and timestamp. Never overwrite the history.

This first prompt creates the proof strip after entry. A human coder must inspect every flag, consult the source material and decide whether any controlled change is justified.

Run post-entry TOOCS QA on this de-identified record using only the human-confirmed [APPLICABLE_TOOCS_VERSION] table and source extracts supplied for that version.

Record: [CLAIM_ID]
Entered fields: Nature, Bodily Location, Mechanism, Breakdown Agency, Agency of Injury
Required proof strip: code version, code, description, exact source phrase, [SOURCE_DOCUMENT_ID], page or paragraph, applicable TOOCS rule, prior value and change date.

Check code-description existence, version provenance, missing source anchors, and cross-field tensions. Return an exception register with the evidence on both sides.

Do not select or propose a code. Do not amend data. Do not infer facts, diagnosis, causation, credibility, employment contribution, injury, disease, exclusion or liability. Mark every exception HUMAN CODER REVIEW.

Consider this fictional, de-identified example. [CLAIM_ID] contains a hand-related Nature, a lower-limb location and identical Agency values. Nature points to [MEDICAL_SOURCE_ID], but Location has no anchor and both Agency fields cite [CLAIM_FORM_ID] without a page.

The model flags the Nature-to-Location tension, missing provenance and duplicated Agency pair. The coder may find a second condition, incomplete extract or entry error. Any correction retains the original value. Nothing in that QA result changes a determination.

This second prompt checks whether an approved correction remains reconstructable. A human reviewer must verify the authority, source and final data entry before release to reporting.

Audit the de-identified TOOCS change record for [CLAIM_ID].

Compare the previous and current values against the approved TOOCS version, cited source anchors, human approval and change reason. Identify missing history, unsupported description changes, version mismatch and any statement that treats coding as a legal finding.

Do not validate liability, choose a preferred code, infer why the condition occurred or approve the change. Return PASS only for traceability controls. Send all substantive coding questions to HUMAN REVIEW.

The final control is analytical quarantine. Do not release a record with unresolved version or existence defects into a trend dashboard. Keep relationship flags visible but do not silently exclude them, because an unusual combination may be valid. Report the unresolved QA population separately so analysts can see the denominator and the limitation. The same denominator discipline matters when claims audits select their sample populations.

Do this Monday

1. Freeze the approved tables. Register each permitted TOOCS version, source URL, local release identifier and owner. Block unversioned lists.
2. Add the proof strip. Require source phrase, source anchor, rule, reviewer and change history for the five linked outputs.
3. Run post-entry checks only. Test existence, descriptions and field relationships on fictional records before using any claim extract.
4. Install the legal firebreak. Reject outputs containing conclusions about causation, credibility, sections 5A, 5B or 14, or the correctness of a determination.
5. Route every exception. Assign a trained human coder to review the complete source record and record the resolution without overwriting history.
6. Quarantine reporting defects. Keep version and invalid-code failures out of trend analysis until corrected, and disclose unresolved relationship flags rather than hiding them.

Bottom line

TOOCS is a classification system, not a compressed liability decision. AI can test whether entered codes exist, carry source provenance and form a coherent set worth human review. It cannot choose the code, resolve the underlying facts or apply sections 5A, 5B or 14. The defensible output is a reconstructable exception trail, with every correction and every legal finding still owned by a person.

This article is general information and education only. It is not legal advice, and it is not advice about any individual claim. Decisions under the Safety, Rehabilitation and Compensation Act 1988 are made by human decision-makers on the individual merits of each claim, and claimants have reconsideration and review rights in respect of determinations. Seek advice specific to your scheme and circumstances.

References

1. Safe Work Australia, Type of occurrence classification system (TOOCS) 3rd Edition, current catalogue for TOOCS Edition 3 Revision 2, data updated July 2025. https://data.safeworkaustralia.gov.au/our-datasets/type-occurrence-classification-system-toocs-3rd-edition
2. Safe Work Australia, Type of Occurrence Classification System Edition 3.2: Detailed coding manual, July 2025. https://data.safeworkaustralia.gov.au/sites/default/files/2026-06/Type%20of%20Occurrence%20Classification%20System%203.2%20-%20Detailed%20coding%20manual.PDF
3. Comcare, Entering TOOCS codes. https://www.comcare.gov.au/sites/default/files/docs/Entering-TOOCS-codes.pdf
4. Safety, Rehabilitation and Compensation Commission, Commission Data Warehouse Specifications, version 3.0, March 2024. https://www.srcc.gov.au/about-us/publications-and-resources/documents/publications/guidance-publications/commission-data-warehouse-specifications-vn3.0-march-2024.pdf
5. Comcare, 66. Customer data report - claim detail (CIS report). https://www.comcare.gov.au/claims/employer-information/access-claims-information/report-66
6. Federal Register of Legislation, Safety, Rehabilitation and Compensation Act 1988, Compilation No. 82, in force 1 July 2026. https://www.legislation.gov.au/C2004A03668/latest/text