PHASE 04 Security & HIPAA Infrastructure

Building trust into the system.

HIPAA-conscious infrastructure is not a feature added at the end. It is the discipline running underneath every patient interaction, every provider workflow, and every data exchange on the platform.

Security Posture

Three layers of operational safeguard, designed together.

Safeguards are organized into three layers: technical controls inside the application, administrative discipline around the people who run it, and infrastructure-level protection across hosting, network, and storage. No single layer carries the full weight; they are designed to reinforce one another.

This structure gives leadership a clear view of where every safeguard sits and which operational risk it addresses, without requiring deep technical fluency to evaluate it.

Layer 01 · Technical Safeguards

Controls inside the application itself.

The first layer protects data and access at the code level. These are the controls the platform enforces every time a provider logs in, opens a record, or performs a clinical action.

01.1

Encryption at rest & in transit

All PHI, including patient records, clinical images, consult notes, and eRx data, is encrypted on disk using AES-256 and protected in transit using TLS 1.2 or higher. Encryption keys are managed by the cloud provider's KMS, not stored inside the application.

01.2

Multi-factor authentication

Every provider, admin, and staff account requires MFA. Leadership and the clinical team have explicit visibility into who holds access and whether their second factor has been enrolled and maintained.

01.3

Role-based access control

Front-desk staff see scheduling and intake. Medical assistants see clinical workflows. Providers see full records. Ownership sees operational reporting. RBAC is enforced server-side and is never dependent on the front-end to restrict visibility.

01.4

Audit logging

Every PHI access event, including view, modify, export, and share, is logged with user, timestamp, IP address, and action taken. Logs are immutable, retained per HIPAA expectations, and available in operational reports for leadership review.

01.5

Session management

Idle timeout, forced re-authentication for sensitive actions such as prescribing and image export, and device fingerprinting for telemedicine consults. An unattended workstation cannot leave a patient record exposed.

01.6

Secure file and image handling

Patient-uploaded files and clinical images travel over an encrypted channel, are stored in a HIPAA-eligible object store, and are never exposed via predictable or publicly accessible URLs. Every file carries the same protection as a clinical record.

Layer 02 · Administrative Safeguards

Discipline around the people who run the system.

Technical controls only work when the operational habits around them are sound. This layer is the documented discipline that keeps the technical layer effective over time.

02.1

BAA registry & coverage map

Every vendor that touches PHI, including hosting, communications, eRx clearinghouse, telemedicine signaling, and analytics, has an executed Business Associate Agreement, mapped in a single registry that leadership can review at any time.

02.2

Access provisioning & revocation

Documented procedures for onboarding new providers, adding staff, and revoking access when someone leaves the organization. Each procedure includes mandatory checklist items covering account deactivation, MFA token revocation, and BAA-relevant access closure.

02.3

Training & acknowledgment

Onboarding training material for staff who will use the platform, covering what constitutes PHI, how to handle a misdirected communication, and what to do if a device is lost or compromised. Documented acknowledgment is collected and refreshed annually.

02.4

Incident response runbook

A written procedure for the scenarios that require an immediate, organized response, including suspected unauthorized access, lost devices, and accidental disclosure. Defines who is notified, who makes decisions, and what the timeline looks like for breach assessment and required notification.

Layer 03 · Infrastructure Safeguards

The platform underneath the platform.

Hosting, network, and storage controls — the foundation the application operates on.

03.1

HIPAA-eligible hosting

The application and all storage are provisioned on a HIPAA-eligible cloud provider with an executed BAA covering the specific services in use. No PHI resides in any service that is not covered under a signed agreement.

03.2

Network isolation

Private subnets, restricted security groups, and a defined ingress posture. Databases are not internet-addressable. Administrative access is gated behind authenticated, logged channels with no exceptions for convenience.

03.3

Backup & recovery

Encrypted, automated backups with documented retention and recovery procedures. Recovery point and recovery time objectives are defined during discovery and tested before launch. Assumptions are never substituted for verified results.

03.4

Patch & vulnerability discipline

Operating systems, runtime environments, application dependencies, and container images are tracked and patched on a documented cadence. Critical vulnerabilities in PHI-touching components are treated as operational incidents, not routine maintenance items.

03.5

Monitoring & alerting

Authentication anomalies, unusual export patterns, infrastructure errors, and uptime degradation all generate alerts routed to the operations team. Issues are identified and addressed before they surface to the practice or its patients.

03.6

Documented architecture

Every component, every data flow, and every BAA-covered service is documented and version-controlled. If an auditor, partner, or future licensee asks how the system is built and where PHI flows, the answer exists on paper and is kept current.

How These Safeguards Work in Practice

Security controls that operate across every workflow the platform supports.

Patient photo and document uploads

A patient uploads clinical images from a mobile device. The file is encrypted client-side, transmitted over TLS, and stored in a HIPAA-eligible object store indexed against their record. No unprotected URL is ever generated, and no one outside the authorized care team can access it.

Multi-location provider workflows

A patient seen at one location has a clinical action performed by a covering provider at a second location. RBAC grants the appropriate level of access; the audit log records both providers, both locations, and the full action pathway end-to-end.

Telemedicine and video consults

A patient connects to a video consult through the patient portal. The signaling path runs through a BAA-covered service, any recorded session is encrypted and stored under the same controls as in-person documentation, and session timeout protects the encounter if either party steps away.

Secure intake from referring providers

A referring provider submits intake forms and clinical materials through a secure, BAA-covered channel. The platform routes the package to the correct provider queue, logs the source organization, and never exposes PHI through an unprotected submission path.

Phase 04 · Engagement Structure Engagement figures are defined in the SOW & MSA. This phase is scoped against the blueprint established during discovery. Final commercial structure, fee model, milestones, and acceptance criteria are detailed in the Statement of Work and Master Services Agreement.
Review SOW & MSA
Up Next

See how the platform moves from validated build to live operation.

Phase 05 covers the deployment process, operational validation, and the structured approach that transitions the platform into a stable, live production environment.