Building health products
Consumer health in Australia is governed by the Privacy Act, not HIPAA, and the retention rules argue with the delete button. Plus the performance traps specific to clinical payloads.
- Domain
- Health
- Notes
- 6 items
- Source
- Shipped work
- Reply
- Within a day
What I already knew before the kickoff call.
Shipped and maintained a live health platform reconciling four data sources into one clinical scoring system.
The Australian Privacy Act is the instrument, not HIPAA
For an Australian consumer health product the Australian Privacy Principles apply: destruction and de-identification, access and correction, cross-border disclosure, and the Notifiable Data Breaches scheme. Health information is a sensitive category with its own consent bar. Writing to a HIPAA checklist means solving the wrong problem carefully.
Retention fights the delete button, and retention wins
State health records legislation sets multi-year retention on clinical records while a user can ask for their account to be destroyed. The workable shape is a soft delete with a short grace window, hard deletion of the non-clinical record, de-identification of what has to be kept, and a disposal log that records what was destroyed and when. A delete endpoint with no disposal register only looks compliant.
Slow usually means payload, not query
A four-second page turned out to have a query that ran in 0ms with the right index already in use. The whole delay was moving a 212 KB biomarker array over the wire and decoding it. Projecting the sub-fields the endpoint actually needed took it to 0.47s. Run the explain plan before touching indexes, because it tells you which of the two problems you have.
Where this happened: Health Optimisation PlatformReads and writes need separate rate-limit buckets
Passive dashboard polling shared one bucket with genuine file uploads, so ordinary navigation could exhaust the budget before a user ever attempted a scan upload. The symptom presents as "upload is broken", which sends you to the upload code, which is fine. Split the buckets by intent, not by URL prefix.
Every lab and scan report has a different layout
Parsing has to survive varying report structures, so no hardcoded line offsets: pattern-driven extraction, a report carrying anywhere from one to ten or more scan dates, and percentile scoring read from the report's own reference gauges rather than from constants baked into your code.
Where this happened: Health Optimisation PlatformA score nobody can trace is a score nobody trusts
Every recommendation has to point back to the marker that triggered it, and every domain score has to decompose into the inputs that produced it. This is a data-model decision made at the start, not a reporting feature added at the end.
Where this happened: Health Optimisation Platform
The same notes, other ground.
Working in one of these?
Tell me what is happening in your own words. I will tell you within a day whether it is mine to solve, and roughly what it takes.