WRITING · ENGINEERING
Five business days is a harder problem than it looks
Compliance deadlines should be a property of the record, computed when the event happens — not a reminder somebody remembered to set. Here is what makes that genuinely difficult, and why it is worth the trouble.
The deadline is not the hard part
Regulated sectors run on clocks. In disability services, a reportable incident carries an obligation to notify the NDIS Commission quickly — within twenty-four hours for immediate notification, with a fuller report following within five business days. Similar shapes exist everywhere: aged care, health, education, financial services. The specific numbers differ; the structure does not.
Most systems handle this by showing the obligation somewhere and trusting a person to act. A field for the due date. Perhaps an email. The provider's real defence is a diligent manager with a good memory.
That is a design decision, and it is a poor one. The people who record incidents are managing a caseload during a difficult day. Asking them to also run a countdown in their head is asking them to be reliable at the exact moment they have least capacity to be.
What "five business days" actually requires
Write the function and the difficulty appears immediately. To know when five business days from now falls, the system needs to know:
- Which days are weekends — easy, and the only easy part.
- Which days are public holidays — and that is not one list. Australia has national holidays, state holidays, and holidays that move. Melbourne stops for a horse race that Sydney works through.
- Which state's calendar applies — the participant's, the worker's, or the provider's registered office? For a provider operating across borders these are genuinely different answers, and the system has to have an opinion.
- When the clock started — the moment the incident occurred, or the moment it was recorded, or the moment someone became aware? These can be days apart, and only one of them is the one that counts.
- What a partial day means — an incident recorded at 4:58pm on the Thursday before Easter is the case that finds every bug you have.
Rules and timeframes are the regulator's to state, not ours — the NDIS Commission is the authority on what is reportable and by when. This piece is about the engineering underneath, which is where we have something useful to say.
Store the instant, compute the deadline
The mistake we see most often is storing a computed due date as a plain field. It looks harmless. It goes wrong in three ways.
It goes stale — if the holiday calendar is corrected, or someone edits when the incident actually occurred, the stored date silently becomes wrong while continuing to look authoritative. It loses its reasoning — nobody can later reconstruct why that date was chosen, which is precisely the question an auditor asks. And it cannot be re-derived, so a bug in the original calculation is permanent in the data rather than fixed by deploying a fix.
The better shape is to store the facts and derive the obligation: the instant the triggering event occurred, the instant it was recorded, the jurisdiction, and the rule version in force at the time. The deadline is then a function of those, evaluated whenever it is displayed. Fix the function, and every record in the system is correct immediately, including historical ones.
Make it visible without making it nag
Once the deadline is derived rather than remembered, the interface question follows: how loudly should the system say it?
The answer we settled on is that the countdown belongs on the record, not in an inbox. An incident carries its own remaining time, visible wherever it appears. Escalation happens on the dashboard as the margin narrows, not as a stream of emails that people learn to filter. The aim is a system where nobody has to ask "what is due?" because the question is answered wherever they already are.
The same machinery, once built, generalises. Credential expiries for workers, document renewals, plan end dates, budget burn approaching a threshold — all of these are the same pattern: a fact with a clock attached, surfaced before it becomes a problem rather than reported after it became one.
Test the awkward cases, not the easy ones
Anyone can verify that Monday plus five business days is the following Monday. The tests worth writing are the ones nobody wants to think about: an event at 11:59pm; an event on a Saturday; five business days spanning Christmas, where consecutive public holidays stack; a provider in one state supporting a participant in another; daylight saving beginning inside the window; an incident recorded late, where the clock started before anyone knew.
These are not edge cases in the dismissive sense. In a system handling thousands of incidents, every one of them happens, and each is a compliance breach the day it is handled wrongly — regardless of how well the person was actually supported. That gap between quality of care and quality of record-keeping is exactly what good software should close.
Why this is worth doing properly
A missed notification is not a paperwork problem. It is a finding against a provider who may well have handled the underlying incident impeccably. The care was good; the clock was not watched; the record says the provider failed.
Software cannot make an incident less serious. It can make certain that the obligations attached to it are computed accurately, surfaced early, and evidenced afterwards — so the provider is judged on how they responded rather than on whether somebody remembered a date during a hard week.
This pattern is running in production in MySienna and CareOp. If your sector has its own clocks — and most regulated sectors do — the machinery transfers.