Why the Best Care Software Lets You Configure It — Not the Other Way Around
Every care organisation is different. Software that forces you into its data model costs you in workarounds and shadow spreadsheets. Here is what configurable record types mean in practice.
The spreadsheet your coordinator will not give up
Every care organisation has one. It is usually called something like "Active Clients — DO NOT DELETE.xlsx" and it lives on a shared drive. It has columns that do not exist anywhere in the official system — a "PACE contact confirmed" flag, a "preferred carer notes" column, a field tracking whether the service agreement has been countersigned.
The coordinator who built it has been asked to move everything into the "proper" system at least twice. They have tried. The proper system does not have those fields.
This is the most common symptom of the problem with rigid care software: when the system cannot hold the data your organisation actually needs, the data migrates to wherever it can be held. Usually a spreadsheet.
Why care organisations have different data needs
There is no such thing as a standard care organisation. An NDIS provider running community access programs has different operational data than an aged care provider delivering in-home nursing. A disability support organisation managing supported independent living has different record-keeping needs than one delivering short-term accommodation.
Beyond the service type, individual organisations evolve. Regulatory requirements change. New funding streams introduce new documentation obligations. A service model that worked with 30 participants looks different at 200.
Software that enforces a fixed data model — here are the fields, here are the record types, this is how it works — requires organisations to adapt themselves to the system rather than the reverse. At small scale, this is tolerable. At larger scale, it produces a constellation of workarounds: spreadsheets, external documents, written notes in fields that were not designed for that purpose.
What configurable record types actually mean
The alternative is software where the data model can be configured by the organisation — where an admin can define what a "Client" record holds, what fields a "Referral" form captures, what information is tracked on a "Service Agreement", and what a "Care Plan" looks like in the system.
This is not about giving everyone access to database administration. It is about giving an appropriately-privileged person — typically an operations manager or coordinator — the ability to add a field, create a new record type, or adjust what information is captured on a form, without raising a support ticket or waiting for a developer.
Practically, this means:
- A new regulatory requirement can be addressed by adding a field to the relevant record type, not by waiting for the vendor to release an update or paying for custom development
- A new service type can be set up with its own record structure, capturing the information that service requires, not just whatever the system's default fields cover
- Intake forms, assessment templates, and support plan structures can reflect the organisation's actual clinical and administrative practice, not a generic approximation
- When the organisation's needs change, the system changes with it — without a project
The compliance case for configurable records
Compliance documentation in the NDIS context is specific and evidence-based. Auditors do not want to see that your organisation has a generic incident report — they want to see the right fields completed consistently, with timestamps and signatures, for every incident.
A configurable system lets you build the exact documentation structure your Quality and Safeguards obligations require, and present it consistently to every carer and coordinator who completes it. A rigid system makes you approximate that structure and then explain the gaps.
This also applies to client-specific requirements. A participant whose support plan includes medical protocols has different documentation needs than one on a standard community access plan. Configurable record types let you capture that difference in the system rather than in a separate document that nobody remembers to check.
What this looks like in Teiro
Teiro's entity builder lets admins create and configure their own record types — with custom fields, field types (text, date, address, signature, document, relationship), and access permissions — without developer involvement.
When a new record type is created, the system automatically creates the access permissions for it: who can view, create, edit, delete, and export records of that type. Admins can adjust those permissions per role. New record types appear in the right places in the platform immediately — no deployment, no support ticket.
The practical result: an organisation can model their actual operational data in the system. Referrals, assessments, care plans, service agreements, incident reports, body maps, medication schedules — if your organisation manages it, you can build a proper record type for it, with the fields your team actually uses.
The shadow spreadsheet becomes unnecessary. The data that was living outside the system because the system could not hold it now lives where it belongs.
*If your current system cannot hold the data your organisation actually needs, see how Teiro's entity builder works.*