How Medyra Protects Your Medical Data: AES-256-GCM Encryption Explained
Your medical reports contain some of the most sensitive data that exists about you, diagnoses, medication history, hormone levels, genetic markers. When you upload a document to any digital service, you deserve to know exactly what happens to it. This article explains precisely how Medyra handles your data, what we encrypt, and why not even our own team can read it.
The problem with storing medical data
Most healthcare applications store patient data in a plain-text database. This means that anyone with database access, a developer, a hacker who breaches the server, or even a cloud provider employee, can read your records directly. For general data this is already bad. For medical data, it is unacceptable.
German and EU law reflects this. Article 32 of the GDPR explicitly requires “appropriate technical measures” to protect sensitive personal data, including encryption. The German Federal Data Protection Act (BDSG, §64) sets an even higher bar for health data specifically. We built Medyra to exceed both standards.
What we encrypt, and why those fields
Extracted text
The raw OCR text from your lab report, contains every diagnosis, test name, and value.
AI explanation
The full analysis: flagged values, interpretations, and the summary your doctor would see.
Chat conversations
Every question you asked and every answer, your private health dialogue with the AI.
File name
Often contains your name, date of birth, or patient ID, directly identifying personal data.
The fields we do not encrypt are non-sensitive structural fields: your Clerk user ID (already pseudonymous), timestamps, and subscription status. These are needed to query the database efficiently and contain no health information.
AES-256-GCM: the encryption standard explained
How your data is encrypted
What MongoDB actually contains
Without the encryption key, this data is mathematically unreadable, by anyone.
🔑 Encryption key
Stored only in server environment variables. Never in the database.
🗄️ MongoDB Atlas
Contains only encrypted ciphertext. Useless without the key.
We use AES-256-GCM, the same encryption standard used by German banking systems, the BSI (Bundesamt für Sicherheit in der Informationstechnik), and NATO for classified communications. Here is what each part means:
- AESAdvanced Encryption Standard, the global standard for symmetric encryption, adopted by the US NIST and EU agencies.
- 256256-bit key length. There are 2²⁵⁶ possible keys, more than the number of atoms in the observable universe. Brute-force is mathematically impossible.
- GCMGalois/Counter Mode. This is authenticated encryption, it not only encrypts the data but produces a cryptographic tag that detects any tampering. If someone modifies the ciphertext in the database, decryption fails loudly rather than returning corrupted data silently.
How each value is encrypted individually
A critical detail: we do not encrypt the entire database record with one key. We encrypt each field individually, and each encryption uses a freshly generated random value called an initialisation vector (IV).
This matters because it means that even if two users upload identical documents, the resulting ciphertext in the database is completely different, an attacker cannot detect patterns or correlations between records. Each encrypted value in MongoDB looks like:
a3f4b12c9e1d8f07:7f3a291bc8e4d0f9a2c...:8b2ef104a93d7c1e
The green section is the IV (unique per encryption), amber is the ciphertext, blue is the GCM authentication tag.
Key management: where the key lives
The encryption key is the only secret that makes decryption possible. We store it exclusively as a server-side environment variable on Vercel, never in the database, never in the source code, never logged. This means:
- ✓A MongoDB database breach exposes only ciphertext, mathematically useless without the key.
- ✓A source code leak (e.g. a public GitHub repository) exposes no patient data.
- ✓Medyra employees with database access cannot read patient records.
- ✓Even Vercel (our hosting provider) cannot access the key in transit.
GDPR Article 32 and BDSG compliance
GDPR Art. 32(1)(a)
“The controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including as appropriate: the pseudonymisation and encryption of personal data.”
AES-256-GCM satisfies this requirement explicitly. The BSI Technical Guideline TR-02102-1 lists AES-256 as the recommended symmetric encryption algorithm through at least 2030. Our implementation also satisfies the BDSG requirement for health data (as a special category under GDPR Art. 9) to apply heightened technical protections.
Additionally, all data is automatically deleted after 30 days via a MongoDB TTL index, satisfying the GDPR data minimisation and storage limitation principles (Art. 5(1)(e)).
What we do not store
- ✗The original file, we extract the text and discard the binary immediately.
- ✗Any data beyond the 30-day window, a TTL index hard-deletes all records automatically.
- ✗Payment card details, handled entirely by Stripe, never touches our servers.
- ✗Biometric data or genetic sequences, we analyse the text values in lab reports, not raw biological data.
Our commitment to transparency
We believe you should not have to trust us blindly. This is why we explain our encryption implementation in detail, the algorithm, the key management model, and the regulatory framework we comply with. If you have questions about our data handling practices, you can contact us at any time.
Medical data deserves military-grade protection. We built Medyra with that principle from day one, not as an afterthought, and not just to tick a compliance checkbox.
Ready to try Medyra?
Your first 3 reports are free. No credit card needed. Everything described in this article protects every upload from your first report onward.
Analyse my report, it's free →