Anamnesix Română

Legal documents

Technical and Organisational Measures

Version 24 September 2026 · Processor: Lava Labs SRL

Purpose of this document

This document describes the technical and organisational measures Lava Labs SRL applies to protect the data processed by Anamnesix. It forms Annex II of the Data Processing Agreement concluded with every doctor who creates an account. It is written from the code that ships in the app and on the server, and it is updated whenever those measures change.

The design principle behind every measure is the same: patient data is readable only on the doctor's phone. The server stores ciphertext and counters. The single exception is dictation, where audio is readable for the time needed to turn it into text.

Encryption on the phone

Database

  • All patient records live in a single SQLite database encrypted with SQLCipher.
  • The database key is a random 32-byte root key generated on the phone at first launch. It is never derived from the PIN and never transmitted.
  • The root key is kept in the operating system keychain (iOS Keychain, Android Keystore), marked as accessible only when the device is unlocked and never transferable to another device.

Files

  • Scanned pages, thumbnails and voice memos are stored as individually sealed files.
  • Each file is encrypted with AES-GCM under its own key, derived from the root key with HKDF-SHA256 and the file's identifier, so no two files share a key and a leaked file key opens one file only.
  • Images are re-rendered to JPEG before sealing, which removes camera metadata such as location and device model.

PIN and biometric unlock

  • The doctor's PIN never encrypts data directly. It derives a wrapping key with PBKDF2-SHA256 at 120000 iterations, using a random salt, and that wrapping key seals the root key with AES-GCM. The sealed envelope is what the keychain stores.
  • Biometric unlock stores a second copy of the root key in the keychain, marked as requiring biometric authentication by the operating system before it can be read.
  • Wrong PIN attempts are throttled: after five failures the app pauses for 60 seconds, and every further failure doubles the pause, up to 24 hours. Data is never wiped by wrong attempts, so a child pressing buttons cannot destroy a medical record.
  • The app locks automatically after a configurable delay and shows a privacy cover whenever it goes to the background, so the app switcher never shows patient data.

Device backups

  • Android device backup is disabled for the app, so the encrypted database never lands in a Google backup.
  • On iOS, the keychain entries are marked as not migrating to another device.

Encryption in the cloud

What the server receives

  • With Premium, the app uploads the sealed files exactly as they are stored on the phone, and a copy of the encrypted database made with the same SQLCipher key. The server receives ciphertext only.
  • Uploads go to a private storage bucket where each doctor can access only their own prefix, enforced by database row-level security policies.
  • Upload URLs are signed for a single object; download URLs are signed and expire after 5 minutes.
  • Uploads are verified by size and SHA-256 hash before being committed.

Recovery code

  • To open a backup on a new phone, the doctor needs a 24-character recovery code generated on the phone and shown once.
  • The root key is wrapped under that code with PBKDF2-SHA256 at 210000 iterations and AES-GCM, and only this wrapped envelope is stored in the cloud. The code itself is never transmitted or stored by us.
  • Without the code, neither Lava Labs SRL nor anyone who obtains the stored data can open the backup.

Transport

  • All traffic between the app and the server uses HTTPS. Sessions are held in the keychain.

Dictation

  • Audio is decrypted on the phone only when the doctor submits a memo for transcription, and is sent over HTTPS to our server functions.
  • The server functions relay the audio in memory to the transcription sub-processor's European Union endpoint and never write it to disk or to the database.
  • When the app confirms it has received the transcript, the server deletes the audio file and the transcription at the sub-processor. A reconciliation job runs every hour and deletes anything left behind, for example when the phone lost connectivity before confirming.
  • The server keeps only counters and identifiers for each transcription session, never audio or text. The identifiers that link a session to a memo and to the sub-processor's objects are scrubbed 30 days after the session is settled.
  • Memo length is capped at 15 minutes and 8 MiB per request.

Server-side controls

  • Every table holds row-level security policies. Doctors can read only their own rows through their session, and no table allows a doctor to read another doctor's data.
  • All state-changing logic lives in SQL functions that only the service role can execute. The app never writes to the ledger tables directly.
  • Server functions authenticate the doctor by the Supabase session token. Scheduled jobs authenticate with a shared secret held in the database vault and refuse secrets shorter than 32 characters.
  • Sign-ups from disposable email domains are rejected.
  • Secrets for the server (API keys, webhook secrets, mail credentials) are kept in the Supabase secret store and in the database vault. Secrets for app builds are kept as EAS secrets. None are committed to the repository.

Monitoring and logs

  • Crash reports go to an error reporting service hosted in the European Union. Before leaving the phone, every report passes through a scrubber that deletes request data, reduces the user to an anonymous identifier, redacts email addresses, dates and runs of digits, removes navigation and console breadcrumbs, and drops any field that could hold a note title, body or clinical section. Screenshots are never attached and performance tracing is off.
  • Product analytics is switched off by default and runs only when the doctor turns it on. It sends screen and feature names only, uses a European Union host, and has session replay, geolocation and surveys disabled.
  • Server function logs mask email addresses and never contain audio, transcripts or file contents.
  • The app never registers for push notifications. Reminders are scheduled locally on the phone, and their lock-screen text shows initials unless the doctor chooses otherwise.

Retention and deletion

  • Deleting a patient on the phone deletes the record and all attached files immediately, with no soft-delete, and removes the corresponding cloud copies.
  • The newest seven database backups are kept in the cloud.
  • When a Premium subscription lapses, uploads stop. Files stay readable for 90 days so the doctor can restore them, then a scheduled job deletes everything under the doctor's prefix.
  • Deleting the account removes every cloud object, the account and every row keyed to it. Audit rows are kept with the user reference removed, so they can no longer be linked to a person.

Organisational measures

  • Access to production systems is limited to the founder of Lava Labs SRL, using hardware-backed multi-factor authentication [TODO: confirm].
  • No member of staff can read patient files or backups, because the keys never leave the doctor's phone. Access to the transcription relay is possible only through the deployed functions, which do not persist audio.
  • Sub-processors are engaged under written agreements that impose equivalent data protection obligations, and the list is published with 30 days' notice of changes.
  • Changes to the app and server go through code review, automated tests, type checks and lint on every change, and production builds fail if a required security setting is missing or if a service is configured outside the European Union.
  • A record of processing activities, a data protection impact assessment and transfer impact assessments are maintained and reviewed at least once a year and whenever the processing changes.

Incident response

  • Any suspected security incident is investigated immediately by the founder.
  • If personal data is affected, the affected doctors are notified within 48 hours of Lava Labs SRL becoming aware, with the information the Data Processing Agreement requires, and with a statement of whether the affected data was ciphertext only.
  • Compromised secrets are rotated, affected sessions are revoked, and the incident and the remediation are recorded.
  • Lava Labs SRL assists the doctor with the assessment and, where required, with notification to the supervisory authority and to patients.