Access matrix — who sees what
Two custodians, never joined. The sponsor holds the code↔identity correspondence (encrypted); the toxicologist holds the results by code. The sample code is the only shared pseudonym — but no role ever sees a name and a result together. The compartmentalisation is enforced at the database level, not merely in the user interface.
| Data item | Toxicologist | Participant | Sponsor | Operator | Laboratory |
|---|---|---|---|---|---|
| Personal identity name · e-mail (encrypted) | |||||
| Sample code unique pseudonym | |||||
| Values & note per sample individual result | |||||
| Summary & PDF aggregated, group level |
The Laboratory role is dormant: it transmitted the results to the toxicologist off-platform and has no action here. It is kept for the record.
The underlying guarantee
A name and a blood result never coexist in the same place, visible to the same role. The toxicologist works on codes and cannot read identities; the sponsor holds the identities but cannot read an individual result; the operator sees neither. This compartmentalisation is enforced by separate PostgreSQL roles (the database itself refuses any crossing), identities are encrypted at rest, and every action is recorded in a signed audit trail.
What the platform protects — stated plainly
Let us be precise about the threat model. The sample code is present on both sides (it is the key that lets each party do its job). Confidentiality therefore does not rest on the idea that a stolen database would be useless — it rests on three concrete protections:
- Compartmentalisation by role: no single application account can join identity and results — the database refuses it.
- Encryption at rest of personal data: name and e-mail are encrypted with a key held outside the database; a raw SQL dump yields nothing but ciphertext.
- Signed traceability: every read or intervention leaves a tamper-evident trace, including emergency technical access to the database.
The operator manages the life cycle (accounts, publication circuit-breaker, audit trail — metadata, never a value nor an identity) and the infrastructure. It does not handle consent withdrawals: those are for the sponsor (on sample code + e-mail) and the participant (self-service). Trust does not rest on a promise, but on a verifiable trace.