Vantrexia is engineered from the ground up to satisfy the HIPAA Security Rule, Privacy Rule, and Breach Notification Rule. Every layer of the system — from the database fields to the cache engine to the API middleware — enforces safeguards that protect electronic Protected Health Information (ePHI). The platform achieves a 91.7% security compliance score across all assessed controls.

Compliance Score: 91.7%

Vantrexia's compliance posture is evaluated against 60+ HIPAA Security Rule controls spanning administrative, physical, and technical safeguards. The current score of 91.7% reflects full implementation of all required technical controls with ongoing improvements to administrative documentation and workforce training procedures.

Technical Safeguards

The following table details every technical safeguard implemented in Vantrexia, mapped to the corresponding HIPAA Security Rule requirement:

Safeguard Implementation HIPAA Reference Details
Encryption at Rest AES-256 (django-encrypted-model-fields) §164.312(a)(2)(iv) All PHI fields in PostgreSQL are encrypted using django-encrypted-model-fields. The encryption key (FIELD_ENCRYPTION_KEY) is a 32-byte key rotated quarterly and stored in environment variables — never in source control.
Encryption in Transit TLS 1.2+ (enforced) §164.312(e)(1) Nginx enforces TLS 1.2 minimum with strong cipher suites. HSTS header is set with a 1-year max-age. HTTP requests are automatically redirected to HTTPS. Internal service communication uses encrypted Redis connections.
Access Control JWT + RBAC §164.312(a)(1) Every API request requires a valid JWT access token (15-minute expiry). Role-based permissions are enforced at the view level using DRF permission classes. Users can only access data scoped to their role and practice.
Audit Logging Immutable audit trail, 7-year retention §164.312(b) Every PHI access, modification, export, and deletion is recorded in the AuditLog model with: timestamp, user ID, IP address, action type, resource type, resource ID, and change details. Logs are append-only and retained for 7 years.
Authentication JWT + TOTP 2FA §164.312(d) Primary authentication via username/password with JWT token issuance. Optional TOTP-based two-factor authentication (RFC 6238). 5 failed login attempts trigger a 30-minute account lockout with progressive backoff delays.
Session Management 30-minute inactivity timeout §164.312(a)(2)(iii) Sessions are stored in EncryptedRedisCache and automatically expire after 30 minutes of inactivity. JWT refresh tokens have a 24-hour maximum lifetime. Explicit logout invalidates all active sessions.
Cache Security EncryptedRedisCache §164.312(a)(2)(iv) Custom cache backend encrypts all data before writing to Redis, ensuring that cached PHI (session data, query results) is not stored in plaintext in memory or on disk.
Breach Detection Automated monitoring §164.308(a)(6)(ii) Real-time monitoring of failed login attempts, unusual access patterns, and data export volumes. Automated alerts trigger when thresholds are breached. The system supports breach notification workflow generation per §164.408.

Authentication & Account Security

The authentication system implements defense-in-depth with multiple layers of protection against unauthorized access:

Login Attempt Flow:
┌──────────────┐     ┌──────────────────┐     ┌──────────────────┐
│  Credentials │────▶│  Validate User   │────▶│  Check Lockout   │
│  Submitted   │     │  + Password Hash │     │  Status          │
└──────────────┘     └──────────────────┘     └────────┬─────────┘
                                                        │
                                        ┌───────────────┴───────────────┐
                                        ▼                               ▼
                              ┌──────────────────┐           ┌──────────────────┐
                              │  Account Locked   │           │  Credentials OK  │
                              │  → 30-min lockout │           │  → Check 2FA     │
                              │  → Log attempt    │           │  → Issue JWT     │
                              │  → Alert admin    │           │  → Log success   │
                              └──────────────────┘           └──────────────────┘
  • Password Policy: Minimum 12 characters, must include uppercase, lowercase, number, and special character
  • Lockout Policy: 5 consecutive failed attempts trigger a 30-minute lockout period
  • Progressive Delay: Each failed attempt increases the response delay (1s → 2s → 4s → 8s → lockout)
  • TOTP 2FA: Optional time-based one-time password via authenticator apps (Google Authenticator, Authy)
  • JWT Tokens: Access token expires in 15 minutes; refresh token expires in 24 hours
  • Session Termination: Automatic logout after 30 minutes of inactivity

Role-Based Access Control (RBAC)

Vantrexia enforces the principle of least privilege through seven predefined roles. Each role grants access to a specific set of API endpoints and UI views. Role assignments are stored in the CustomUser model and checked on every API request via DRF permission classes.

Role Code Access Level Typical User
Admin admin Full system access — all CRUD operations, user management, settings, audit logs, compliance reports Practice administrator, IT manager
Clinical Manager clinical_manager Clinical team management — oversee clinical workflows, manage staff assignments, review clinical reports Clinical supervisor, nurse manager
Provider provider Full clinical + limited admin — all clinical access plus practice-level reports and configuration Supervising physician, practice owner
Nurse nurse Clinical operations — triage review, alert acknowledgment, patient notes, intervention documentation Registered nurse, licensed practical nurse
Medical Assistant (MA) ma Patient data entry — add vitals, update demographics, manage device assignments. No triage actions Medical assistant
Data Monitor data_monitor Data monitoring — view vitals data, monitor alert dashboards, review data quality reports. Read-only clinical access Data analyst, quality assurance
Patient patient Patient portal — view own vitals history, demographics, and alerts. No access to other patients' data Patient (self-service portal)
Principle of Least Privilege

Users should always be assigned the most restrictive role that still allows them to perform their job duties. Admin access should be limited to practice administrators and IT personnel. Regular clinicians should use the nurse or provider role, not admin.

Field-Level Encryption

All Protected Health Information (PHI) is encrypted at the field level before writing to PostgreSQL. Vantrexia uses four custom encrypted field types built on django-encrypted-model-fields (AES-256):

Field Type Base Type Used For Example Fields
EncryptedCharField CharField / TextField Names, addresses, phone numbers, SSN, notes Patient.first_name, Patient.last_name, Patient.address, Patient.phone
EncryptedJSONField JSONField Structured clinical data, observation values, device metadata Observation.value, Patient.emergency_contact, AlertThreshold.config
EncryptedDateField DateField Dates of birth, admission dates, service dates Patient.date_of_birth, BillingRecord.service_date
EncryptedEmailField EmailField Patient and user email addresses Patient.email, CustomUser.email
Encryption Key Management

The FIELD_ENCRYPTION_KEY is a 32-byte encryption key injected via environment variable. It is stored in GitHub Secrets for CI/CD and in .env for local development. The key is rotated quarterly, with a migration script that re-encrypts all existing data under the new key. The old key is retained for 90 days during the transition period to support audit log decryption.

In the database, encrypted fields are stored as base64-encoded ciphertext. A sample encrypted value looks like:

-- Raw database value for Patient.first_name:
gAAAAABl... (base64-encoded ciphertext, ~120 chars)

-- Decrypted by Django ORM transparently:
"John"

Encryption and decryption happen transparently in the Django ORM layer. Application code reads and writes plaintext values — the encrypted field classes handle all cryptographic operations automatically.

Audit Logging

Every interaction with PHI is recorded in an immutable audit log. The AuditLog model captures the following data points for each event:

Field Type Description
timestamp DateTimeField UTC timestamp of the event, auto-generated
user ForeignKey The authenticated user who performed the action
action CharField Action type: CREATE, READ, UPDATE, DELETE, EXPORT, LOGIN, LOGOUT, FAILED_LOGIN
resource_type CharField Model name: Patient, Observation, BillingRecord, etc.
resource_id CharField Primary key of the affected record
ip_address GenericIPAddressField Client IP address (forwarded through Nginx)
user_agent TextField Browser/client user agent string
details JSONField Additional context: changed fields, old/new values (encrypted), request metadata
  • Retention: 7 years (per HIPAA §164.530(j))
  • Immutability: Audit log records cannot be modified or deleted through the API. Database-level protection ensures append-only behavior.
  • Querying: Admins can search audit logs by user, action, resource type, date range, and IP address via the /api/v1/auth/audit-logs/ endpoint.
  • Maintenance: The AUDIT_LOG_MAINTENANCE.sh script handles archival and cleanup of logs older than 7 years.

Business Associate Agreement (BAA)

Vantrexia supports Business Associate Agreement (BAA) execution with covered entities. As a cloud-based platform handling ePHI on behalf of healthcare providers, Vantrexia acts as a Business Associate under HIPAA.

BAA Coverage

What's covered: Storage, processing, and transmission of ePHI; technical safeguards; breach notification; data return/destruction on termination.

Subcontractors: BAAs are in place with all subprocessors that handle ePHI, including AWS (infrastructure), and the eClinicalWorks integration pathway.

Requesting a BAA: Contact compliance@vantrexia.com to initiate a BAA. Standard BAAs are typically executed within 5 business days.

Breach Detection & Notification

Vantrexia implements automated breach detection monitoring that continuously evaluates system activity for indicators of unauthorized access:

  • Failed login monitoring: Excessive failed login attempts from a single IP or targeting a single account trigger automated alerts and temporary IP blocking
  • Unusual access patterns: Access to patient records outside of normal hours, bulk data exports, or access from new geographic locations are flagged for review
  • Data export tracking: All data exports (patient lists, billing reports, FHIR Bundles) are audit-logged with volume metrics. Exports exceeding configured thresholds trigger admin alerts
  • Session anomalies: Concurrent sessions from different IPs, session hijacking indicators, and impossible travel detection

In the event of a confirmed breach, the system supports the generation of notification reports per §164.408 (notification to individuals), §164.410 (notification to media), and §164.412 (notification to HHS Secretary).

Compliance Quick Reference

Requirement Status Implementation
Encryption at Rest ✅ Implemented AES-256 via django-encrypted-model-fields on all PHI fields
Encryption in Transit ✅ Implemented TLS 1.2+ enforced, HSTS enabled
Access Control ✅ Implemented JWT + 8-role RBAC with per-endpoint permissions
Audit Controls ✅ Implemented Immutable audit log, 7-year retention, all PHI access tracked
Integrity Controls ✅ Implemented Database constraints, input validation, FHIR R4 schema enforcement
Person/Entity Authentication ✅ Implemented JWT + optional TOTP 2FA, account lockout after 5 failures
Automatic Logoff ✅ Implemented 30-minute inactivity session timeout
Breach Notification ✅ Implemented Automated detection + notification report generation
BAA Support ✅ Available Standard BAA template, 5-day execution turnaround
Data Backup ✅ Implemented Daily automated backups to S3, encrypted at rest, 30-day retention
Related Documentation

GDPR & CCPA: See GDPR & CCPA Compliance for data subject rights, data export, erasure, and cookie consent implementation.

Architecture: See System Architecture for the full technical stack and data flow diagrams.

API Authentication: See Authentication API for JWT token endpoints and 2FA setup.