How MedOS protects PHI: AES-256-GCM field-level encryption + DPDP Act 2023 compliance

When you tell a hospital their patient data is "encrypted", most people imagine a locked filing cabinet — encrypted at rest on the database disk, decrypted automatically when queried. That's table stakes. Every modern database vendor offers it.

But "encrypted at rest" only protects against one threat: someone physically stealing the disk.

It does nothing to protect against: - A backup file accidentally exposed on a misconfigured S3 bucket - A query log leak (e.g., a slow-query log shipped to a logging service) - An insider with read access to the raw database - A buggy export endpoint that leaks rows from the wrong tenant - A SQL injection that reads from the wrong table

For Indian healthcare under the DPDP Act 2023, that's not enough.

What MedOS does instead

Every PHI field in MedOS is encrypted at the application layer using AES-256-GCM, on top of database-at-rest encryption.

The encrypted fields: - patient.name - patient.phone - patient.aadhaar - patient.abha_id - patient.email - patient.address - patient.emergency_contact - consultation.notes (clinical narrative) - consultation.diagnosis - prescription.medicine_notes

How it works: - Encryption key loaded from `ENCRYPTION_KEY` env var (64-char hex = 256-bit) - Each field encryption uses a fresh random IV per row - Authenticated encryption (GCM mode) prevents tampering - Decryption happens server-side only — the browser never sees raw ciphertext or the key - If decryption fails (corrupted data, wrong key version), MedOS returns null instead of leaking ciphertext

The key is held only in MedOS's environment, separate from the database. Even if someone gains read access to the Turso libSQL database, they get rows like: ``` { "id": "pat_mn63jmxr8xe16w", "name": "enc:v1:eyJpdiI6Im...", "phone": "enc:v1:eyJpdiI6...", "uhid": "UHID-00009", ... } ```

The encrypted blobs are useless without the key. The non-PHI fields (id, uhid, role, etc.) remain plain — they're not personal data and they're needed for joins and lookups.

Why this matters for DPDP Act 2023

The Digital Personal Data Protection Act 2023 has a few specific requirements that drive this design:

§8(5) — Reasonable security safeguards. The Act requires "data fiduciaries" to implement "reasonable security safeguards" to prevent personal data breaches. Field-level encryption is the strongest interpretation of that requirement.

§8(6) — Breach notification. If there's a breach, you have to notify the Data Protection Board within 72 hours. With field-level encryption, a backup file exposure is not a notifiable breach — the data is encrypted with a key that wasn't in the backup. (You should still investigate, of course.)

§9 — Children's data. The Act requires "verifiable parental consent" for processing children's personal data. MedOS enforces guardian consent at registration if patient age < 18, and the children's records get the same encryption as everyone else.

§11 — Right to erasure. When a patient invokes the right to be forgotten, MedOS doesn't have to scrub backup files — the encryption keys can be rotated and old records become permanently unreadable.

Key rotation

Real-world security requires the ability to rotate keys. MedOS supports versioned key prefixes (`enc:v1:...`, `enc:v2:...`) so multiple keys can co-exist during a rotation window. New writes use the latest version; old reads decrypt with the matching version. Migration is online — no downtime.

If a key is compromised, you can: 1. Generate a new key (v2) 2. Set ENCRYPTION_KEY_V2 alongside the existing one 3. Re-encrypt existing rows in the background (online migration) 4. Once complete, retire v1

The audit log records key version on every write so you can prove which records were encrypted with which key during a forensic review.

What you can verify

If you're a clinic admin and want to verify that your data is encrypted:

1. Open Settings → Security & Compliance 2. Check the "Encryption Status" panel — it shows which fields are encrypted, the algorithm (AES-256-GCM), and the active key version 3. Click "Generate Compliance Report" to download a PDF you can hand to auditors

The compliance report includes all 9 Indian regulatory modules (DPDP, HIV Act, Mental Healthcare Act, PCPNDT, Drugs & Cosmetics, NMC Regulations, Notifiable Disease, BSA 2023, Consumer Protection Act) with the specific implementation details for each.

What this doesn't solve

Encryption isn't a silver bullet. It doesn't protect against: - A logged-in user with appropriate permissions (still need RBAC + audit trail — MedOS has both) - A phishing attack that captures user credentials (still need OTP login + session timeout — MedOS has both) - A compromised admin account doing legitimate-looking queries (still need anomaly detection — on the roadmap)

But it does eliminate an entire class of "data leaked from a backup file" or "insider with database access" scenarios. Combined with our other controls — RBAC, OTP-only login, 30-minute auto-logoff, session-IP binding, full audit trail on every PHI access, 6-year retention — it's the strongest application-layer security available in any Indian HMS today.

If you're evaluating an HMS and the vendor can't tell you whether they encrypt PHI at the application layer, that should be a red flag. "We use HTTPS and our database is encrypted at rest" is not the same answer.