How We Architected a HIPAA-Compliant Telemedicine Platform

• May 25, 2026
• admin
• no comments

When we started the architecture for a WebRTC-based telemedicine platform in 2018, the telemedicine market looked very different. Video consultation infrastructure was not a commodity. The regulatory environment for cross-provincial digital healthcare in Canada was still taking shape. And the assumption that a video call and a patient record system could be built by the same team, on the same platform, under the same compliance requirements, was not obvious.

What followed was five years of building, operating, and scaling a system that handled over 3,000 patient encounters per month across distributed clinical teams — compliant with both HIPAA and PIPEDA, supporting multiple white-label clinical organizations on the same infrastructure.

This post covers the specific architectural decisions that made that possible: how we structured access control so compliance was enforced at the data layer, how we designed the audit trail, how we handled WebRTC session management for clinical reliability, and what we would do differently today.

The Requirements That Shaped the Architecture

HIPAA and PIPEDA share a common principle — minimum necessary access — but differ in their specific technical requirements and enforcement approach. HIPAA’s Security Rule specifies administrative, physical, and technical safeguards with some flexibility in implementation. PIPEDA’s accountability principle places more emphasis on organizational controls and consent management. A system compliant with both requires careful mapping of where the requirements overlap and where they diverge.

For this platform, the technical requirements that shaped the architecture most significantly were: audit logging for every PHI access event, access control enforced at the data layer (not just the UI), data isolation between clinical organizations sharing the same infrastructure, and encrypted storage and transmission for all patient data. These are not negotiable requirements. They are architectural constraints that need to be built in from the start, not retrofitted after the system exists.

Access Control at the Data Layer

UI-level access control — showing or hiding elements based on the logged-in user’s role — is a usability feature, not a security control. A system where PHI is accessible to the application server regardless of who is authenticated, with the restriction enforced only by what the UI renders, is a single middleware bug away from a data breach.

The architecture we implemented enforced access control at the database query level. Every query that returned patient data included a mandatory scope filter tied to the authenticated session — the clinical organization ID, the practitioner’s assigned patient list, and the active encounter context. Queries without a valid scope could not return PHI. This is not elegant ORM code. It requires deliberate schema design and query discipline throughout the application. It is, however, auditable and enforceable in ways that UI-level control is not.

For multi-tenant deployments where multiple clinical organizations share the same database infrastructure, row-level security at the database engine level provided an additional isolation layer. A bug in the application layer’s scope filtering would hit a database-level denial before returning data from a different organization’s records.

Audit Logging as a First-Class System Concern

A compliant healthcare system needs to answer the question “who accessed this patient record, when, and what did they see?” for any PHI access event, retroactively, for a multi-year retention period.

We treated the audit log as an append-only event stream, not a database table that could be edited or deleted by the application. Every PHI read event, write event, and authentication event wrote a signed audit record to a separate log store with different access controls from the primary application database. Application-level roles had no delete permission on the audit log. Deletion required a separate administrative credential with its own audit trail.

The audit log schema captured: timestamp, user ID, session ID, patient ID, record type accessed, operation type, and the IP address of the request origin. For write operations, it captured a hash of the pre-change and post-change state. This is sufficient for most HIPAA audit requirements and allows reconstruction of what any given session accessed or modified.

WebRTC for Clinical Use: What Is Different from Consumer Video

Consumer video calling tolerates quality degradation gracefully — a dropped frame or a moment of audio desync is a minor annoyance. Clinical video has different requirements. A practitioner conducting a remote consultation needs to see wound conditions clearly, assess patient affect reliably, and hear the patient’s breathing pattern without compression artifacts. Quality degradation is not just an inconvenience; it can affect clinical judgment.

The WebRTC implementation used TURN server infrastructure deployed in the same geographic region as the clinical users rather than relying on public STUN/TURN services. This reduced latency and kept the video traffic within a network boundary that we controlled — important for HIPAA BAA coverage. Public TURN services are typically not covered under a HIPAA Business Associate Agreement.

Session reliability was handled through a reconnection protocol that preserved session state across network interruptions. If a video connection dropped mid-consultation, the system automatically reconnected and restored the encounter context without requiring the practitioner or patient to restart. In a clinical context, an encounter that terminates unexpectedly without proper documentation creates both a usability problem and a potential compliance gap.

Multi-Tenant Healthcare SaaS: Data Isolation in Practice

Running multiple clinical organizations on shared infrastructure creates a tension between operational efficiency and data isolation. Shared infrastructure is cost-effective and operationally manageable. Shared infrastructure also means that a misconfiguration or a bug in the tenancy isolation layer could expose one organization’s patient data to another organization’s staff — which is a HIPAA breach by definition.

Our approach was defense in depth across three layers: application-level scope filtering (described above), database-level row security policies, and separate encryption keys per clinical organization. Patient data was encrypted with a key unique to each organization. Even if the database-level isolation was bypassed, the data returned would be encrypted with a key the requesting session did not hold.

Key management used a dedicated secrets management service rather than application configuration. Key rotation was automated. Access to key material was logged separately from the application audit log.

HIPAA vs PIPEDA: The Differences That Matter for Architecture

The most operationally significant difference between HIPAA and PIPEDA for this architecture was the consent model. HIPAA’s treatment, payment, and operations (TPO) provisions permit certain uses of PHI without explicit patient consent. PIPEDA requires explicit, informed consent for most uses of personal health information, with specific provisions around withdrawal of consent.

This meant the data model needed to track consent status at the patient level and enforce data use restrictions based on consent state — something HIPAA-only compliance does not require. Patients who withdrew consent needed to have their data excluded from analytics, reporting, and any secondary processing, while remaining accessible for direct care delivery to existing practitioners.

The practical implementation was a consent flag on each patient record that was checked as part of the access control scope — not just at the UI level but in the query logic for every reporting and analytics operation.

What We Would Do Differently Today

The audit logging implementation, while functionally correct, was built as a synchronous write in the application request path. Under load, this added latency to every PHI access event. The right architecture is an asynchronous event stream — the application emits an audit event, and a separate consumer writes it durably. This decouples the audit write latency from the user-facing request latency while preserving the durability guarantee.

For the WebRTC infrastructure, we would evaluate the maturity of managed HIPAA-compliant video APIs more carefully today than we did in 2018. The vendor landscape has matured significantly. A managed video infrastructure with a HIPAA BAA covers a significant operational burden that we were carrying ourselves.

The access control implementation was correct but verbose — the query discipline required to maintain it was a constant source of code review comments. Today we would implement a more systematic approach using database views or materialized scopes that enforce the filtering automatically, rather than relying on developer discipline on every query.