How the product is built
Photographs & data
Track’s engineers photograph ceiling-mounted units on wards where children are patients. A photograph meant to show a chilled beam can accidentally capture a patient, a visitor, a staff whiteboard with names on it, or a notes trolley. That is special-category personal data, held by a contractor, on a personal phone.
This page describes the intended controls and identifies operational work that must be verified before hospital use. A contractor evaluating Track should check each control against its own deployment.
Photographs
Capture happens inside the app
Photographs are taken through Track’s own camera view. The web capture flow uses an in-page camera without a gallery picker; native capture uses the app camera. Hospital photo uploads remain disabled until the deployment is commissioned.
A warning sits on the capture screen
Frame the unit only — no people, no screens, no whiteboards, no paperwork. This is built into the camera view rather than left to training.
Nothing is written to the camera roll
Capture does not save to a personal gallery. Browser queues stay on this device and are bound to the signed-in account and contractor. Native backup exclusion still needs built-device verification before hospital use; local storage alone is not proof that backups are excluded.
Location metadata is removed
The web camera creates a fresh, resized JPEG rather than uploading the source file. Upload validation rejects embedded metadata. Native capture also re-encodes photographs. These controls must be checked on the actual rollout devices before use.
Storage is private, access is signed and short-lived
The storage bucket is private. There are no public image URLs at any point; photographs are served through signed URLs that expire.
Deletion and retention need operational sign-off
Database deletion queues a request to remove the stored image. The deletion worker must be deployed and verified before hospital photography begins; removing a database row alone does not prove the image bytes have been destroyed.
Retention is agreed, not indefinite
The contractor and hospital must agree a retention period and verify scheduled deletion before rollout. A suggested period is not an active retention policy. Do not upload hospital photographs until these arrangements are in place.
The photo policy is signed off before rollout
The hospital’s facilities team signs off how photographs are captured, stored and destroyed, in writing, before any engineer uses the app on a ward.
Access, tenancy and audit
One contractor cannot see another’s work
Every table carries an organisation identifier and row-level security from the migration that creates it. Access is denied by default and scoped by membership, so separation between tenants is enforced by the database rather than by application code.
Roles are enforced below the interface
An engineer can create completions and photographs but cannot delete them or edit the room register. That restriction lives in the database policies, not only in what the app chooses to show.
Completions and deletions are logged, append-only
When an invoice is queried months later the question is “who marked this room done, and when”. The audit log answers it and cannot be edited or removed after the fact.
Keys and sessions
The app ships with the public client key only. The key that bypasses row-level security is server-side and never bundled into the app. Session tokens are held in the device keychain or keystore rather than general app storage.
Minimal personal data from work orders
Scheduled rooms arrive by email, and the addresses on those emails are personal data. Track stores the minimum it needs and does not sync them down to engineers’ phones.
This website
This website includes access requests and a signed-in work dashboard. Access requests collect your name, email address and any optional phone number or note you provide, so your contractor can decide whether to grant access. Do not include patient information in these fields. Supabase stores the request and provides authentication; Resend delivers sign-in emails once configured. The host processes ordinary request logs.
Essential session cookies keep you signed in. The theme preference and queued work may be stored on your device. No advertising analytics are installed. Ask your contractor’s administrator about correcting or deleting an access request, the agreed retention period, and the organisation responsible for your data.
The photo controls above are commitments about how the app is engineered. They are not a substitute for the data-processing agreement between a contractor and the hospital it works for; that agreement, and the facilities team’s written sign-off on the photo policy, sit alongside them.