Skip to content

Security & Privacy

Document Purpose: This document defines the security architecture, privacy controls, and compliance requirements for the Entheory.AI platform, with specific focus on Indian healthcare regulations.

Executive Summary

Entheory.AI handles sensitive patient health information (PHI) and must comply with Indian data protection laws (DPDP Act), ABDM guidelines, and healthcare accreditation requirements (NABH). Our security architecture follows defense-in-depth principles with multiple layers of protection.

Related Documentation: - Security Use Cases – Detailed security implementations - Consent Management – Patient consent workflows - Ops Playbooks – Key rotation and DR procedures

1. Security Architecture Overview

Defense-in-Depth Model

flowchart TB
    subgraph Perimeter["Perimeter Security"]
        WAF["Web Application Firewall"]
        DDoS["DDoS Protection"]
        GW["API Gateway"]
    end

    subgraph Network["Network Security"]
        VPN["VPN/Private Link"]
        FW["Firewall Rules"]
        SEG["Network Segmentation"]
    end

    subgraph App["Application Security"]
        AUTH["Authentication (JWT)"]
        RBAC["Authorization (RBAC)"]
        VAL["Input Validation"]
    end

    subgraph Data["Data Security"]
        ENC["Encryption (AES-256)"]
        MASK["PII Masking"]
        AUDIT["Audit Logging"]
    end

    subgraph Host["Host Security"]
        PATCH["OS Patching"]
        AV["Antivirus/EDR"]
        HARDEN["Hardening"]
    end

    Perimeter --> Network --> App --> Data --> Host

    style Perimeter fill:#ff9999
    style Network fill:#ffcc99
    style App fill:#ffff99
    style Data fill:#99ff99
    style Host fill:#99ccff

2. Authentication & Authorization

2.1 Authentication

Method Use Case Implementation
SSO/LDAP Hospital staff login SAML 2.0 / OAuth 2.0 integration
JWT Tokens API authentication RS256 signed, 8-hour expiry
API Keys System-to-system HMAC-SHA256, rotated quarterly
MFA Admin access TOTP (Google Authenticator)

2.2 Role-Based Access Control (RBAC)

graph TD
    subgraph Roles["User Roles"]
        ADMIN["Admin"]
        ONCO["Oncologist"]
        NURSE["Nurse"]
        COORD["Coordinator"]
        SCRIBE["Scribe"]
        READONLY["Read-Only"]
    end

    subgraph Permissions["Permissions"]
        PAT_R["Read Patient Data"]
        PAT_W["Write Patient Data"]
        DOC_R["Read Documents"]
        DOC_W["Upload Documents"]
        ADMIN_P["Admin Functions"]
        AUDIT_R["View Audit Logs"]
    end

    ADMIN --> PAT_R & PAT_W & DOC_R & DOC_W & ADMIN_P & AUDIT_R
    ONCO --> PAT_R & PAT_W & DOC_R & DOC_W
    NURSE --> PAT_R & PAT_W & DOC_R
    COORD --> PAT_R & DOC_R & DOC_W
    SCRIBE --> PAT_R & DOC_R & DOC_W
    READONLY --> PAT_R & DOC_R

2.3 Permission Matrix

Role View Patients Edit Notes Upload Docs Admin Panel Audit Logs
Admin ✅ All ✅ ✅ ✅ ✅
Oncologist ✅ Department ✅ Own ✅ ❌ ❌
Nurse ✅ Assigned ✅ Vitals only ❌ ❌ ❌
Coordinator ✅ Department ❌ ✅ ❌ ❌
Scribe ✅ Assigned ✅ Draft only ✅ ❌ ❌
Read-Only ✅ Limited ❌ ❌ ❌ ❌

Use Cases: SEC-401a

3. Data Protection

3.1 Encryption

Layer Method Key Management
In Transit TLS 1.3 Certificate rotation every 90 days
At Rest (Files) AES-256-GCM AWS KMS / HashiCorp Vault
At Rest (Database) Transparent Data Encryption Managed by cloud provider
Backups AES-256 Hospital-provided keys (BYOK option)

3.2 Data Classification

Classification Examples Controls
PHI (Protected Health Information) Patient name, ABHA ID, diagnoses Encrypted, access-logged, consent-required
Sensitive Lab results, imaging, prescriptions Encrypted, role-based access
Internal System configs, user lists Access restricted to admins
Public Documentation, branding No restrictions

3.3 PII Masking

Field Display Logs Exports
ABHA ID XXXX-XXXX-XX34 Masked Full (with consent)
Phone XXXXXX7890 Masked Masked
Address City only Masked Masked
Diagnoses Full Full Full (with consent)

Use Cases: SEC-402

4. Compliance Framework

4.1 Indian Regulatory Compliance

Regulation Requirement Our Implementation
DPDP Act 2023 Consent-based processing, data minimization, retention limits Consent management, auto-deletion, purpose limitation
ABDM Guidelines ABHA integration, consent artifacts, PHR interoperability FHIR R4, consent tokens, health locker support
NABH Standards Medical records completeness, audit trails 100% audit logging, provenance tracking
IT Act 2000 Security practices, breach notification Incident response plan, 72-hour notification

4.2 DPDP Act Compliance Checklist

Requirement Status Implementation
Explicit Consent ✅ Consent capture before data processing
Purpose Limitation ✅ Data used only for stated clinical purposes
Data Minimization ✅ Collect only necessary fields
Retention Limits ✅ Auto-deletion after configurable period
Right to Access ✅ Patient can download their data
Right to Erasure ✅ Consent revocation triggers data deletion
Data Portability ✅ FHIR export for patient records
Breach Notification ✅ 72-hour notification process

Use Cases: SEC-001, SEC-003

sequenceDiagram
    participant P as Patient
    participant UI as Entheory.AI
    participant CS as Consent Service
    participant ABDM as ABDM Gateway

    P->>UI: Access patient portal
    UI->>CS: Check existing consent

    alt No consent
        CS->>UI: Request consent
        UI->>P: Display consent form
        P->>UI: Grant consent (digital signature)
        UI->>CS: Store consent artifact
        CS->>ABDM: Register consent (if ABDM)
    end

    CS->>UI: Consent verified
    UI->>P: Access granted

    Note over P,ABDM: Consent can be revoked anytime

    P->>UI: Revoke consent
    UI->>CS: Process revocation
    CS->>ABDM: Revoke on ABDM
    CS->>UI: Data access blocked
{
  "consentId": "CNS-2024-001234",
  "patientId": "ABHA-12345678901",
  "purpose": "oncology_care",
  "dataTypes": ["labs", "imaging", "notes"],
  "validFrom": "2024-01-01T00:00:00Z",
  "validUntil": "2025-12-31T23:59:59Z",
  "grantedTo": ["hospital_xyz", "dr_aditi"],
  "signature": "base64_digital_signature",
  "createdAt": "2024-01-01T10:00:00Z"
}

Use Cases: CNS-001, SEC-401b

6. Audit & Monitoring

6.1 Audit Log Structure

Every data access event is logged with:

{
  "eventId": "EVT-2024-001234567",
  "timestamp": "2024-12-09T10:30:00Z",
  "actor": {
    "userId": "dr_aditi_001",
    "role": "oncologist",
    "ipAddress": "10.0.1.25",
    "userAgent": "Mozilla/5.0..."
  },
  "action": "VIEW_PATIENT",
  "resource": {
    "patientId": "ABHA-12345678901",
    "resourceType": "lab_results",
    "resourceId": "LAB-2024-001"
  },
  "result": "SUCCESS",
  "metadata": {
    "consentId": "CNS-2024-001234",
    "sessionId": "SES-abc123"
  }
}

6.2 Monitored Events

Event Category Examples Alert Level
Authentication Login, logout, failed attempts Warning on 3+ failures
Data Access View patient, download report Logged (no alert)
Data Modification Create note, update record Logged (no alert)
Admin Actions Create user, change role Alert on sensitive changes
Security Events Consent revocation, key rotation Alert always
Anomalies Bulk access, off-hours access Alert + block

6.3 Anomaly Detection

Pattern Detection Response
Bulk Access >50 patients in 1 hour Alert + temporary block
Off-Hours Access Access outside 6am-10pm Alert to security team
Unusual Role Nurse accessing admin functions Block + alert
Geographic Anomaly Login from new location MFA challenge

Use Cases: SEC-002, SEC-004

7. Incident Response

7.1 Security Incident Classification

Severity Examples Response Time Notification
P0 Critical Data breach, ransomware, system compromise 15 min CEO, CISO, Legal
P1 High Unauthorized access attempt, DDoS 1 hour Security team, IT
P2 Medium Policy violation, suspicious activity 4 hours Security team
P3 Low Failed login attempts, minor policy breach 24 hours Logged only

7.2 Breach Response Plan

  1. Contain (0-1 hour): Isolate affected systems
  2. Assess (1-4 hours): Determine scope and impact
  3. Notify (4-24 hours): Inform affected parties per DPDP Act (72 hours max)
  4. Remediate (24-72 hours): Fix vulnerabilities
  5. Report (within 72 hours): Report to Data Protection Board if required
  6. Learn (1-2 weeks): Post-incident review and improvements

8. Infrastructure Security

8.1 Network Security

Control Implementation
Firewall Allow only 443 (HTTPS), 2575 (HL7 MLLP from whitelist)
Segmentation Separate VLANs for app servers, databases, processing
VPN Site-to-site VPN for hospital connections
WAF OWASP Top 10 protection, SQL injection, XSS

8.2 Host Security

Control Implementation
OS Hardening CIS benchmarks, minimal packages
Patching Critical patches within 24h, monthly maintenance window
Antivirus/EDR CrowdStrike / Microsoft Defender
Container Security Distroless base images, vulnerability scanning

8.3 Application Security

Control Implementation
SAST SonarQube in CI pipeline
DAST OWASP ZAP weekly scans
Dependency Scanning Snyk / Dependabot
Secret Scanning GitLeaks, no secrets in code

9. Key Management

9.1 Key Types

Key Type Purpose Rotation Storage
TLS Certificates HTTPS encryption 90 days AWS ACM / Let's Encrypt
JWT Signing Keys Token signatures 6 months HashiCorp Vault
Data Encryption Keys AES-256 for PHI 1 year AWS KMS / Vault
API Keys Partner integrations Quarterly Vault + rotation playbook

9.2 Key Rotation Procedure

See: API Key Rotation Playbook

10. Security Testing

10.1 Testing Schedule

Test Type Frequency Scope
Vulnerability Scan Weekly All external endpoints
Penetration Test Annually Full application + infrastructure
Red Team Exercise Annually Social engineering + technical
Compliance Audit Annually NABH, DPDP readiness

10.2 Bug Bounty

  • Scope: Public-facing APIs and web applications
  • Rewards: Based on severity (₹5,000 - ₹2,00,000)
  • Contact: security@entheory.ai

Document Owner: Security Team / CISO
Last Updated: 2024-12-09
Next Review: Quarterly (aligned with compliance audits)