Vantrexia is a multi-tenant SaaS platform purpose-built for Remote Patient Monitoring (RPM) to EMR integration. The system ingests vitals data from connected medical devices, transforms it into FHIR R4-compliant resources, applies clinical triage rules, and synchronizes observations with eClinicalWorks — all while maintaining HIPAA compliance at every layer.

Platform Overview

The platform serves medical practices that need to monitor patients with chronic conditions (hypertension, diabetes, COPD, heart failure) at scale. A single clinician can monitor up to 100 patients simultaneously using exception-based triage, while the automated billing engine captures all billable CPT codes without manual intervention.

Key architectural goals:

• HIPAA-first design — AES-256 encryption at the field level, immutable audit logs, RBAC, auto session expiry
• Real-time data flow — Device readings arrive via webhooks and are processed within seconds
• EMR synchronization — Bidirectional sync with eClinicalWorks for patients and observations
• Automated revenue capture — Celery-powered billing engine runs every 4 hours
• Cost efficiency — Full production stack runs on a single EC2 t4g.medium (~$57/month)

Technology Stack

Layer	Technology	Version	Purpose
Frontend	React SPA	Vite + TypeScript + Tailwind CSS	Provider dashboard, admin UI, triage views, billing console
Backend	Django / Django REST Framework	Django 4.2 / DRF 3.15	REST API, business logic, FHIR R4 compliance, webhook processing
Database	PostgreSQL	15	Primary data store with field-level AES-256 encryption for all PHI
Cache / Broker	Redis	7	EncryptedRedisCache for sessions, Celery message broker, rate limiting
Task Queue	Celery + Celery Beat	5.x	Async processing: billing runs, EMR sync, data ingestion, alerting
Reverse Proxy	Nginx	Latest	TLS termination, static file serving, rate limiting, request routing
Containerization	Docker Compose	—	Multi-container orchestration for all services
CI/CD	GitHub Actions	—	Automated testing, linting, Docker build, production deploy

Backend Application Structure

The Django backend is organized into eight discrete apps, each owning a specific domain. All apps share a common PostgreSQL database but communicate through well-defined internal APIs (service functions and serializers), not direct model access across app boundaries.

App	Responsibility	Key Models / Features
authentication	User management, JWT auth, RBAC, privacy controls	CustomUser, Role, AuditLog, PrivacyRequest, ConsentRecord, TOTP 2FA
core	Patient records, observations, triage, billing	Patient, Observation, AlertThreshold, TriageQueue, BillingRecord, CPT codes
ecw_integration	eClinicalWorks EMR bidirectional sync	JWT auth to eCW, patient import/export, observation push, conflict resolution
fhir_transform	FHIR R4 resource transformation	Patient → FHIR Patient, Observation → FHIR Observation, Bundle generation
ingestion	Device data intake and normalization	Webhook receiver, payload validation, unit conversion, deduplication
mio_integration	MioConnect device platform interface	Webhook processing, device enrollment, transmission tracking
monitoring	System health and operational metrics	Health checks (DB, Redis, Celery, eCW), uptime tracking, error rates
settings	Practice-level configuration	Alert thresholds, notification preferences, billing rules, integration config

End-to-End Data Flow

The following diagram shows the complete path a vital sign reading takes from a patient's device to the clinician's dashboard and the EMR system:

┌──────────────┐     ┌──────────────────┐     ┌──────────────────────┐
│  RPM Device  │────▶│  MioConnect Cloud │────▶│  Vantrexia Webhook   │
│ (BP, SpO2,   │     │  (Device Gateway)  │     │  POST /api/v1/       │
│  Glucose,    │     │                    │     │  ingestion/webhook/  │
│  Weight)     │     └──────────────────┘     └──────────┬───────────┘
└──────────────┘                                          │
                                                          ▼
                                              ┌──────────────────────┐
                                              │  Ingestion Service   │
                                              │  • Validate payload  │
                                              │  • Normalize units   │
                                              │  • Deduplicate       │
                                              │  • Assign patient    │
                                              └──────────┬───────────┘
                                                          │
                                                          ▼
                                              ┌──────────────────────┐
                                              │  FHIR Transform      │
                                              │  • Map to FHIR R4    │
                                              │  • Create Observation│
                                              │  • Encrypt PHI       │
                                              │  • Write to DB       │
                                              └──────────┬───────────┘
                                                          │
                                    ┌─────────────────────┼─────────────────────┐
                                    ▼                     ▼                     ▼
                          ┌────────────────┐  ┌────────────────────┐  ┌────────────────┐
                          │  Triage Engine │  │  Billing Engine    │  │  eCW Sync      │
                          │  • Threshold   │  │  • CPT Code Match  │  │  • Push to EMR │
                          │    evaluation  │  │  • Auto-generate   │  │  • FHIR Bundle │
                          │  • Risk score  │  │    claims          │  │  • Conflict    │
                          │  • Push alerts │  │  • Revenue track   │  │    resolution  │
                          └────────────────┘  └────────────────────┘  └────────────────┘

Step-by-Step Flow

Infrastructure & Deployment

Vantrexia runs as a set of Docker containers orchestrated by Docker Compose on a single AWS EC2 instance. The architecture prioritizes simplicity and cost efficiency while maintaining production-grade reliability.

Component	Service / Instance	Est. Monthly Cost
Compute	EC2 t4g.medium (2 vCPU, 4 GB RAM, ARM64)	~$27
Database	RDS PostgreSQL 15 (db.t4g.micro, 20 GB gp3)	~$15
Storage	S3 (static assets, backups, encrypted exports)	~$3
Cache	Redis 7 (Docker container on EC2)	Included in compute
Email	AWS SES (transactional email)	~$2
Networking	ALB + Route 53 + ACM (TLS certificates)	~$10
Total		~$57/month

Docker Compose Services

The production docker-compose.prod.yml defines the following services:

┌─────────────────────────────────────────────────────┐
│                   EC2 t4g.medium                     │
│                                                       │
│  ┌─────────┐  ┌──────────┐  ┌──────────┐            │
│  │  Nginx  │  │  Django   │  │  Celery   │            │
│  │  :443   │─▶│  Daphne   │  │  Worker   │            │
│  │  :80    │  │  :8000    │  │           │            │
│  └─────────┘  └──────────┘  └──────────┘            │
│                                                       │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐            │
│  │  Celery  │  │  Redis 7 │  │ Postgres │ (or RDS)  │
│  │  Beat    │  │  :6379   │  │  :5432   │            │
│  │ (sched.) │  │          │  │          │            │
│  └──────────┘  └──────────┘  └──────────┘            │
└─────────────────────────────────────────────────────┘

• Nginx — TLS termination, static file serving, reverse proxy to Daphne, rate limiting (100 req/min per IP)
• Django (Daphne) — ASGI server serving the REST API on port 8000
• Celery Worker — Processes async tasks: EMR sync, data ingestion, alert notifications, billing runs
• Celery Beat — Scheduler for periodic tasks: billing engine (every 4h), device billing (2:00 AM daily), health checks (every 5 min)
• Redis 7 — Celery message broker, encrypted session cache (EncryptedRedisCache), rate limit counters
• PostgreSQL 15 — Primary data store (local container or RDS in production)

External Service Integrations

Vantrexia integrates with the following external services, each serving a specific role in the RPM workflow:

Service	Purpose	Protocol	Notes
MioConnect	Device gateway — receives vitals from RPM hardware	HTTPS Webhooks (inbound)	Supports BP, SpO2, glucose, weight devices. HMAC-signed payloads.
eClinicalWorks (eCW)	EMR — bidirectional patient and observation sync	REST API + JWT Auth	Patient import, observation push, FHIR R4 Bundles. Retry with exponential backoff.
APNs (Apple)	iOS push notifications	HTTP/2 + .p8 token auth	HIPAA-safe payloads — PHI is stripped before delivery. Uses AuthKey_GSZ5ZQQ6L2.p8.
FCM (Firebase)	Android push notifications	HTTPS + service account	Same HIPAA-safe sanitization as APNs. Configured via GoogleService-Info.plist.
AWS SES	Transactional email	SMTP / SES API	Password resets, alerts, admin notifications. No PHI in email bodies.
AWS S3	Object storage	AWS SDK	Static assets, encrypted data exports, database backups.

Security Architecture

Security is not a bolt-on — it is woven into every layer of the Vantrexia architecture. The system is designed to meet HIPAA Security Rule requirements for technical, administrative, and physical safeguards.

Layer	Mechanism	Implementation
Authentication	JWT + TOTP 2FA	15-minute access tokens, 24-hour refresh tokens, optional TOTP-based two-factor authentication
Authorization	Role-Based Access Control (RBAC)	7 roles (Admin, Clinical Manager, Provider, Nurse, MA, Data Monitor, Patient) with per-endpoint permission checks
Encryption at Rest	AES-256 (django-encrypted-model-fields)	All PHI fields use EncryptedCharField, EncryptedJSONField, EncryptedDateField, EncryptedEmailField
Encryption in Transit	TLS 1.2+ (enforced)	Nginx terminates TLS with ACM certificates. HSTS header enabled.
Audit Logging	Immutable audit trail	Every PHI access, modification, export, and deletion is recorded. 7-year retention policy.
Session Management	30-minute inactivity timeout	Encrypted Redis sessions. Automatic logout on timeout. Single-device enforcement available.
Brute Force Protection	5 attempts → 30-min lockout	Progressive delay after each failed login attempt. Admin can manually clear lockouts.
Cache Security	EncryptedRedisCache	All cached data (including sessions) is encrypted before writing to Redis.

API Request Lifecycle

Every API request passes through multiple middleware layers before reaching the view handler:

Client Request (HTTPS)
  │
  ▼
┌──────────────────────────────┐
│  Nginx (TLS Termination)     │ ─── Rate Limit: 100 req/min/IP
└──────────┬───────────────────┘
           ▼
┌──────────────────────────────┐
│  Django Middleware Stack      │
│  1. SecurityMiddleware       │ ─── HSTS, Content-Type sniffing
│  2. SessionMiddleware        │ ─── Encrypted Redis sessions
│  3. AuthenticationMiddleware │ ─── JWT token validation
│  4. AuditMiddleware          │ ─── Log request metadata
│  5. RBACMiddleware           │ ─── Role-based permission check
│  6. EncryptionMiddleware     │ ─── Decrypt/encrypt PHI fields
└──────────┬───────────────────┘
           ▼
┌──────────────────────────────┐
│  DRF View / ViewSet          │ ─── Business logic + serialization
└──────────┬───────────────────┘
           ▼
┌──────────────────────────────┐
│  PostgreSQL (Encrypted PHI)  │
└──────────────────────────────┘

Next Steps