Security by Design
Boundaries the platform enforces, not policies people have to remember.
This page explains, in more technical terms than the rest of the site, how Nerida’s access model, records and audit trail are built. It describes the design and the current web build. Production controls are stated in future tense until they are verified live.
Six design rules
- Identity comes from the verified sign-in, never from the request
- Who is acting is taken from the authenticated session token. Nothing in a request body or address can change who the server believes you are.
- Deny by default, on every request
- Each request is checked against the person’s role, their care relationship with the patient and the specific permission granted. A new route starts closed. Hiding a button is never the protection.
- Access is recorded before anything is shown
- A read of clinical information writes its audit record first. If that record cannot be written, the information is not returned. The audit trail is append-only and cannot be edited or deleted by the application.
- Operational roles have no clinical path
- Assistant access exists only through an active assignment and per-request grant checks. Assistant views are built as separate, deliberately limited data shapes, never by stripping a clinical record.
- Records keep their history
- Clinical notes are corrected by appending; nothing is silently overwritten. Deletion is archive-first, with lawful retention and erasure handled as their own reviewed process, never a casual button.
- Small groups stay hidden
- Aggregate reports over a small number of people are treated as identifiable information. Very small counts are hidden on the server before the report is sent, so the client never receives them.
One Request
What happens when someone opens a record
A doctor opens a patient’s record. The server first confirms who they are from the session, then confirms an active care relationship with that patient, then checks the specific action. Only then is the read recorded, and only after it is recorded is the record returned.
A resource the person may not see returns “not found”, not “forbidden”, so the existence of records cannot be probed. The same steps apply to every secondary path: lists, histories, overviews and change requests each re-check the boundary independently.
- Identity confirmed from the verified session
- Care relationship with this patient confirmed
- Specific permission for this action checked
- Access recorded, or nothing is returned
- Record returned, with private notes redacted for the role
In the current build
- Parameterised database access
Every query uses bound parameters; a build check fails on inline-built SQL. Free-text inputs are length-capped.
- Least-privilege database role
The application connects with a role that can read and write data but cannot change the schema.
- Rate limits on sensitive routes
Sign-in, registration and invitation routes carry stricter per-address limits.
- Security headers and strict policies
The API and the web application send restrictive content-security and framing headers. The web client loads no third-party analytics or advertising code.
- Files verified end to end
Uploaded files are content-sniffed and hashed; downloads are recorded and fail closed. A non-viewer receives “not found”.
- Refuses to start misconfigured
A production-like deployment refuses to boot with development authentication, a default secret or an unencrypted database connection.
- Tested for the failure modes that matter
Negative-authorisation and redaction assertions ship with every read path; race-condition tests follow an exactly-one-winner pattern for appointments, invitations and permission removal.
- Production encryption and backupsBefore live use
The production service will protect data in transit and at rest and prove timed backup restoration before live use. Stated in future tense until verified.
Before Live Use
Design is not proof
Everything above describes how the platform is built and what the current web build does with fictional data. Before any real patient data is handled, the deployed service undergoes an independent penetration test, clinical review and legal review, and production controls are verified live.
Security researchers acting in good faith are welcome to report findings; the disclosure policy explains how and what to expect.
Questions about the design?
Privacy-minded clinicians, security researchers and practice IT leads are welcome to ask for detail.