General interface
Shift management
Shift distributed to worker
Report review
Drafting note

Assura

Speak the shift. Surface the risk.

Inspiration

Assura began with a simple question: what happens after an NDIS support worker finishes a shift?

The worker’s main responsibility is supporting the participant, but the shift also needs to become a clear and accurate record. NDIS providers must retain evidence such as case notes, support logs, rosters, invoices, and service agreements. These records may later be used for service coordination, payment reviews, and audits. Providers must also identify, record, assess, and manage incidents that occur during service delivery.

The problem is not a lack of documentation. It is the volume and structure of that documentation.

An Australian study involving 135 aged-care and disability-service staff found that larger sites could face hundreds of progress notes. Participants described duplicate entry, disconnected forms, excessive free text, delayed documentation, and difficulty searching or reporting on collected information. When workers are busy providing care, notes may be completed at the end of the shift, when important details can already have been forgotten.

This led us to a key insight:

NDIS providers do not simply need more notes. They need a better way to turn frontline information into records that workers can confirm and managers can act on.

We chose a problem-first approach because the hackathon’s Track 3 asks teams to begin with a real business problem rather than a preferred technology. We then used ElevenLabs as a core part of the workflow—not as an added voice button—because voice allows workers to document a shift through a natural conversation.

What Assura Does

Assura is a voice-first shift-documentation and risk-review platform for NDIS providers.

A manager creates participants, schedules shifts, and assigns support workers. After completing a shift, the worker can enter the record manually or speak with an ElevenLabs conversational agent. The agent uses the selected participant and shift context to guide the conversation, collect missing details, and update a structured shift record.

Once the record is saved, Assura runs a bounded post-shift review across five possible risk areas:

Incident or safeguarding concerns
Health or medication concerns
Behaviour or restrictive-practice concerns
Complaints
Service-delivery exceptions

Each finding must point back to words recorded during the current shift. Assura distinguishes between facts, explicit negatives, unknown information, and topics that were never discussed. It does not silently convert missing information into a positive statement.

The worker then reviews the saved record and the AI findings before explicitly confirming them. If the note is edited, the earlier assessment is invalidated and must be run again.

Managers receive a prioritised review queue rather than another unstructured list of notes. They can inspect the original note, transcript, and supporting quotations; adjust the operational priority; mark an item as under review or closed; and record the reason for their decision. The original worker account and AI result remain preserved in the audit history.

Assura supports human decisions; it does not replace them. It does not determine whether an event is legally reportable, submit reports to the NDIS Commission, or send external risk notifications.

How We Built It

The main workflow is:

Scheduled shift
      ↓
ElevenLabs voice conversation
      ↓
Structured shift note + source transcript
      ↓
Bounded post-shift risk review
      ↓
Worker review and confirmation
      ↓
Manager exception queue
      ↓
Append-only decision history

We built Assura as a TypeScript and React application using Vinext and Vite. The application runs as a Cloudflare Worker, with Cloudflare D1 and Drizzle providing the relational data layer. Better Auth manages signed sessions and separates worker and manager permissions.

ElevenLabs provides the conversational voice interface. The recorder can call authenticated client tools to:

Read the current shift form.
Retrieve limited participant context.
Update and validate the shift record.

The participant context is treated as background—not proof of what occurred during the current shift. Historical information can help the agent ask a relevant question, but every new risk finding still requires evidence from the current shift.

After recording, a separate structured-output AI process performs the silent risk review. Zod validates the returned schema, while server-side checks verify that quoted evidence actually exists in the supplied note or transcript. This does not prove the model’s interpretation is correct, so the result still requires worker and manager review.

D1 remains the source of truth. Transcript events, note revisions, assessments, confirmations, and manager actions are stored durably. Assessments are bound to a specific note revision, which prevents a worker from changing the note while retaining an outdated AI result.

We also created an experimental ElevenLabs workflow that routes one conversation between a main agent and six specialist risk agents. We deliberately kept this experiment separate from the primary confirmation flow until its behaviour can be evaluated more thoroughly.

Challenges We Faced

Preventing AI from making the note sound better than the evidence

The easiest implementation would have been to send a short worker account to a language model and ask it to produce a professional note. However, polished text can introduce unsupported assumptions.

For example, if a worker says that a participant felt dizzy and returned home, the system should not add that the participant “fully recovered,” “required no medical assistance,” or experienced “no incident” unless those details were actually supplied.

We therefore designed Assura around structured facts, unknown values, and source-linked findings rather than unrestricted rewriting.

Coordinating voice, tools, and durable writes

A real-time voice conversation introduces difficult state-management problems. Workers can interrupt the agent, tools may return late, the selected note may change, and multiple updates may arrive close together.

We needed to ensure that:

Stale responses could not update the wrong shift.
Tool calls respected the signed-in worker and provider.
Saves completed before the record entered review.
Failed saves remained visible rather than appearing successful.
No API key or database credential reached the browser.

We addressed this using authenticated client tools, ordered writes, revision checks, and server-side ownership validation.

Keeping the AI review auditable

A simple risk score was not enough. A manager needs to know why something was flagged, which version of the note was reviewed, and what happened after the flag appeared.

We therefore linked each successful assessment to an exact note revision and stored manager decisions separately from the original AI result. Closing a finding or changing its priority requires a reason, and later edits do not silently erase earlier findings.

Defining the boundary between assistance and compliance

NDIS incident management involves operational, clinical, and regulatory judgement. It would have been unsafe to claim that Assura could decide whether an event was officially reportable.

We limited the product to identifying possible signals requiring human review. A routine result means only that no risk was detected in the supplied account; it is not proof that nothing happened.

Working within the hackathon scope

The full provider workflow can include rostering, clock records, support logs, medication records, incident forms, invoicing, and claims. Attempting to automate all of these would have produced a broad but unreliable prototype.

We focused on one complete workflow:

Capture the worker’s account, preserve its source, perform a bounded review, and send actionable exceptions to a manager.

The 48-hour constraint forced us to prioritise a working end-to-end system over a larger collection of disconnected features.

What We Learned

The largest lesson was that generating text is the easy part. Building a workflow that people can safely review, correct, and audit is much harder.

We also learned that voice is most valuable when it changes the workflow. Assura does not use voice merely to transcribe a paragraph. The conversation can access the active shift, retrieve constrained context, and update the structured record while the worker speaks.

Another important lesson was that worker efficiency cannot be measured in isolation. An AI tool may reduce writing time while increasing the amount of text managers must verify. The metric that matters is the total time across capture, review, and correction:

$$

T_{\text{saved}}

N_{\text{shifts}} \left[ \left( t_{\text{capture}} + t_{\text{review}} + t_{\text{rework}}

\right)_{\text{before}}

\left( t_{\text{capture}} + t_{\text{review}} + t_{\text{rework}} \right)_{\text{after}} \right] $$

This is why Assura focuses on a manager exception queue rather than simply generating longer notes faster.

Finally, we learned that acknowledging limitations improves the product. Assura preserves uncertainty, makes failures visible, and keeps the final decision with workers and managers.

Accomplishments

During the project, we produced a working end-to-end system with:

Worker and manager roles
Participant and shift scheduling
Manual, text, and voice-based shift capture
Authenticated ElevenLabs client tools
Structured note storage and source transcripts
Revision-bound AI risk assessments
Source-quotation validation
Explicit worker confirmation
A manager review queue
Append-only decision and audit history
Synthetic unit and API testing
A live deployed application

The project is not presented as legal or clinical advice, and all demonstrations use fictional participant information.

What’s Next

Our next step is to evaluate Assura with realistic synthetic scenarios and, subject to appropriate privacy and governance arrangements, with NDIS workers and provider managers.

We would measure:

Time required to complete a shift record
Manager review time
Unsupported-fact rate
Missing-information detection
Risk recall and false-positive rate
Frequency of notes returned for correction
Time from frontline observation to manager review

We also plan to connect shift notes with roster, clock-time, and proposed billing information. This would allow Assura to identify mismatches between what was scheduled, what occurred, what was documented, and what is ready to be claimed.

Longer term, Assura could support provider-specific policies with clear source and version information, while continuing to separate government requirements, organisational procedures, and general documentation guidance.