PulseHealth is a telemedicine SaaS platform for independent practitioners in the USA. The defining constraint: all patient data must be HIPAA-compliant — encrypted at rest, in transit, with full audit logs.
The HIPAA Architecture Challenge
HIPAA doesn't specify exact technologies; it mandates outcomes:
- All PHI (Protected Health Information) must be encrypted at rest and in transit.
- Access must be role-based with granular permissions (RBAC).
- Audit logs must capture every access and modification to PHI.
- Business Associate Agreements (BAAs) must be signed with all vendors.
Technology Choices
We selected vendors that offer HIPAA BAAs:
- Supabase (with Row Level Security for RBAC)
- AWS (for file storage with KMS encryption)
- Twilio (for HIPAA-compliant SMS and video)
- Stripe (for payment processing)
Row Level Security: The RBAC Foundation
-- Only practitioners can see their own patient records
CREATE POLICY "practitioners_can_view_own_patients"
ON patients FOR SELECT
USING (
auth.uid() IN (
SELECT user_id FROM practitioner_patients
WHERE patient_id = patients.id
)
);
-- Patients can only see their own data
CREATE POLICY "patients_can_view_own_data"
ON patients FOR SELECT
USING (auth.uid() = user_id);Audit Logging
Every DB operation that touches PHI triggers a PostgreSQL function that writes to an immutable audit log:
CREATE OR REPLACE FUNCTION log_phi_access()
RETURNS trigger AS $$
BEGIN
INSERT INTO audit_logs (table_name, operation, user_id, timestamp, record_id)
VALUES (TG_TABLE_NAME, TG_OP, auth.uid(), NOW(), NEW.id);
RETURN NEW;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;The 12-Week Timeline
- Weeks 1-2: Architecture design, vendor selection, BAA signing
- Weeks 3-5: Authentication, RBAC, audit logging infrastructure
- Weeks 6-10: Core feature development (appointments, messaging, records)
- Weeks 11-12: Security audit, penetration testing, launch
Result: PulseHealth launched on schedule, passed a third-party HIPAA audit, and onboarded 150 practitioners in the first month.

