Clinicians, carers, coordinators and patients each need something different from the software. We build for the people using it:
Each of these is a page in its own right. Client details, rostered work and incident records commonly sit in separate systems, and the gaps between them are where reporting and audit trails fail.
One client record — plans, contacts, consents and history — instead of details retyped into three systems.
Intake, claiming and rostering paperwork handled by the system, so support staff spend the time with clients.
Incidents, complaints and corrective actions tracked through to close-out, so an audit shows what you did about them.
Every one of them starts with a Rapid Insight Workshop: a paid session that maps your operation and hands back a prioritised roadmap. What you do next depends on what it finds.
We stay embedded and work through the roadmap with you month after month, as rules, funding and caseloads change. One monthly fee, measured against results we agree at the start. From $15K a month, six-month minimum term.
One build, scoped in writing before anything starts, then quoted at a fixed price against that scope. A one-year warranty, and the code and the IP are yours. Typically $100K and up.
Test a participant or clinician tool before a full rollout. Fixed price, $25K to $50K, and working software in four to eight weeks — enough to test it with real users before you spend more.
A provider runs on systems that each hold part of the participant: a client management platform like Lumary or ShiftCare, a rostering tool, a practice system on the clinical side, PRODA for claiming, and Xero for the money. Staff join them by hand, which is where the unbillable hours go.
CodeFish builds across those gaps, connecting participant records, rostering, progress notes and claiming so the record is entered once and read everywhere. We work to HL7 FHIR where needed, and build the software layer rather than replacing your systems.
With a Rapid Insight Workshop. It maps how work actually moves through your organisation: the systems you run, where staff are duplicating records or chasing paperwork, what that costs in billable hours, and which fix returns the most. You get a prioritised roadmap back before committing to a build. From there you either test one idea first (Ignite), build one thing at a fixed price and own it outright (Amplify), or keep us on to work through the roadmap with you month after month (Apex). We will tell you honestly which one fits.
Yes, we have worked with NDIS providers. The operational reality is usually participant records, service agreements, rostering, progress notes and claiming all living in different places, with staff holding it together manually. We work through your specific requirements rather than assuming a generic model, because provider setups genuinely differ.
Yes, and it is factored in from design planning through to execution rather than retrofitted before launch. WCAG AA is the floor we build to, not the goal. In health and disability the people using the product often have access needs the product exists to serve, so treating accessibility as a compliance checkbox produces something nobody can use.
Yes. Integration is usually the core of the work, because the information a clinician or coordinator needs is spread across a practice management system, a rostering tool, finance, and whatever spreadsheet covers the gap. We connect them so the record is entered once and read everywhere, with permissions respected at every point.
As the primary design constraint. Health and participant data gets least-privilege access, clear consent handling, encryption at rest and in transit, and an auditable record of who viewed or changed what. Staff see what their role requires and no more, and the system is built on the assumption that this data is the most sensitive thing you hold.
That is usually where the fastest return sits. Clinicians and coordinators lose hours to duplicate data entry, notes, and reporting that could be captured once as work happens. We design workflows stress-tested against real time pressure, so the system reduces cognitive load during a shift instead of adding another screen to keep updated.
Yes, and integration is usually the core of the work. The information a coordinator or clinician needs is spread across client management, rostering, clinical and finance systems, so it gets copied between them by hand. We connect them so the record is captured once, and so the person reading it sees exactly what their role permits and no more.
Yes. Claiming and clinical data exchange carry their own rules on consent, identity and retention, so we treat them as architectural requirements rather than a late integration. Where the clinical side needs it we build to HL7 FHIR, and where claiming is the pain we automate the assembly so the evidence is already there when the claim goes in.
The NDIS Pricing Arrangements and Price Limits change every 1 July, and your software should pick them up as a data update rather than a rebuild. We store support item numbers, price limits and their start dates as data your team can review, so a support delivered on 30 June claims at the old rate and one on 1 July at the new rate. Before each change we load the new catalogue against your service agreements and flag any that sit above a new limit or use a retired item. Your coordinators fix those before claiming, rather than finding them in a batch of rejected claims in PRODA or the my NDIS provider portal.
Yes, and a phone is where most progress notes should be written, in the car between one participant and the next. We build the note screen around the shift: it opens on the current visit, fills in the participant, time and support item from the roster, and asks only for what the worker saw and did. Notes save on the device when coverage drops in a carpark or a regional town, and sync when it returns. Once submitted, the note is attached to the shift, so the claim and the evidence behind it line up without a coordinator chasing anyone on a Friday afternoon.
The software can produce most of the evidence an auditor asks for, as long as it records it while the work happens. Under the NDIS Practice Standards, auditors look for proof that your staff do what your policies say: current worker screening checks, signed service agreements, reportable incidents notified to the NDIS Quality and Safeguards Commission on time, complaints closed out, and progress notes that match the supports claimed. We build those records into the daily workflow and keep a dated history of every change. When your certification or verification audit comes around, you run a report instead of spending weeks assembling folders.
The Privacy Act 1988 treats health and disability information as sensitive information, and we design the software around that from the first screen. In practice that means collecting only what a support needs, recording consent against each participant, hosting in Australia where you require it, and logging every view and change. If something does go wrong, the Notifiable Data Breaches scheme gives you 30 days to assess a suspected breach and requires you to notify the OAIC and the people affected when it is likely to cause serious harm. A clear access log is what lets you answer who saw what within hours, rather than guess.
