Case study /02
Northlight Clinic — the whole record, read together
A patient portal that collects symptoms, clinical notes, prescriptions and test results into one record — then lets an assistant reason across all of it instead of one document at a time.
The challenge /01
A patient’s history arrives in fragments.
A photograph of a prescription. A letter from a consultant. A results printout from a lab. Each document makes sense on its own, and almost none of them are looked at together — least of all by the patient, who is the one person present at every appointment.
The gap is not storage. It is that nobody holds the assembled picture at the moment it would be useful.
Our approach /02
Structure the intake, then read across it.
The record is divided into four deliberate categories — symptoms, doctor’s note, prescription and test results. Each accepts typed notes alongside file attachments, so a patient can describe what they are experiencing in their own words next to the paperwork that describes it clinically.
The assistant then receives the entire assembled record as context, not a single uploaded file. Asking about a symptom means the answer is informed by the prescription and the results sitting alongside it.
The product /03
What we built /04
A record that assembles itself, and an assistant that reads it.
- Email and password authentication against the Supabase auth API, with sign-up and sign-in in one card
- Four structured intake cards — symptoms, doctor’s note, prescription, test results
- Mixed input per card: free-text notes plus file attachments
- Text-based attachments read inline so their contents reach the model, not just the filename
- Assistant that receives the complete record as system context before any question is asked
- Persistent session so a returning patient lands back on their own record
- Standing clinical disclaimer — general information, explicitly not a diagnosis
- ICO registration and a stated twelve-month retention period surfaced in the footer
Production hardening /05
What has to change before real patient data.
This build calls the auth and model APIs directly from the browser, which means its keys are readable by anyone who loads the page. That is acceptable for a demonstrator and unacceptable for patient records, so we say so rather than leaving it implied.
Going live means moving both calls behind a server that holds the keys, enabling row-level security so a patient can only ever read their own record, and agreeing where model inference is allowed to run under UK data protection rules. We would rather scope that properly at audit stage than discover it after a build.
Key capabilities /06
Tech stack /07
- HTML / CSS / JavaScript
- Supabase auth
- REST API
- File upload handling
- OpenRouter
- Session persistence