Legal
Privacy Impact Assessment
IMECore coordinates Independent Medical Examinations. It holds claimant identity, medical records, exam findings, and reports. This PIA explains what we assessed, what the risks are, and what we do about them.
In BC the instrument is a PIA. FOIPPA requires a public body to complete one before it uses a new system with personal information.
A client that is a public body — WorkSafeBC, or ICBC as a Crown corporation treated as public-body work — may need its own PIA before it places personal information in IMECore. This page and the record of processing are meant to help that review.
Scope
What this assessment covers
The product as it exists today: intake, records, scheduling, report drafting and review, and billing. One workspace model, one case file, one audit trail.
Information at issue
Personal health information. Claimant identity, clinical records, exam findings, and reports. Doctor payout details are personal and financial data and we protect them the same way.
Who uses it
Intake coordinators, records specialists, examiners, referrers, workspace admins, and system agents. Each role has its own permission set.
Legal frame
PIPEDA as the federal baseline, BC PIPA for private-sector clients, and FOIPPA where a public body is the client. FOIPPA requires storage and access in Canada.
Flow
How personal information moves
- Referral intake. Email arrives through the Outlook connector or manual upload. The extractor pulls fields. A coordinator reviews and approves.
- Records collection. Record PDFs land in R2. Extracted text and indexes live in D1. A records specialist organizes and deduplicates.
- Scheduling. The workspace books an examiner. The examiner sees only that case in the portal. No attachments by email.
- Report. The examiner drafts. A reviewer approves. The workspace delivers. Each approval writes an audit event.
- Billing and retention. Invoices and payouts flow through the finance role. Retention carries until the workspace policy says delete. A human approves deletion.
Risks
What could go wrong
Wrong person sees the file
A user reads a case outside their workspace or role. A link leaks outside the portal. An agent acts on the wrong case.
Data leaves Canada
A tool sends content to a United States model or log sink. An export lands on a United States device. A backup replicates to a United States region.
No one can show who accessed what
The audit log misses an access, or a report leaves without an approval record. A breach review has no trail.
Retention runs too long or short
We keep a file past its legal period, or we delete a file under legal hold. The workspace has no clear policy per client type.
Controls
What we do about each risk
Workspace tenancy and RBAC
Every case belongs to one workspace. We scope every request to that workspace. Roles define what each person may view, edit, export, and approve. The permission check is the gate. Hiding a button in the interface is not the control.
Human in the loop
AI proposes. A human approves. Extracted fields, bookings, and report deliveries reach a person or the client only after a named human approves. Each approval is an audit event.
Audit trail
Every time someone opens health information, we log who opened it, what they opened, when, and why where a reason applies. The log is append-only. See security for current limits.
Canada-resident inference
Health information may only go to a model that runs in Canada. Every request is checked before any information is sent for processing. We verify with the provider that the work actually happened in Canada, on every request. We do not send health information to providers without a Canada-only option.
Storage residency honesty
Case data and files live on Cloudflare with a Western North America location hint. There is no Canada-only choice for this storage today, so the hint is best-effort, not a guarantee. We track this gap for each environment and share the findings on request. Processing of health information in Canada is verified on every request; storage in Canada is requested, not guaranteed.
Retention and deletion
Retention policies are set per workspace, data class, and client type. Elapsed cases surface in a review queue. A person approves deletion. Deletion removes the database rows, the files, and the derived indexes. Legal hold blocks the queue.
Residual risk
What the client must still handle
IMECore lowers risk. It does not remove the client's own duties.
- Your own PIA if you are a public body under FOIPPA. Use this page and the record of processing as input. We can provide a questionnaire-style annex on request.
- Exact retention years per client type. We ship the mechanism with a conservative default. Your counsel and insurer contracts set the years.
- Breach-notification ownership and timelines. The runbook names the steps. Your service agreement should name who notifies the OIPC and the affected persons.
- De-identification bar for any United States model use. We send only de-identified text. Your privacy officer should approve that bar.
Email privacy@imecore.com to request a PIA annex, the data flow notes, or the deployment check output for your environment.
Read next
Related documents
FAQ
Questions about this assessment
Is this our client's PIA?
No. This page describes the PIA for the IMECore product. A public body such as WorkSafeBC must complete its own PIA under FOIPPA before it uses a new system with personal information. This page is evidence for that review, not a substitute for it.
Which law requires the assessment?
In BC the instrument is a Privacy Impact Assessment. A public body must complete one under FOIPPA before it uses a new system that holds personal information. PIPEDA and BC PIPA set related duties for private-sector work.
Need a PIA annex for your board?
We can send the data flow, the control list, and the deployment findings for your environment.