Frequently Asked Questions

Vantrexia is a HIPAA-compliant Remote Patient Monitoring (RPM) SaaS platform designed for healthcare practices. It enables providers to continuously monitor patients' vital signs remotely using cellular-connected medical devices, automate clinical triage workflows, and streamline RPM billing with CPT code tracking.

The platform includes:

• Real-time vital sign dashboards with configurable alert thresholds
• Automated triage system with clinical escalation rules
• RPM billing engine with CPT 99453, 99454, 99457, and 99458 support
• EMR integration via FHIR R4 (eClinicalWorks, with Epic and Cerner planned)
• Device management through MioConnect gateway
• Full audit logging for HIPAA compliance

Vantrexia currently integrates with eClinicalWorks (eCW) via the FHIR R4 standard. This integration enables:

• Bi-directional patient demographic sync
• Practitioner and provider roster sync
• Observation/vital sign push back to eCW charts
• Appointment and scheduling data

Integrations with Epic and Cerner (Oracle Health) are on the product roadmap and planned for future releases. The FHIR-based architecture makes adding new EMR integrations straightforward.

Yes. Vantrexia is designed from the ground up for HIPAA compliance. Key security measures include:

Vantrexia supports the following medical device categories through the MioConnect gateway:

• Blood Pressure Monitors — A&D UA-651BLE (Gen1), A&D UA-767PBT-Ci (Gen2)
• Weight Scales — A&D UC-352BLE (Gen1), A&D UC-355PBT-Ci (Gen2)
• Glucose Meters — OneTouch Verio Flex
• Pulse Oximeters — Nonin 3230

All devices connect via Bluetooth to a cellular hub, eliminating the need for smartphone pairing or Wi-Fi. Data is transmitted automatically over LTE/4G.

Vantrexia targets 99.9% availability (approximately 8.76 hours of allowed downtime per year). This covers all production services including:

• API endpoints and backend services
• Frontend web application
• Webhook processing (MioConnect, eCW)
• Background task processing (Celery)

Scheduled maintenance windows are communicated 48 hours in advance and excluded from SLA calculations. The platform includes automated failover, health monitoring, and alerting to minimize unplanned downtime.

Vantrexia supports the four primary RPM CPT codes as defined by CMS:

Rates vary by payer. Configure payer-specific rates in Admin > Billing > Payer Configuration.

Vantrexia automatically tracks clinical monitoring time for each patient. The system counts time spent on qualifying clinical interactions:

• Reviewing vital signs — Time spent viewing a patient's observation dashboard
• Triage actions — Time spent evaluating and responding to triage alerts
• Patient communications — Documented phone calls, secure messages, and care coordination notes
• Care plan modifications — Updating thresholds, medication notes, or care instructions

A minimum of 20 minutes per patient per calendar month qualifies for CPT 99457. Each additional 20-minute increment qualifies for CPT 99458 (up to 2 additional units per month).

Yes. Vantrexia can generate CMS-1500 claims via the Billing Reports API. Claims include all required fields for RPM submissions:

• Patient demographics and insurance information
• Rendering and billing provider details (NPI, Tax ID)
• CPT codes with appropriate modifiers
• ICD-10 diagnosis codes linked to the monitored conditions
• Place of service code (typically 11 for office-based RPM)
• Date of service ranges for the billing period

GET /api/v1/billing/reports/claims/?month=2026-02&format=cms1500
Authorization: Bearer <token>

# Returns: PDF or JSON with payer-specific formatting

Vantrexia's smart billing engine automatically selects the highest-value billing source for each patient per billing period. This is important when patients may qualify under multiple programs or payers.

The engine evaluates:

• Primary insurance vs. secondary insurance reimbursement rates
• Medicare vs. commercial payer fee schedules
• Multiple monitoring programs — if a patient is enrolled in both RPM and Chronic Care Management (CCM), the engine selects the higher-value code per service

The billing engine runs automatically at the end of each month (via Celery beat) and generates optimized billing entries. Manual review and approval is required before claims submission.

Yes. Vantrexia can be self-hosted using Docker Compose on any Linux server. Minimum requirements:

• RAM: 4 GB minimum (8 GB recommended)
• CPU: 2 cores minimum (4 cores recommended)
• Storage: 20 GB SSD minimum
• OS: Ubuntu 22.04 LTS, Debian 12, or any Docker-compatible Linux distribution
• Docker: Docker Engine 24+ and Docker Compose v2+

git clone https://github.com/highlandpc/Vantrexia.git
cd vantrexia
cp .env.example .env  # Configure your environment variables
docker-compose -f docker-compose.prod.yml up -d

See the Deployment Guide for detailed production deployment instructions.

Use the Django management command to reset an admin password:

# Reset password interactively
docker-compose exec backend python manage.py changepassword admin

# You'll be prompted to enter and confirm the new password
Changing password for user 'admin'
Password:
Password (again):
Password changed successfully for user 'admin'

Vantrexia requires Python 3.11 for best performance and compatibility.

The Docker images ship with Python 3.11 pre-installed, so no Python version management is needed for containerized deployments. If developing locally outside Docker, ensure your system Python matches:

python3 --version
# Python 3.11.x ✓

Database migrations are run via the Django migrate management command inside the backend container:

# Run all pending migrations
docker-compose exec backend python manage.py migrate

# Check migration status
docker-compose exec backend python manage.py showmigrations

# Create new migration after model changes
docker-compose exec backend python manage.py makemigrations

# Migrate a specific app
docker-compose exec backend python manage.py migrate patients

Vantrexia employs a multi-layer encryption strategy to protect patient data:

• Encryption at Rest (AES-256) — All PHI and PII fields are encrypted at the database level using django-encrypted-model-fields (AES-256). This includes names, SSNs, dates of birth, addresses, phone numbers, and medical record numbers.
• Encryption in Transit (TLS 1.2+) — All API communications use TLS 1.2+ encryption. HTTP connections are automatically redirected to HTTPS. HSTS headers are enforced with a max-age of 31536000 seconds.
• Field-Level Encryption — Sensitive fields are encrypted using the FIELD_ENCRYPTION_KEY environment variable. Each encrypted field type (EncryptedCharField, EncryptedDateField, etc.) handles encryption/decryption transparently in the Django ORM.

from encrypted_model_fields.fields import EncryptedCharField, EncryptedDateField

class Patient(models.Model):
    # Encrypted fields — stored as ciphertext in PostgreSQL
    first_name = EncryptedCharField(max_length=100)
    last_name = EncryptedCharField(max_length=100)
    ssn = EncryptedCharField(max_length=11)
    date_of_birth = EncryptedDateField()

    # Non-sensitive fields — stored in plaintext
    mrn = models.CharField(max_length=20, unique=True)
    is_active = models.BooleanField(default=True)

Vantrexia supports the following authentication methods:

• JWT Tokens (Primary) — JSON Web Tokens with short-lived access tokens (15 minutes) and longer-lived refresh tokens (1 day). Token rotation is enforced — each refresh token can only be used once.
• Two-Factor Authentication (Optional) — TOTP-based 2FA using authenticator apps like Google Authenticator, Authy, or 1Password. Enabled per-user in account settings.

# 1. Login
POST /api/v1/auth/login/
{"email": "user@practice.com", "password": "..."}
→ {"access": "eyJ...", "refresh": "eyJ..."}

# 2. Access protected resource
GET /api/v1/patients/
Authorization: Bearer eyJ...

# 3. Refresh expired access token
POST /api/v1/auth/token/refresh/
{"refresh": "eyJ..."}
→ {"access": "eyJ...", "refresh": "eyJ..."}

Audit logs are retained for 7 years in accordance with HIPAA requirements (45 CFR § 164.530(j)). This applies to:

• Access logs — Who accessed what patient data, when, and from which IP address
• Modification logs — All changes to patient records, including before/after values
• Authentication logs — Login attempts (successful and failed), password changes, 2FA events
• System logs — Configuration changes, user role modifications, API key generation

Audit logs are stored in a separate, append-only database table with write protection. They cannot be modified or deleted through the application layer.

Yes. Audit logs can be exported in CSV or JSON format via the audit export API endpoint:

# Export as CSV
GET /api/v1/audit/export/?format=csv&start_date=2026-01-01&end_date=2026-02-01
Authorization: Bearer <admin_token>

# Export as JSON
GET /api/v1/audit/export/?format=json&start_date=2026-01-01&end_date=2026-02-01
Authorization: Bearer <admin_token>

# Filter by action type
GET /api/v1/audit/export/?format=csv&action=patient_data_access&user=nurse@practice.com
Authorization: Bearer <admin_token>