Data Protection

Overview

Data protection in Odento follows a defense-in-depth approach. Every layer — network, storage, application, and access — has its own security controls. Patient health records are treated with the highest sensitivity, with additional protections beyond standard business data.

Encryption at Rest

All data stored in Odento is encrypted at rest using AES-256-GCM (Galois/Counter Mode), which provides both confidentiality and integrity. This applies to:

• Database (PostgreSQL): Transparent data encryption (TDE) on all tablespaces. Disk-level encryption on the attached SSD.
• File storage (GCS): Google Cloud Storage server-side encryption with customer-managed encryption keys (CMEK) via Cloud KMS.
• Redis cache: AOF and RDB files encrypted on disk. In-memory data is transient and not persisted unencrypted.
• Backups: All backup snapshots and export files are encrypted with AES-256-GCM before storage.
• Logs: Application and audit logs are encrypted at rest in the logging backend.

Key Management

Encryption keys are managed through Google Cloud Key Management Service (Cloud KMS):

• Keys are stored in Cloud KMS in the asia-south1 region.
• Automatic key rotation every 90 days.
• Key access is logged in Cloud Audit Logs.
• Keys are never exported or accessible in plaintext outside KMS.
• Separate keys for different data classes (patient records, financial data, general data).

Encryption in Transit

All data in transit is encrypted using TLS 1.3, the latest transport security protocol. TLS 1.3 provides stronger security with fewer round trips and eliminates vulnerable cipher suites. Connections that do not support TLS 1.3 fall back to TLS 1.2 with forward secrecy.

• Client to Odento API: TLS 1.3 (HTTPS). HSTS enforced with preload.
• Odento API to database: TLS 1.3 over private network (localhost).
• Odento API to GCS: TLS 1.3 (Google Cloud internal network).
• Odento API to Redis: TLS 1.3 over private network.
• Odento API to external services: TLS 1.3 (Razorpay, WhatsApp, Google APIs).
• Certificate management: Managed by Cloudflare with automatic renewal.

Storage Architecture

Odento uses a tiered storage architecture based on data type and access patterns:

PostgreSQL (Primary Data Store)

All structured data — patient records, appointments, invoices, treatment plans, user accounts — is stored in PostgreSQL 18. The database runs on a Compute Engine VM with an attached SSD disk and is accessible only via localhost (no external network access).

Google Cloud Storage (File Storage)

Unstructured data — X-rays, intraoral photos, documents, video content — is stored in GCS. Files are uploaded via signed URLs, which grant time-limited access without exposing credentials to the client. Signed URLs expire after 15 minutes.

// Signed URL flow
1. Client requests upload URL from Odento API
2. Odento API generates GCS signed URL (15-min expiry)
3. Client uploads file directly to GCS via signed URL
4. Client notifies Odento API of upload completion
5. Odento API verifies file exists and records metadata
6. File is accessible via new signed URL on demand

// Storage classes
- X-rays and clinical images: Standard (frequent access)
- Video content (Wave): Standard (streaming access)
- Archived records: Nearline (30-day retrieval)
- Backups: Coldline (90-day retrieval)

Redis (Cache & Real-time)

Redis is used for session caching, rate limiting, real-time subscriptions, and ephemeral data. Redis runs on the same VM as the API with AOF (append-only file) and RDB (snapshot) persistence enabled. No sensitive patient data is stored in Redis — only session tokens and cached query results.

Access Control

Odento implements role-based access control (RBAC) with granular permissions. Access is determined by the user's role within an organization, not by their individual account. This ensures consistent access policies across the organization.

RBAC Model

• Organization owner: Full access to all data and settings within the organization.
• Administrator: Manage users, settings, and billing. No access to clinical data by default.
• Dentist: Access to assigned patients, appointments, and clinical records.
• Front desk: Appointment management, patient registration, billing. No clinical record access.
• Lab technician: Access to assigned lab orders and related patient data only.
• Student: Access to enrolled courses, shared cases, and own learning records.
• Patient: Access to own records, appointments, and invoices only.

Data Scoping

Data access is scoped at multiple levels:

• Organization: Users can only access data within their organization.
• Location: Users can be restricted to specific practice locations.
• Patient: Dentists see only patients assigned to them (configurable).
• Record-level: Sensitive records (e.g., HIV status) can be restricted to specific roles.

Audit Logs

Odento maintains comprehensive audit logs for all data access and modifications. Every action is recorded with:

• User ID and role at the time of the action
• Timestamp (UTC)
• Action type (create, read, update, delete, export)
• Resource type and ID (e.g., patient record #1234)
• IP address and user agent
• Before and after values (for updates)
• API endpoint or UI action that triggered the log

Audit Log Retention

• Active logs: Searchable for 90 days in the dashboard.
• Archived logs: Retained for 7 years (per medical records requirements).
• Export: Logs can be exported to CSV or JSON at any time.
• Tamper protection: Logs are append-only and cryptographically chained.

Data Deletion and Retention

Odento follows strict data retention and deletion policies:

• Patient records: Retained for 7 years per medical records regulations. Cannot be deleted before retention period expires.
• Financial records: Retained for 8 years per GST and tax regulations.
• Audit logs: Retained for 7 years.
• Deleted data: Soft-deleted for 30 days (recoverable), then permanently deleted and purged from backups within 90 days.
• Account closure: Data is retained per the retention policy even after account closure. Data export is available before closure.