The Same Change, Two Very Different Bills
Four architectural factors that decide the price of every rule change — and what Support at Home quality indicators will test next
Two aged care software vendors receive the same revised quality indicator definition.
The first authors a new rule version, sets its effective date, runs regression against prior periods, and ships. The second opens a ticket, sends a developer to find where the logic lives, discovers it lives in four places, fixes three of them, and spends the following quarter working out which historical records are now wrong.
Same regulation. Same deadline. Completely different cost — and the difference was decided years earlier, by architecture.
This matters because these changes are not rare. Australia's mandatory quality indicator manual for residential aged care has been through four versions in six years: v1.0 (July 2019), v2.0 (July 2021), v3.0 (April 2023) and v4.0 (April 2025), each superseding the last on a set date (QI Program Manual collection). A parallel programme for in-home aged care has been consulted on and piloted, and will add another (consultation findings).
This article is for the people building that software — SaaS vendors serving Australian aged care providers, and the product and engineering leaders who absorb each round of change. It is not a guide for providers on how to comply.
Every regulatory fact below links to a public source and carries its actual status: proposed, consulted, piloted or in effect.
What You Can Build Before the Rules Are Final
The in-home indicator set does not exist yet, which is usually read as a reason to wait. It is not. The content of the rules is unknown; the shape is not.
| Your decision | Why | Applies to |
|---|---|---|
| Build now | The structure is knowable even though the definitions are not: indicator containers, eligibility and denominator modelling, effective dating, validation that evaluates as at a period | In-home QI, and every future expansion |
| Build now, and keep rebuilding | Conformance is recurring, not one-off. Developers "must transition to the current API version within 12 months to maintain their software conformance, unless otherwise approved by the agency in writing and in advance" (B2G project) | B2G integration |
| Already required | 14 quality indicators, Manual v4.0, in effect since 1 April 2025 | Residential QI reporting |
| Do not guess | The Department published that the indicators "will not start before 1 July 2026" (source) — a floor, not a commencement date. That date has now passed with no start date published | In-home QI start date |
Statuses reflect publicly available Departmental material at the time of publication. Where no date has been published, this table says so rather than estimating one. If any status has since changed, tell us and we will correct it.
That last row is not hypothetical. A vendor who read the floor as a deadline in 2024 built to a date that never came. A vendor who built the container and left the definitions empty did not.
QPS Benchmarking publicly offers a home care NQI module "built for the national pilot", capturing consumer experience, care plans and missed visits so providers can start collecting and reviewing data "ahead of schedule" (QPS Benchmarking).
A Compliance Feature Is Not a Compliance Capability
A compliance feature solves the requirement in front of you. A compliance capability determines what the next one costs.
Most aged care platforms can already produce quality indicator reports, collection workflows, audit records and dashboards. That is the feature layer, and it is table stakes. Whether the next revision is a configuration release or a redevelopment project is decided somewhere else — in how the rules are stored, versioned, validated and tested.
Which reduces to one question:
Is your platform designed to absorb regulatory change, or does every change require redevelopment?
Four Architectural Factors That Decide Every Rule Change
Four factors decide the answer.
1. Are the rules data, or are they code?
Where rules live in application code, a revision means finding and modifying logic whose reach is unknown until someone goes looking — the same rule may have been reimplemented in several places, with no list of where. Where rules are versioned configuration, the definitional part of a change is authored rather than programmed.
Not everything reduces to configuration. New submission formats, workflows, schema changes and integrations need code regardless. The goal is to stop definitional changes from requiring it, because those are the ones that recur.
What to check: if a policy analyst who cannot write code reads the new manual, how far can they get before a developer is required? In a rules-as-data system, quite far. If the answer is "nowhere", your rules are code.
What good looks like: rule definitions held as configuration with effective dates, read by the calculation engine, the validation layer and the reporting layer from one source — so a definitional change is authored once and takes effect everywhere consistently.
2. Can each part of a rule move on its own schedule?
Regulatory elements do not move together. A denominator gets redefined while the indicator concept stays put; a submission format changes on the Department's timetable, not the manual's. If your model cannot version them separately, every independent movement becomes a code change.
| If this changes on its own… | …and you cannot version it separately, then |
|---|---|
| Denominator or eligibility | Every affected indicator has to be reissued to correct one population definition |
| Calculation method | Expected value, actual value and flagging state drift apart, because each follows its own logic |
| Exclusions | Edge cases added after go-live force a release instead of a configuration change |
| Submission format | An external change reaches into your calculation layer, which it should never touch |
| Data provenance | "Where did this number come from" becomes an investigation instead of a lookup |
That last row grows in importance each year. Once a platform ingests indicator data from other care management systems rather than collecting it directly — as vendors in this market now do — provenance stops being metadata and becomes part of the audit trail.
What to check: take one indicator and list which of the above your system can version independently. Everything you cannot is a future code change you have already committed to.
What good looks like: each element modelled as versioned data with its own effective date range, so a denominator revision does not reissue the indicator, and a submission-format change never touches calculation.
3. Can a figure you already submitted still be reproduced?
This is not merely an engineering preference.
Quarterly quality indicator data is published by the Australian Institute of Health and Welfare on its GEN Aged Care Data site. The Department states that this data "must be interpreted according to the version of the National Aged Care Quality Indicator Program Manual (Part A) that was in use at the time" — which is why its manual collection retains current and previous versions, "to allow accurate interpretation of the data reports" (QI Program Manual collection).
The same principle is built into the government's own API surface. B2G versions its APIs and keeps deprecated ones available — Quality Indicators v1.2 alongside the current v2.0 — with the note that deprecated APIs "should only be used for viewing historical data and previous submission periods" (B2G project).
Two independent parts of the regulatory system do the same thing: retain superseded versions so historical results stay interpretable under the rules that produced them.
So your system has to answer, for any published number: why is this figure 17.3%?
A historical result should be reproducible from five things: the rule set version, the indicator definition, the eligibility criteria, the source data, and the reporting period.
That cannot be retrofitted. If effective dates were never modelled, the information needed to reconstruct the answer no longer exists.
What to check: take a figure from a prior submission and try to reconstruct it. If you cannot name the rule version and inputs that produced it, that is the first thing to fix.
What good looks like: calculations evaluated as at a reporting period rather than as at now — so validation answers "was this valid under the rules applying to this collection period", not "is this valid today".
4. Would you know if the last change broke something?
The regression surface here grows with rule versions, not features — one indicator expansion can affect collection, validation, calculation, reporting, export and historical data at once, without a new screen appearing.
Underneath that is a harder problem: some defect classes in this domain are invisible to users.
Standards configuration is the clearest case. Audits are built from national standards, and a service receives the questions matching its type. Attach a question to a standard that does not apply and nothing fails — no error, no warning, an audit that completes normally. The result is quietly wrong, and it flows into the dashboard, and from there into the risk report a manager uses to decide where to send resources. That class of defect can sit undetected across several reporting periods, because the people using the system have no way to see it.
The consequence: user reports cannot be your detection mechanism for anything a user cannot observe.
What to check: after your last rule change, did anyone verify that previously published figures still reproduced? If not, you do not know whether that change altered history.
What good looks like: previously published results held as regression fixtures and re-verified on every rule change; scheduled jobs asserting structural invariants — every question attached to a standard is valid for every service type it is served to — running whether or not anyone has complained; and rule-change regression on separate environments so it never queues behind feature testing near a submission window.
What This Costs, Either Way
| Rules as code | Rules as data | |
|---|---|---|
| Who makes the change? | A developer | An analyst |
| How far does it reach? | Unknown until investigated | Bounded to the rule definition |
| What happens to history? | Manual investigation of what was already written | Prior versions remain intact and evaluable |
| What must be re-tested? | Everything; blast radius unknown | The versioned rule set |
| How does it ship? | Deployment, often out of cycle | Configuration where possible, code where product behaviour changes |
The saving is not the hours on this change. It is the rework on the next one.
The cost of regulatory change is determined less by how often the rules change than by how deeply those rules are embedded in the product.
Frequency is set by the regulator and you cannot influence it. Depth of embedding is entirely yours.
Score Your Own Platform
Rate each factor (1 = Poor, 5 = Strong).
| Factor | Score (1–5) |
|---|---|
| Rules held as configuration rather than application code | |
| Each rule element versioned and effective-dated independently | |
| Historical results reproducible from rule version and inputs | |
| Regression covers rule versions and invisible defect classes | |
| Total / 20 |
- 16–20: the next expansion is a planned release, not a disruption.
- 10–15: workable, but each change carries avoidable rework — fix the weakest factor before the in-home set lands.
- Under 10: regulatory change is consuming capacity meant for product work, and it compounds each cycle.
Whichever factor scored lowest is where the next change will hurt. Fix that one first — the other three are cheaper to address once it is in place.
Frequently Asked Questions
How can an aged care SaaS platform absorb changing compliance requirements without rebuilding features each time?
By separating regulatory rules from application logic. Rule definitions should be versioned, effective-dated, and read by the validation, calculation and reporting layers from one source — so a definitional change is authored once rather than reimplemented everywhere it is used.
Why can't we just recalculate historical data when the rules change?
Because a figure already submitted must continue to reconcile with that submission. The Department publishes every superseded manual version, and keeps deprecated B2G APIs available for viewing previous submission periods, precisely so historical results stay interpretable under the rules that applied at the time.
When do quality indicators start for Support at Home?
No commencement date has been published. The Department stated the indicators "will not start before 1 July 2026" and will apply only to Support at Home providers — a floor, not a start date, and it has now passed. Consultation ran May–June 2024 and a 12-week pilot from October 2024, with outcomes to inform implementation recommendations.
Should we build for in-home quality indicators before the definitions are published?
The content of the rules cannot be built before it exists; the structure can. At least one Australian benchmarking provider has already shipped a home care NQI module built to the pilot indicator set.
When does a platform need additional engineering capability for regulatory work?
When regulatory absorption is consuming the capacity intended for product work — that is the signal, regardless of where the capacity comes from. The harder question is what to look for. Not cost per hour, but whether the people doing the work can recognise that a supplied denominator cannot be correct, or that a question has been attached to a standard that does not apply. That competence takes months to build, which is why it can be met by internal hiring, a long-term partnership, or an external team, but not by short-term contracting.
What Separates the Teams That Get This Right
None of the four factors above is theoretical. They are what regulated Australian platforms actually run into — calculation engines rebuilt without documentation, reporting results that moved between periods for reasons nobody could name, historical records quietly written wrong by a defect nobody reported.
Which points at the thing to look for when deciding who does this work. It is not team size. It is whether the engineers can tell you why a denominator does not reconcile, why a reporting result changed between periods, and whether a defect has already written incorrect history that needs correcting. That takes months to learn, which makes continuity more valuable than headcount.
Build for the Next Change, Not the Current One
The in-home indicator set will be published, and implementing it will take a few sprints. What decides your cost base is the four expansions after that one — and that is settled by architecture, not effort, before the manual arrives. The same is true wherever a regulator owns the definitions a product encodes.
Is your platform designed to absorb regulatory change, or does every change require redevelopment?
Shinetech builds and maintains regulated Australian software, works inside clients' own repositories and infrastructure, assigns IP contractually before any code is written, and holds ISO 27001 and Cyber Essentials Plus certification. We build for clients only, with no product line that could compete with yours.
If you want a second read on where your platform sits against these four factors, talk to our Sydney or Melbourne team. For teams that would rather see it applied than discussed, we run a short technical assessment on your own codebase, at no cost, with the engineers who would do the work.
Related reading: evaluating offshore development partners · offshore development costs in Australia
Sources
- Department of Health, Disability and Ageing. National Aged Care Quality Indicator Program. health.gov.au/our-work/qi-program
- Department of Health, Disability and Ageing. QI Program Manual collection. health.gov.au/resources/collections/national-aged-care-mandatory-quality-indicator-program-manual
- Department of Health, Disability and Ageing. Introducing quality indicators to Support at Home. health.gov.au/our-work/qi-program/consultation/introducing-quality-indicators-to-support-at-home
- Department of Health, Disability and Ageing. Aged care Business to Government (B2G) project. health.gov.au/our-work/b2g
- Department of Health, Disability and Ageing. Have your say: quality indicators for in-home aged care. health.gov.au/news/have-your-say-quality-indicators-for-in-home-aged-care
- Australian Institute of Health and Welfare. GEN Aged Care Data — quality indicator publications. gen-agedcaredata.gov.au
- My Aged Care. The new Aged Care Act and Support at Home. myagedcare.gov.au
- QPS Benchmarking. Product information, accessed at time of publication. qpsbenchmarking.com
About Shinetech Software: shinetechsoftware.com.au | Sydney & Melbourne | 900+ Australian clients since 2001 | 420+ partnerships lasting 2+ years | Average individual developer tenure 8+ years | ISO 27001 & Cyber Essentials Plus.