CareNucleus — PIPEDA alignment assessment (technical)

Document type: Internal technical mapping · Not a legal opinion
Framework: PIPEDA Schedule 1 — Fair Information Principles
Scope: apps/web-carenucleus codebase + published privacy materials
First issued: March 2026 · Last revised: March 23, 2026 (aligned with incremental privacy implementation)

Executive summary

CareNucleus shows privacy-by-design in code: tenant-scoped data access (service-store, secureHandler), PHI minimization and runtime guards before LLM calls, encrypted EMR refresh tokens when ACCURO_TOKEN_ENCRYPTION_KEY is set, and graceful AI degradation on errors. The privacy policy and subprocessors materials describe purposes, consent, retention, transfers, and breach themes.

Current product evidence (revised March 23, 2026):

DSAR & breaches — Persisted via src/lib/store/privacy-ops-store.ts (same JSON-backed persistence as other service entities until DB migration).
Dashboard API — src/app/api/v1/privacy-dashboard/route.ts returns privacyPosture from src/lib/privacy/compliance-posture.ts (no hard-coded "compliant" flags).
Consent KPIs — Communication preferences aggregated from patient_prefs_{tenantId}_* in src/lib/privacy/consent-metrics.ts (not full clinical consent inventory).
Audit — dataStore.logAudit accepts actorUserId / actorUserName in details; dashboard merges getAuditEventsByTenant.
AI governance — skipMinimization only in local dev (not production-like); one-time log when using public LLM APIs without Azure OpenAI.
Startup — src/instrumentation.ts logs privacy env warnings (LLM residency, EMR key).
Openness — public/legal/SUBPROCESSORS.html, public/legal/PRIVACY-OPERATIONS-PLAYBOOK.html, policy §6.3/§8 hedged for deployment reality.
Tests — tests/privacy/compliance-posture.test.ts (Vitest) for posture derivation.

Remaining gaps: production-grade DB + KMS if you promise them contractually; automated retention jobs; pen test; legal sign-off; optional DSAR seed only with CN_PRIVACY_SEED_DEMO=true (non-production).

Methodology

Reviewed PIPEDA’s 10 principles (Schedule 1) as headings.
Cross-referenced: PRIVACY-POLICY-CANADA.md, secure-handler.ts, data-store.ts, privacy-ops-store.ts, privacy-dashboard/route.ts, compliance-posture.ts, consent-metrics.ts, clinical-ai-service.ts, instrumentation.ts, patient preferences API, marketing compliance/privacy pages.
Rated each principle: Met (code) · Partial · Gap · Policy only

Principle-by-principle mapping

Principle	Status	Evidence in CareNucleus	Notes / gaps
1 — Accountability	Partial	Privacy policy designates a Privacy Officer and accountability for subprocessors (public/legal/PRIVACY-POLICY-CANADA.md §3). API layer centralizes auth, optional audit flags (src/lib/api/secure-handler.ts).	Ensure a named officer, board-approved privacy program, vendor DPAs, and training records exist outside the repo. Updated: Dashboard API exposes `privacyPosture` (derived signals) instead of static compliance flags.
2 — Identifying purposes	Policy + Partial	Policy tables list purposes for collection (healthcare delivery, AI documentation, billing, security, etc.) — §4.2. Patient preferences API documents consent timestamps (src/app/api/v1/patients/[patientId]/preferences/route.ts).	Confirm in-product notices and customer agreements match policy for each module (voice, fax, outreach, AI interviewer).
3 — Consent	Policy + Partial	Policy distinguishes express vs implied consent; custodian vs agent roles (§5). Patient prefs API stores opt-ins and `consentRecordedAt` (preferences/route.ts). Privacy dashboard consent KPIs derive from consent-metrics.ts (communication channels — scoped note in `privacyPosture.consentMetricsScopeNote`). Related UI types: src/lib/api/dashboard.ts `ConsentState`.	Validate consent UX and custodian workflows per province; AI/audio need explicit paths in runbooks. Dashboard percentages are communication-prefs, not a full clinical consent register.
4 — Limiting collection	Partial	PHI minimization pipeline before LLM calls (src/lib/ai/clinical-ai-service.ts, src/lib/ai/phi-minimization). Runtime guard blocks payloads that fail validation (`validateLlmPayload`).	Audit each feature for “nice to have” fields; ensure analytics/logging does not over-collect identifiers.
5 — Limiting use, disclosure, retention	Policy + Partial	Policy §6 (updated subprocessors / cross-border narrative) links to SUBPROCESSORS.html. Tenant-scoped stores; DSAR/breach records persist with other entities via privacy-ops-store.ts.	Infra gap: Same JSON file persistence (.data/store.json in dev) — not a substitute for production DB, legal hold, or automated disposition. Implement retention jobs and secure disposal in target hosting.
6 — Accuracy	Partial	Policy §7; clinical documentation has authorship, versioning, provenance structures (data-store.ts `PatientDocumentRecord`).	DSAR/correction flows should update authoritative records and EMR writebacks consistently; test edge cases.
7 — Safeguards	Partial	`secureHandler`: auth context, CSRF for state-changing methods, rate limiting, optional audit (secure-handler.ts). EMR refresh tokens: AES-256-GCM when `ACCURO_TOKEN_ENCRYPTION_KEY` set (emr-token-protection.ts). AI errors caught; fallback responses (clinical-ai-service.ts). Startup privacy signals logged (instrumentation.ts + compliance-posture.ts).	Policy aligned: §8.2/§8.3 now describe deployment-dependent encryption and hosting (dev JSON vs production targets). Still required for enterprise claims: KMS, field/database encryption scope, backup encryption, RBAC review, pen test.
8 — Openness	Met (docs)	Privacy policy; compliance & privacy marketing pages link to subprocessors, playbook, and this assessment (compliance/page.tsx, privacy/page.tsx); i18n in en.json / fr.json. SUBPROCESSORS.md / .html; policy §6.3 references subprocessors path.	Keep subprocessors list current when vendors change; ensure deployed URL matches customer communications.
9 — Individual access	Partial	Policy §9 (30-day framing). privacy-dashboard/route.ts: DSAR CRUD on `ctx.tenantId`; PUT/POST audited with actor fields; in-app UI src/app/(app)/privacy-dashboard/page.tsx shows `privacyPosture` caveats.	DSAR/breach rows persist via privacy-ops-store.ts; audit tab merges `getAuditEventsByTenant`. Optional demo DSARs: env `CN_PRIVACY_SEED_DEMO=true` (tenant `tenant-1` only). Enterprise immutable ledger / ticketing still optional hardening.
10 — Challenging compliance	Policy + Partial	Policy: Privacy Officer contact and complaints (§9–10). Playbook: PRIVACY-OPERATIONS-PLAYBOOK.html. API: authenticated `POST` with `type: "breach_record"` + `logAudit` on privacy events.	Formal intake (ticketing, mailbox SLAs) and OPC filing workflows stay organizational; link playbook from compliance/page.tsx and privacy/page.tsx.

Cross-cutting technical topics

AI & cross-border processing

LLM calls support OpenAI, Azure OpenAI, and Anthropic via env (clinical-ai-service.ts).
Public OpenAI/Anthropic endpoints may process outside Canada unless using Azure OpenAI in Canadian regions + appropriate DPAs.
PHI minimization and validateLlmPayload run before send; skipMinimization is blocked outside local dev.
One-time per-process info log when not using AZURE_OPENAI_ENDPOINT; production startup warns via compliance-posture.ts / instrumentation.ts.
Does not replace transparency, consent, and contracts for transfers.

Multi-tenancy

Positive: Privacy dashboard POST/PUT ignore body tenantId; use ctx.tenantId from auth.
Positive: logAudit maps actorUserId / actorUserName from details to audit event identity fields.
Verify: All PHI routes use secureHandler or equivalent; webhooks use signed handlers — periodic static audit recommended.

Storage architecture (dev vs prod)

Privacy DSAR/breach entities use the same service-store → data-store JSON persistence path as other features until DATABASE_URL / DB store is primary.
Align production deployment, encryption, backups, and access logging with customer-facing commitments in PRIVACY-POLICY-CANADA.md.

Recommended action checklist

Legal/privacy: Have counsel review privacy policy vs actual hosting, AI providers, and provincial health law roles (custodian/agent).
Subprocessors: Keep SUBPROCESSORS.html current; execute DPAs with providers per policy.
Production infra: Migrate PHI to encrypted managed DB + KMS where promised; backup encryption; pen test.
Done (incremental): Persistent DSAR/breach stores; privacyPosture API; consent metrics from prefs keys; playbook + subprocessors pages; logAudit actor fields; AI skip-minimization guard.
Security testing: Schedule penetration test and dependency scanning; document results for enterprise customers.
AI governance: Monitor guard blocks; prefer Azure OpenAI in Canada for residency-sensitive tenants.

Key file references

public/legal/PRIVACY-POLICY-CANADA.md — principles; §6.3 / §8 deployment-aware wording
public/legal/SUBPROCESSORS.html / SUBPROCESSORS.md — subprocessor categories
public/legal/PRIVACY-OPERATIONS-PLAYBOOK.html — DSAR / breach ops outline
src/lib/api/secure-handler.ts — auth, CSRF, rate limits, audit hooks
src/lib/store/data-store.ts — persistence, logAudit, getAuditEventsByTenant, custom data keys
src/lib/store/service-store.ts — tenant-isolated entity pattern
src/lib/store/privacy-ops-store.ts — DSAR + breach stores
src/app/api/v1/privacy-dashboard/route.ts — dashboard API, privacyPosture, breach POST
src/app/(app)/privacy-dashboard/page.tsx — in-app posture UI
src/lib/privacy/compliance-posture.ts — posture derivation + startup messages
src/lib/privacy/consent-metrics.ts — prefs-based consent aggregates
src/lib/ai/clinical-ai-service.ts — PHI minimization, guards, cross-border notice
src/lib/security/emr-token-protection.ts — EMR token encryption
src/instrumentation.ts — privacy startup logging
src/app/api/v1/patients/[patientId]/preferences/route.ts — prefs + consent timestamps
tests/privacy/compliance-posture.test.ts — Vitest for posture logic
.env.example — CN_PRIVACY_SEED_DEMO, AI, EMR key notes