Asellera PHIPA + PIPEDA COMPLIANCE MAPPING DOCUMENT

1. PURPOSE OF THIS DOCUMENT

This document demonstrates how Asellera satisfies:

• PHIPA (Personal Health Information Protection Act, Ontario)

• PIPEDA (Personal Information Protection and Electronic Documents Act, Canada)

• 
  

It maps each legal requirement to:

• Technical controls (AWS, Supabase, AI system)

• Administrative controls (policies, governance)

• Operational controls (logging, workflows)

2. PHIPA COMPLIANCE MAPPING

2.1 Accountability (PHIPA Principle)

Legal Requirement:

An organization must be responsible for personal health information under its control.

Asellera Controls:

• Defined Privacy Officer role (see governance doc)

• Vendor Management Policy

• Access Control Policy

• Audit logging across all systems

System Implementation:

• AWS IAM roles enforce responsibility boundaries

• Supabase tenant isolation (clinic_id)

• Audit logs stored in audit_logs table

2.2 Identifying Purposes

Legal Requirement:

Patients must be informed why data is collected.

Asellera Controls:

• Patient intake consent flow

• Privacy policy disclosure

• AI transparency disclosure

System Implementation:

• Web intake forms with consent checkboxes

• Retell voice AI disclosure script

• SMS opt-in confirmation flows

2.3 Consent

Legal Requirement:

Meaningful consent must be obtained before collecting PHI.

Asellera Controls:

• Consent Framework (stored in Supabase)

• Revocation mechanism

• Timestamped consent logs

System Implementation:

Consent table:

patient_id

clinic_id

consent_type

status (granted/revoked)

timestamp

source (web/sms/voice)

version

2.4 Limiting Collection

Legal Requirement:

Only necessary data should be collected.

Asellera Controls:

• AI prompt minimization layer

• Backend filtering before OpenAI calls

• Structured intake forms

System Implementation:

• AI orchestrator strips unnecessary PHI

• n8n workflows pass only required fields

2.5 Limiting Use, Disclosure, and Retention

Legal Requirement:

PHI must only be used for stated purposes.

Asellera Controls:

• Data Retention Policy

• Role-based access control

• Workflow scoping by clinic

System Implementation:

• Supabase RLS policies enforce clinic isolation

• No cross-tenant data sharing

• Retention scripts in /scripts

2.6 Accuracy

Legal Requirement:

PHI must be accurate and up to date.

Asellera Controls:

• Human review of AI-generated SOAP notes

• Editable clinical dashboard

• Version control for records

System Implementation:

• soap_notes.status = draft/approved

• Clinic staff final approval required

2.7 Safeguards

Legal Requirement:

Protect PHI against loss, theft, or unauthorized access.

Asellera Controls:

• Encryption (AES-256 + TLS)

• IAM least privilege

• RLS enforcement

• Secrets Manager usage

System Implementation:

• AWS CloudTrail logging

• Supabase RLS:

clinic_id = auth.jwt() ->> 'clinic_id'

2.8 Openness (Transparency)

Legal Requirement:

Organizations must be transparent about practices.

Asellera Controls:

• Public Privacy Policy

• AI Disclosure Policy

• Vendor disclosure list

System Implementation:

• Clinic-facing documentation portal

• Patient-facing privacy page

2.9 Individual Access

Legal Requirement:

Patients can access their records.

Asellera Controls:

• Clinic dashboard access layer

• Record retrieval API

System Implementation:

• API endpoint:

  • /api/patient/:id/records

• Supabase read policies scoped to clinic

2.10 Breach Notification

Legal Requirement:

Notify affected individuals and regulators if breach occurs.

Asellera Controls:

• Incident Response Plan

• Audit logging system

• Severity classification (SEV1–SEV3)

System Implementation:

• incident_report workflow in n8n

• API key revocation scripts

• Log preservation system

3. PIPEDA COMPLIANCE MAPPING

3.1 Accountability

Controls:

• Defined governance structure

• Vendor oversight policy

System:

• Central audit logs

• IAM role ownership tracking

3.2 Identifying Purposes

Controls:

• Consent capture at intake

System:

• Web + SMS + voice consent flows

3.3 Consent

Controls:

• Explicit opt-in required

System:

• Consent stored in Supabase

• Versioned consent text tracking

3.4 Limiting Collection

Controls:

• AI data minimization layer

System:

• Backend sanitization before OpenAI calls

3.5 Limiting Use & Disclosure

Controls:

• Role-based access control

• Tenant isolation

System:

• Supabase RLS + AWS IAM enforcement

3.6 Retention Limitation

Controls:

• Defined retention policy

System:

• Automated deletion scripts in /scripts

3.7 Accuracy

Controls:

• Human-in-the-loop verification

System:

• SOAP note approval system

3.8 Safeguards

Controls:

• Encryption + logging + access control

System:

• AWS + Supabase security stack

3.9 Openness

Controls:

• Privacy policy transparency

System:

• Public + clinic-facing documentation

3.10 Individual Access

Controls:

• Patient record access layer

System:

• API + dashboard access controls

4. SUMMARY CONTROL MATRIX

Legal Requirement

Control Type

System Implementation

Accountability

Governance

Policies + audit logs

Consent

Technical + Legal

Supabase consent table

Safeguards

Technical

AWS + Supabase + encryption

Retention

Operational

scripts/ retention jobs

Access

Technical

API + RLS

Transparency

Legal

Privacy + AI disclosure docs

Breach Response

Operational

Incident response system

5. RESIDUAL RISK STATEMENT

After implementation:

• Low risk: unauthorized access (mitigated by RLS + IAM)

• Medium risk: AI misinterpretation (mitigated by human review)

• Low risk: vendor exposure (mitigated by encryption + contracts)

6. CONCLUSION

Asellera demonstrates:

• Full PHIPA principle alignment

• Full PIPEDA principle alignment

• Strong technical enforcement of privacy obligations

• Audit-ready mapping of law → system controls

Approval

Approved By: Shane Senha, CEO
Company: Asellera
Version: 1.0
Date: June 16th 2026