Compliance & Privacy
PIPEDA, PHIPA, SOC 2 requirements and implementation status for Canadian healthcare voice AI
Version: 4.0.1
Last Updated: 2026-02-16
1. Overview
Regulatory Landscape
VitaraVox operates in the Canadian healthcare sector, governed by overlapping federal and provincial privacy legislation. As a voice AI scheduling platform that processes personal health information (PHI) on behalf of medical clinics, compliance is a core product requirement.
Federal:
| Legislation |
Scope |
Key Requirements |
| PIPEDA |
Commercial organizations |
Consent, purpose limitation, safeguards |
Provincial (Healthcare-Specific):
| Province |
Legislation |
Key Differences |
| Ontario |
PHIPA |
Health Information Custodian model |
| British Columbia |
PIPA + E-Health Act |
Consent emphasis |
| Alberta |
HIA |
Custodian model similar to Ontario |
| Quebec |
Bill 64 / Law 25 |
Stricter consent, data localization |
Industry Standards:
| Standard |
Purpose |
Status |
| SOC 2 Type II |
Trust services |
Gap analysis complete |
| ISO 27001 |
Information security |
Optional |
| HIPAA |
US healthcare |
Not applicable (Canada) |
VitaraVox Role Classification
Under PIPEDA/PHIPA, VitaraVox acts as a data processor (agent), not a controller (custodian):
| Role |
Entity |
Responsibilities |
| Controller/Custodian |
Medical Clinic |
Consent, purpose, patient rights |
| Processor/Agent |
VitaraVox |
Security, confidentiality, limited use |
| Sub-processor |
Vapi.ai |
Call handling, same obligations |
Implications:
- Clinic remains accountable for patient data
- VitaraVox must process only as instructed
- Business Associate Agreement required between parties
- Sub-processor disclosures required (Vapi, cloud providers)
Data Processing Activities
What We Process:
| Activity |
Data Types |
Legal Basis |
| Patient lookup |
Name, DOB, phone |
Implied consent (scheduling) |
| Appointment booking |
Patient ID, provider, time |
Implied consent (healthcare) |
| Registration |
Demographics, PHN |
Explicit consent |
| Waitlist |
Name, phone |
Explicit consent |
| Call analytics |
Metadata only (no PHI) |
Legitimate interest |
What We Store:
| Location |
Data |
Retention |
| Vitara DB |
Clinic config |
Permanent |
| Vitara DB |
Call metadata |
1 year (configurable) |
| Vitara DB |
Transcripts |
90 days (configurable) |
| Vitara DB |
Waitlist |
Until registered |
| Vitara DB |
Audit logs |
7 years |
| Vapi |
Call recordings |
30 days (configurable) |
| OSCAR |
All PHI |
Clinic responsibility |
What We Do NOT Store:
- Patient names (in logs -- redacted by
redactPhi())
- Medical records
- Clinical notes, lab results, prescriptions
Cross-Border Data
| Component |
Location |
Cross-Border? |
| Vitara DB |
Canada (OCI Toronto) |
No |
| OSCAR EMR |
Clinic-controlled |
Clinic decision |
| Vapi AI |
United States |
Yes -- disclosed, BAA required |
| Cloudflare |
Global edge |
Yes (encrypted transit only) |
2. PIPEDA Requirements
PIPEDA's 10 Fair Information Principles and VitaraVox's implementation status.
Principle 1: Accountability
Designate an individual accountable for compliance.
| Implementation |
Status |
Privacy officer fields per clinic (privacyOfficerName, privacyOfficerEmail, privacyOfficerPhone) |
Done |
| Pre-launch validation enforces privacy officer designation |
Done |
| Privacy policy published on website |
Needs update |
| Staff training program |
Planned |
Principle 2: Identifying Purposes
Identify purposes for collection at or before collection.
| Implementation |
Status |
| Voice agent states purpose at call start |
Done |
| Purpose limited to scheduling |
Done |
| Privacy notice available |
Needs update |
Principle 3: Consent
Knowledge and consent required for collection, use, disclosure.
| Implementation |
Status |
| Implied consent for scheduling (healthcare operations exception) |
Done |
| Explicit verbal consent for registration ("Do you consent to proceed?") |
Done |
| Withdrawal mechanism (transfer to staff / hang up) |
Done |
| Voice recording consent in greeting ("This call is recorded...") |
Done |
Principle 4: Limiting Collection
Collect only what is necessary.
| Implementation |
Status |
| Minimal data in call logs (no PHI logged) |
Done |
| No medical records access |
Done |
| Registration data limited to BC Health minimum |
Done |
Principle 5: Limiting Use, Disclosure, Retention
Use only for identified purposes; retain only as needed.
| Implementation |
Status |
| Configurable transcript retention (default 90 days) |
Done |
| Configurable call log retention (default 365 days) |
Done |
| Automated purge job (node-cron, daily 3 AM) |
Done |
Admin manual purge trigger (POST /api/admin/data-retention/run) |
Done |
Principle 6: Accuracy
Keep information accurate, complete, up-to-date.
| Implementation |
Status |
| Patient data sourced from OSCAR (no copies) |
Done |
| Confirmation before booking (voice flow) |
Done |
| Registration read-back (voice flow) |
Done |
Principle 7: Safeguards
Protect with appropriate security.
| Implementation |
Status |
| TLS 1.2+ for all traffic |
Done |
AES-256-GCM credential encryption (lib/crypto.ts) |
Done |
| Webhook authentication (3-tier: HMAC-SHA256, API key header, Bearer token) |
Done |
| Rate limiting (5/min auth, 100/min API, 300/min webhooks) |
Done |
| RBAC (admin UI middleware enforcement) |
Done |
Zod input validation (23 schemas — 8 .strict() + 15 .strip()) |
Done |
| Helmet security headers (CSP, HSTS, X-Frame-Options) |
Done |
| Circuit breaker for OSCAR calls (Opossum) |
Done |
PHI log redaction (redactPhi(), 15 PHI field keys across multiple call sites) |
Done |
| bcrypt password hashing (cost factor 12) |
Done |
| Account lockout (5 failed attempts = 15 min) |
Partial — DB fields exist (failedLoginAttempts, lockedUntil) but middleware enforcement not yet wired |
| Automated database backups (daily, 14 retained) |
Done |
Principle 8: Openness
Make policies and practices available.
| Implementation |
Status |
| Privacy policy on website |
Needs update |
| Sub-processor disclosure (Vapi, OCI) |
Needs documentation |
| Retention schedule published |
Planned |
Principle 9: Individual Access
Provide access to personal information on request.
| Implementation |
Status |
| Access request procedure |
Needs documentation |
| 30-day response timeline |
Needs procedure |
| Correction mechanism |
Planned |
Principle 10: Challenging Compliance
Provide mechanism to address complaints.
| Implementation |
Status |
| Complaint procedure |
Needs documentation |
| Privacy Officer contact (per clinic) |
Done |
| Escalation to OPC |
Planned |
Cross-Border Transfers (Vapi.ai -- United States)
PIPEDA allows cross-border transfers with comparable protection.
| Requirement |
Status |
| Comparable protection assessment (Vapi is HIPAA-compliant) |
Done |
| Contractual safeguards (BAA with Vapi) |
In progress |
| Disclosure in privacy policy |
Needs update |
Breach Notification (PIPEDA s.10.1)
| Threshold |
Action |
Timeline |
| Real risk of significant harm |
Report to Privacy Commissioner (OPC) |
As soon as feasible |
| Real risk of significant harm |
Notify affected individuals |
As soon as feasible |
| Any breach |
Document internally |
Immediately |
| Retain records |
24 months minimum |
-- |
Breach response procedure documented in the breach response plan.
3. PHIPA Requirements
PHIPA governs personal health information in Ontario. VitaraVox acts as an agent of the health information custodian (the clinic), not as a custodian itself.
Agent Obligations (PHIPA s. 17)
| Requirement |
Implementation |
Status |
| Act in accordance with custodian's instructions |
Clinic configuration controls behavior |
Done |
| Not collect/use/disclose beyond permitted |
Scheduling only, no medical records |
Done |
| Notify custodian of breach |
Breach notification procedure |
Done |
| Keep information secure |
TLS, AES-256-GCM, access controls |
Done |
Consent Framework
Implied Consent (Circle of Care -- PHIPA s. 20): Patient identification, appointment scheduling, appointment reminders. Status: Done.
Explicit Consent: New patient registration requires explicit verbal consent. Voice script includes "Do you consent to proceed?" Status: Done.
| Area |
PHIPA Requirement |
Implementation |
Status |
| Collection |
Collect directly from individual |
Voice calls direct from patient |
Done |
| Collection |
Collect only necessary information |
BC Health minimum fields |
Done |
| Collection |
Inform of purpose at collection |
Voice agent states purpose |
Done |
| Use |
Use only for collected purpose |
Scheduling only |
Done |
| Disclosure |
Disclose to EMR (same custodian) |
Patient data to OSCAR |
Done |
| Disclosure |
No disclosure to third parties |
Never implemented |
Done |
Security Requirements (PHIPA s. 12)
| Safeguard |
Implementation |
Status |
| Physical |
Cloud infrastructure (OCI Toronto) |
Done |
| Technical |
TLS 1.2+, AES-256-GCM |
Done |
| Administrative |
RBAC, audit logs |
Done |
| Access controls |
Role-based, per-clinic |
Done |
| Audit trail |
All admin actions logged |
Done |
Breach Notification (PHIPA s. 12(2))
| Requirement |
Timeline |
Recipient |
| Notify IPC |
At first reasonable opportunity |
Information and Privacy Commissioner |
| Notify individuals |
At first reasonable opportunity |
Affected patients |
| Notify custodian |
Immediately |
Clinic (for agent breaches) |
Agent Agreement
Written agreements between custodians (clinics) and agents (VitaraVox) are required under PHIPA.
| Element |
Status |
| Permitted uses and disclosures |
Template needed |
| Security safeguards |
Template needed |
| Notification obligations |
Template needed |
| Return/destruction of PHI |
Template needed |
4. SOC 2 Type II
SOC 2 evaluates controls over data security, availability, processing integrity, confidentiality, and privacy. Type II evaluates whether controls operated effectively over 6-12 months.
Trust Services Criteria -- Gap Analysis
Security (Common Criteria)
| Control |
Implementation |
Status |
| CC1.1 Integrity and ethical values |
Code of conduct |
Planned |
| CC2.1 Security policies |
Security policy document |
Needs formalization |
| CC3.1 Risk assessment |
Risk register |
Needs formalization |
| CC4.1 Monitoring activities |
Structured logging (Pino) |
Needs centralized aggregation |
| CC5.1 Logical access controls |
RBAC, JWT, API keys |
Done |
| CC6.1 Encryption |
TLS 1.2+, AES-256-GCM |
Done |
| CC7.1 Vulnerability management |
Trivy scanning |
Planned |
| CC8.1 Incident response |
Breach response procedure |
Done (needs formalization) |
| CC9.1 Change management |
Git-based deployment |
Done |
Availability
| Control |
Implementation |
Status |
| A1.1 Capacity planning |
Resource monitoring |
Needs formalization |
| A1.2 Disaster recovery |
Backup procedures |
Needs testing |
| A1.3 Recovery testing |
DR test schedule |
Planned |
Processing Integrity
| Control |
Implementation |
Status |
| PI1.1 Input validation |
Zod schemas (23) |
Done |
| PI1.2 Processing controls |
Audit logging |
Done |
| PI1.3 Output review |
API responses |
N/A |
Confidentiality
| Control |
Implementation |
Status |
| C1.1 Information classification |
Data classification |
Needs documentation |
| C1.2 Confidential data protection |
Encryption, access controls |
Done |
Privacy
| Control |
Implementation |
Status |
| P1.1 Privacy notice |
Privacy policy |
Needs update |
| P2.1 Consent |
Voice consent flow |
Done |
| P3.1 Collection limitation |
Minimal data |
Done |
| P4.1 Use limitation |
Scheduling only |
Done |
| P5.1 Retention |
Automated retention jobs |
Done |
| P6.1 Access requests |
Access procedure |
Needs documentation |
| P7.1 Disclosure limitation |
No third-party sharing |
Done |
| P8.1 Data quality |
Source from OSCAR |
Done |
High Priority Gaps (Audit Blockers)
| Gap |
Action Required |
Effort |
| Security policies |
Formalize and document |
2 weeks |
| Risk assessment |
Create risk register |
1 week |
| Incident response plan |
Formalize from breach-response.md |
1 week |
| Privacy policy |
Update for completeness |
1 week |
Estimated Costs
| Item |
Cost Range |
| SOC 2 Type II audit |
$30,000 - $50,000 |
| Remediation (internal) |
$10,000 - $20,000 |
| Compliance platform (optional) |
$5,000 - $15,000/year |
| Penetration testing |
$5,000 - $15,000 |
| Total Year 1 |
$50,000 - $100,000 |
Audit Timeline
| Phase |
Duration |
Activities |
| Pre-Audit |
Month 1-3 |
Gap assessment, remediation, documentation |
| Observation |
Month 4-9 |
Controls operating, evidence collection |
| Audit |
Month 10-12 |
Auditor selection, fieldwork, report |
5. Implementation Status
Implemented (Done)
| Item |
Implementation |
Legal Reference |
| AES-256-GCM credential encryption |
lib/crypto.ts -- encrypt/decrypt with random IV. ENCRYPTION_KEY required in production. OSCAR OAuth secrets + SOAP password encrypted at rest |
PIPEDA 4.7 / PIPA s.34 |
| Audit logging |
AuditLog model + middleware. Auto-captures all POST/PUT/DELETE. Redacts passwords/secrets. Admin query endpoint with filters |
PIPEDA 4.1.4 / PIPA s.4 |
| PHI log redaction |
redactPhi() helper strips names, DOB, phone, email, health cards from all log output. Caller phone logged as [SET]/[NOT SET]. 7 log sites redacted in v3.2.1 |
PIPEDA 4.7 |
| Privacy officer designation |
ClinicConfig fields per clinic. Pre-launch validation enforces designation before go-live |
PIPEDA 4.1.1 / PIPA s.4(3) |
| Data retention automation |
jobs/data-retention.ts -- node-cron daily 3 AM. Nulls transcripts after configurable days (default 90). Deletes call logs after configurable days (default 365). Admin manual trigger available |
PIPEDA 4.5 |
| BAA/DPA status tracking |
ClinicConfig fields: baaVapiSigned, baaVapiSignedAt, baaHostingSigned, baaHostingSignedAt. Tracked in admin UI and pre-launch checklist |
PIPEDA 4.1.3 |
| HMAC webhook authentication |
Multi-auth middleware (vapi-auth.ts). HMAC-SHA256 with 5-minute replay window. Constant-time comparison. Mandatory in production |
PIPEDA 4.7 |
| Zod input validation |
23 schemas (8 .strict() + 15 .strip()). validate() middleware factory on all POST/PUT endpoints. Covers auth, clinic, providers, onboarding, tickets, etc. |
PIPEDA 4.7 |
| Rate limiting |
5/min auth, 100/min API, 300/min webhooks. express-rate-limit. Prevents brute-force and DoS |
PIPEDA 4.7 |
| Voice recording consent |
Router greeting includes "This call is recorded for quality and scheduling purposes. By continuing, you consent to recording." |
PIPEDA 4.3 |
| Breach response plan |
Documented procedure covering detection, containment, assessment, notification, remediation. PIPEDA and PHIPA notification timelines included |
PIPEDA s.10.1 / PIPA s.29.3 |
| Helmet security headers |
CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy |
PIPEDA 4.7 |
In Progress
| Item |
Current State |
Next Step |
| BAA/DPA with Vapi |
DPA template drafted, ClinicConfig tracking fields implemented |
Legal execution of agreement |
| BAA/DPA with clinics |
Template drafted |
Legal review and execution per clinic |
| Privacy policy |
Draft exists |
Update for completeness, publish on website |
Planned
| Item |
Priority |
Owner |
Timeline |
| Full SOC 2 Type II audit |
Medium |
Leadership |
Month 6-12 |
| BAA legal review and execution |
High |
Legal |
Month 1-2 |
| Formalized security policies |
High |
Security |
Month 1-2 |
| Risk register |
High |
Security |
Month 2 |
| Vulnerability scanning (Trivy) |
Medium |
Engineering |
Month 2 |
| DR testing and documentation |
Medium |
Engineering |
Month 3 |
| Access request procedure |
Medium |
Privacy Officer |
Month 1 |
| Complaint handling procedure |
Medium |
Privacy Officer |
Month 1 |
| Centralized log aggregation (Loki) |
Medium |
Engineering |
Month 2-3 |
| Penetration testing |
Low |
External |
Month 3 |
| Annual privacy training |
Low |
Privacy Officer |
Annual |
Consent Framework Summary
Implied Consent (Scheduling)
When a patient calls to book an appointment, consent is implied for verifying identity, accessing appointment schedule, creating/modifying appointments, and providing appointment confirmations. Basis: Healthcare operations exception under PIPEDA/PHIPA.
Explicit Consent (Registration)
New patient registration requires explicit verbal consent for collecting personal health information, creating a record in OSCAR EMR, and storing contact information.
Voice agent script: "I'll collect some information to register you as a new patient. This will be stored in the clinic's medical records system. Do you consent to proceed?"
Withdrawal of Consent
Patients may withdraw consent by requesting transfer to staff, stating "I don't want to provide that", or hanging up. System response: Log incomplete interaction, do not persist partial data.
Breach Response Procedure
1. DETECTION
- Monitoring alert / User report / Audit finding
2. CONTAINMENT (Immediate)
- Isolate affected systems
- Revoke compromised credentials
- Preserve evidence
3. ASSESSMENT (24 hours)
- Determine scope
- Identify affected data
- Assess harm potential
4. NOTIFICATION (If required)
- Privacy Commissioner / IPC
- Affected individuals
- Affected clinics
5. REMEDIATION
- Fix root cause
- Update controls
- Document lessons learned
Risk Matrix
| Risk |
Likelihood |
Impact |
Mitigation |
| Breach without BAA |
Medium |
High |
Priority: Execute BAAs |
| Privacy complaint |
Low |
Medium |
Priority: Privacy policy |
| OSCAR credential exposure |
Low |
Critical |
AES-256-GCM encryption (done) |
| SOC 2 audit failure |
Medium |
High |
Follow implementation roadmap |
| Vendor non-compliance |
Low |
Medium |
Vapi BAA + monitoring |
Compliance Calendar
| Frequency |
Task |
Owner |
| Monthly |
Log review |
Engineering |
| Monthly |
Alert review |
Engineering |
| Quarterly |
Access review |
Security |
| Quarterly |
Policy review |
Privacy Officer |
| Annual |
Risk assessment |
Security |
| Annual |
Security review |
Security |
| Annual |
Penetration test |
External |
| Annual |
Privacy training |
Privacy Officer |
| Annual |
Vendor review |
Security |
| Annual |
DR test |
Engineering |