KB Type: Research Theme
Domain Area: Billing / Plan Architecture
Confidence: Researched (Andrew)
Depth Hint: Standard
Version: 1.0 — 2026-04-26
Status: Active

Level 3 Specialist Support Coordination is uniquely categorised under the NDIS Registration Group R132, setting it fundamentally apart from standard coordination and coaching roles. This distinct classification creates an inherent "ring-fence" around Level 3 funding, restricting claims solely to providers holding this specialised registration. Providers require specialised allied health qualifications to bill under R132, preventing general support staff from accessing these funds. To further protect this funding, NDIS planners typically apply a "Stated" digital lock to Level 3 allocations to guarantee the budget is not depleted by lower-tier supports.

The National Disability Insurance Scheme (NDIS) utilises strict Registration Groups to govern which providers can deliver specific supports to participants. A prominent and highly complex example of this mechanism is the natural ring-fencing of Level 3 Specialist Support Coordination. This highly specialised support is strictly assigned to Registration Group R132, distinguishing it fundamentally from standard coordination roles. Other coordination supports — specifically Level 1 Support Connection, Level 2 Coordination of Supports, and Psychosocial Recovery Coaching (PRC) — all reside under the separate Registration Group R106.

The core operational differentiation between these two registration groups lies in the mandatory qualifications required for staff delivery. Registration Group R132 demands specific, specialised allied health qualifications, whereas R106 allows for broader lived-experience or mental health qualifications, particularly to satisfy the requirements for PRCs. Consequently, agency staff lacking the specific R132 credentials can fluidly pivot between Level 1, Level 2, and PRC roles depending on a participant's flexible funding needs, but they are absolutely prohibited from billing for Level 3 tasks.

To enforce ongoing compliance, providers are strongly advised to configure internal billing platforms, such as the iinsight system, to strictly validate Registration Groups. This proactive billing configuration actively blocks R106 staff from accidentally submitting claims against R132 Level 3 item codes, preventing costly portal rejections.

The unique R132 classification creates an inherent "ring-fence" around Level 3 Specialist Support Coordination, which is explicitly billed using the item code 07_004_0132_8_3. This structural boundary dictates that only registered providers holding the specific R132 designation are authorised to submit claims for payment against a participant's plan that has been approved for this code.

Untangling how these plans operate reveals that even if a participant possesses a substantial flexible budget within Category 07 (Support Coordination), a provider cannot legally or systematically access those funds for Level 3 services unless they natively hold the R132 registration.

Because Level 3 is an intensive and highly specialised support, NDIS planners almost always safeguard these funds by applying a "Stated" designation to the allocation. This functions as a hard "digital lock", ensuring that the protected funding cannot be drained by standard Level 2 coordination or PRC activities. When analysing plans, a provider might encounter different budget architectures, ranging from entirely ring-fenced Category 07 funds to scenarios where an explicit budget is partitioned exclusively for Level 2 and Level 3 within the category.

The enforcement of this digital lock is visualised differently across NDIS portal systems:

Legacy (myplace) system: Providers sometimes used a mathematical heuristic — where an exact multiple of the Level 3 hourly rate implied a digital lock — though explicitly seeing "Allocated Items" marked with a "Stated" status is what definitively locked the funds.

PACE (my NDIS) system: Removes ambiguity by explicitly categorising funds. The PACE interface physically blocks claims from utilising stated allocations for other support types and issues an explicit warning that "Stated supports are intended solely for the purpose of that support" and cannot be swapped.

Providers using platforms like iinsight must configure their systems to: