A regulated medical device portal

The device is regulated by the TGA, and regulation is mostly an evidence problem. It is not enough for the software to work — you have to be able to demonstrate that it works, that you knew it worked before you shipped it, and that you would find out if it stopped.

In practice that means building compliant with IEC 62304, the standard governing the software lifecycle for medical devices: how the work is planned, how it is documented, how changes are traced, and how you demonstrate any of it years later.

It changes how you build. Documentation is not written up afterwards; it is the artefact the auditor reads, so it has to be true at every commit. Testing is not a quality nice-to-have; it is the evidence. Version history has to survive scrutiny long after everyone who wrote it has moved on.

A multi-tenant portal in Next.js, React and TypeScript, used by clinics, hospitals, laboratories and technicians to manage scanners, review scan results and administer their own users. Tenancy is one of those words that loses people — including developers — so outside the code they are simply organisations.

Behind it, an Express API and a MySQL database handling device communication, and the management and delivery of scans. It does not process them: the scans arrive as scans, and the job is to move them, keep them straight, and put them in front of the right person. Next.js only carries the front end and a heartbeat route that handles per-user encryption in the browser — the real API is its own service.

Scans come off the device as .ply and .obj — point clouds and meshes, not pictures — and a clinician needs to look at one without installing anything. That is a three.js viewer running inside the portal, next to the record it belongs to, rather than a separate application someone has to be trained on.

The heavy lifting happens on the server rather than in the tab. A browser is the wrong place to grind through a large scan, and treating it as a viewport onto work done elsewhere is what keeps it usable on the machine a clinic actually has rather than the machine you wish they had.

It is the clearest example of why the interface being custom matters. There is no component library with a medical scan viewer in it, and there is no version of this built by picking parts off a shelf.

The documentation is a deliverable in its own right, not a write-up afterwards: what was built, why it was built that way, how it was verified, and what changed since the last time anyone asked.

Today the client reads it. Before release, auditors will. That is a different standard of writing from an internal README — it has to make sense to someone who was not there, has no context, and is specifically looking for the gap between what you claimed and what you can show.

It is also the part of the job that never appears in a screenshot, and the reason the rest of it counts for anything. Software that works but cannot be shown to work does not ship in this industry.