HIPAA Compliance
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.
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) |
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 |
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.shscript 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.
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 |
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.