Supporting Potential · Systems Scoping (Core) · Working Document

Quality-First Operating Model

A first-principles map of what frontline supports need to work well — built from the ground up, then mapped against Achieve's existing systems. The starting question is not "what does compliance require?" but "what does a support worker need on any given shift to support someone well?" Compliance attachment points are shown separately below the core flow.

How to read this: The core loop shows what quality-first looks like in sequence. Each node is coded: Exists the foundation is already at Achieve — Adapt the foundation exists but needs restructuring — New build this does not currently exist at Achieve. The model does not require replacing what works. The goal is to find the minimum set of changes that make the quality loop close.

The core quality loop

Exists Foundation in place at Achieve Adapt Foundation exists — needs restructuring New build Does not currently exist at Achieve
01
Adapt
Know the person
Who they are, what matters to them, their health needs, goals, risks, and communication style. The foundation everything else builds on. One source of truth, kept current.
Currently at Achieve Person records in Connect (SIL, live June 2026) and VisiCase (Day Programs, Respite). Support plans exist. Connect go-live is a timing opportunity to reset plan format.
What needs to change Plan format restructured to be worker-facing: what to do, what to look for, what to do if. Not a compliance document — a working guide accurate enough to use on shift.
02
Adapt
Prepare for the shift
Worker knows: who they are supporting today, what routines matter, what to look for, any changes from yesterday, and what protocols are live. Information delivered, not hunted for.
Currently at Achieve RosterOn handles scheduling. Connect holds the support plan. The two are not joined — the roster does not surface plan context at shift start.
What needs to change Structured shift-start information: who I'm supporting + what's live for them (health alerts, recent incidents, upcoming reviews). Low technology requirement — structured handover template achieves most of this.
03
Exists
Deliver the support
The actual work: personal care, community access, meals, health management, social connection. Workers know what good looks like for this person and have what they need to achieve it.
Currently at Achieve This is what the frontline does. The work itself is not the gap. What surrounds it is — the information workers arrive with and what they can do when something doesn't go to plan.
What needs to change Protocols accessible and understood at point of care. Escalation thresholds unambiguous: "if X, do Y, contact Z" — not "refer to the relevant procedure."
04
Adapt
Observe and record
Shift notes capture what actually matters: health observations, behaviour patterns, what was different, what worked, what needs follow-up. Simple enough to do well at the end of a shift.
Currently at Achieve Shift notes exist in Connect. Structure is currently oriented toward compliance tick-boxes rather than meaningful observation.
What needs to change Note structure includes: domain-based observation fields (health, behaviour, social), a clear flag for "needs follow-up," and explicit link to the person's health alerts and plan goals.
05
New build
Review — proactive and scheduled
Someone looks across the observations for the people in their service — not only when an incident is reported. Regular cadence. Patterns visible before they become crises.
Currently at Achieve Review happens reactively: incident review, annual plan review, Commission audit. No scheduled proactive service-level review exists. The CEO report confirms "compliance relies heavily on individual manager oversight and periodic audit rather than embedded controls."
What needs to change Scheduled review cadence at site level. Structured questions: whose plan is out of date, who has had a cluster of incidents, who has not been to a GP in six months, who is not progressing on their goals.
06
New build
Surface and learn
Patterns across people and sites aggregate upward. Plans are updated. Training is targeted. The system improves because someone is looking at the set, not just the individual.
Currently at Achieve The CI register exists but records individual items — it does not aggregate patterns. Each fix is singular. The loop closes per-incident, never per-theme. No mechanism takes a set of closed items and asks what they share.
What needs to change Pattern aggregation function: who holds it, what triggers it, what questions it asks. This is not primarily a technology problem — it is an accountability question.
← Loop closes here
Learning updates the person record and plan — loop restarts

Where compliance steps attach

These are genuine additions that don't fall out of quality naturally — they are required by the NDIS Practice Standards or legislation regardless of what the quality model looks like. The goal is to attach them to specific nodes in the quality loop, not run them as a parallel system. Current state at Achieve is shown for each.

Requirement Attaches to What it adds beyond quality Current state at Achieve
NDIS Practice Standards — intake documentation (PS 2.1) 01 Person Formal documented consent, service agreement, rights and responsibilities at commencement Exists — Connect intake process handles this for SIL
Mealtime management plan (SLP/dietitian sign-off) 01 Person External clinician sign-off, formal plan, review schedule triggered by clinical events — not just calendar Gap identified — 13% not current (April 2026 blitz); currency gap closed; quality review (accuracy, staff training, support plan reference) not done; tracking spreadsheet disconnected from Connect and Power BI
Behaviour support plan and restrictive practice authorisation 01 Person 03 Deliver NDIS-registered BSP sign-off; state-level authorisation for each restrictive practice; implementation fidelity record Partial — plans exist; Connect migration scope for implementation recording not confirmed in this engagement
Medication management 03 Deliver 04 Observe Medication authority on file; administered as charted; PRN recording; pharmacist review triggers Partial — medication charting exists; scope and format in Connect not assessed in this engagement
Reportable incident notification (NDIS Commission) 04 Observe External notification within Commission timeframes; investigation report; Commission correspondence Exists — routes through OCG; four matters open as at June 2026 CEO report. The notification step works; the internal learning loop back from Commission response is the gap
Annual plan review (PS 2.2) 05 Review Documented review with participant, goals updated, supports adjusted — within NDIS funding review cycle Exists — annual review cycle in place. Proactive triggers for between-review changes are the gap
NDIS quality indicator evidence 05 Review 06 Learn Documented evidence that each Practice Standard indicator is met — available for audit on request Partial — evidence generated event-by-event; no standing evidence base; audit preparation is a sprint, not an ongoing process
Continuous Improvement Register 06 Learn Formal record of improvements identified and actioned — required by NDIS Practice Standards Exists — CI register maintained with 191 entries. Pattern aggregation across entries is the gap (see CI Register deep dive)

The structural shift this model makes

Current model — compliance as the skeleton

Achieve's current operating model runs a quality system (support plans, shift notes, incident reports) and a compliance system (CI register, Commission notifications, audit evidence) in parallel. They share some data but were built separately, are owned by different functions, and reported through different channels.

The frontline experience: documentation fills compliance, not learning. Reviews happen when something goes wrong or when an audit is due. The organisation improves when it is prompted externally, not when it notices something itself.

This is not a criticism of the people who built it. It is what happens when systems are added reactively, one compliance requirement at a time, without a quality architecture underneath.

Quality-first model — compliance as attachment

Compliance steps attach to the quality flow at specific nodes rather than running as a separate system. The shift note is also the health observation record. The plan review is also the annual review evidence. The CI register captures what the review and learning cycle surfaces, not what someone inputs separately for audit purposes.

The frontline experience: one set of tasks, not two. Documentation serves the person first and compliance second. Quality data is available in real time rather than reconstructed when an audit is called.

The Commission's current enforcement direction — checking that systems work, not just that they exist — is easier to demonstrate from a quality-first model than from a compliance-first one.

What the model doesn't answer yet
The two nodes marked New build — proactive review (05) and surface and learn (06) — are not primarily technology problems. They are accountability problems. Someone has to own the review cadence. Someone has to own pattern aggregation across people and sites. The model defines what those functions need to do; it does not yet say where they sit. Until that question is answered, the quality loop has no close. Good documentation goes in; nothing structured comes back out.