CareOp

The problem

A disability provider's day is already accounted for in a dozen places. The roster lives in one tool. The shift note gets written in another. Hours are re-typed into a timesheet, then into payroll, then into a claim. Incidents go in a form that someone has to remember to file within twenty-four hours.

Every one of those hand-offs is a chance for two systems to disagree, and in this sector disagreement is expensive in a specific way. A claim that does not match the roster is unpaid work. A note that cannot be produced at audit is a finding. A missed incident deadline is a compliance breach, regardless of how well the person was actually supported.

The industry answer has usually been more tools. We thought the problem was the seams between them.

What we built

CareOp treats a shift as a single object that travels its whole life inside one system. It is rostered, delivered, noted, costed, claimed and reconciled — and it is only ever entered once.

Around that sit the parts a provider actually runs on: participant records, rostering and timesheets, shift notes, incident management, claiming, payroll, and the evidence needed at audit. One subscription rather than five, and more importantly one set of numbers rather than five that have to be made to agree.

The parts that were genuinely hard

Making one record serve every reader

A support worker on a phone at the end of a shift, a finance manager reconciling a month, and an auditor asking what happened on a Tuesday in March are three completely different jobs looking at the same underlying event. The temptation is to build three systems and sync them. Sync is where the numbers drift.

The alternative is harder up front: one record, many views, with the roles and permissions doing the work of separating what each person should see. Get that right and re-keying disappears as a category of problem rather than being reduced.

Claiming that survives contact with the real thing

Generating a claim file is easy. Generating one that validates, every time, against a government system that has its own rules and its own opinions is not. The price catalogue changes on the first of July. Line items have to be exactly right or the file is rejected as a whole. And when remittance comes back, someone has to work out which payment corresponds to which delivered service.

We built that as a loop rather than an export: services become claim lines, claim lines become a validated bulk file, remittance is matched back line by line against what was actually delivered. The measure of success is that the books close without a spreadsheet in the middle.

Deadlines the system watches, not the person

The NDIS Commission's reportable-incident timeframes are not advisory. Twenty-four hours means twenty-four hours. Relying on a person to notice is a design decision, and a poor one — people are managing a caseload, not a countdown.

So the deadline is computed from the moment the incident is recorded, and the countdown is a property of the record rather than a reminder someone set. The same applies to credential expiries, document renewals and budget burn: the system raises them before they become the provider's problem.

Audit readiness as a state, not a scramble

Most providers experience an audit as weeks of assembling evidence that already exists but is scattered. If records are written append-only, with who changed what and when preserved rather than overwritten, then the evidence pack is a query instead of a project — and an auditor can be given read-only access to look for themselves.

This is the clearest example of security work paying for itself commercially. Tamper-evident history is a compliance requirement; it is also the feature that turns an audit from a fortnight into an afternoon.

Award interpretation

Pay in this sector runs on the SCHADS award, which is genuinely intricate — different rates by time of day, day of week, shift type and circumstance. Interpreting it correctly is not a nice-to-have; it is the difference between paying people properly and underpaying them by accident.

Built for the people using it

The majority of entries into a system like this are made by support workers, often on a phone, often at the end of a long shift. That reality sets the bar: if logging a note is tedious, it will be done later, badly, or not at all — and the compliance record degrades accordingly. Accessibility is not decoration here either, in a product built for the disability sector. CareOp is built to WCAG accessibility standards and hosted in Australia.

What it demonstrates

CareOp is the argument the rest of our work rests on. Multi-tenant architecture, integration with a government claiming system, computed compliance deadlines, append-only audit history, award interpretation and a mobile workforce — that is the same set of problems most serious operational software has, arranged differently.

We did not learn it on someone else's budget. We learned it running our own product, which is why we are willing to be held to it on yours.

Read the companion case study: MySienna, built for support coordinators rather than providers — a different job, a different shape of system.

← All case studies