Security by Design
Boundaries the platform enforces, not policies people have to remember.
The technical detail behind the Trust page: how access is decided, how every view is recorded and how records keep their history. It describes the design and the current web build, which runs on fictional data until independent review is complete.
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.
- Encrypted, hosted in the EU
Nerida Health encrypts data in transit and at rest, hosted in the EU (Frankfurt). Connections require TLS 1.2 or newer.
- Messages encrypted twice
On top of encryption at rest, message text is encrypted with a separate key for each conversation.
- No clinical path for administrators
Platform administrators cannot open clinical data. Support access needs the user’s consent, expires, and never lets staff act as the user.
- Checked on every build
Every change is scanned for vulnerable dependencies and leaked secrets, and container images are scanned before they ship.
- Tested with unexpected input
Fuzzing, property-based and mutation tests run every night.
- Malware scanningBefore real patient data
Uploaded files stay unopened until they are scanned; the scanning service is being rolled out.
- Independent penetration testBefore real patient data
Booked, and completed before any real patient data is handled.
- Backup restoration provenBefore real patient data
A timed restore from backup is exercised and recorded before any real patient data is handled.
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.