Legal

Data processing agreement

This page explains how IMECore handles personal information when it acts on your instructions. It draws on the controls described in trust and security.

Note

This page summarizes the agreement. The signed data processing agreement governs your use of IMECore. This summary is not legal advice. Counsel should review the signed terms for your organization.

Roles

Parties and roles

The agreement names who decides why the information is processed and who carries out the processing.

Customer, controller

You, the customer, are the controller. Your workspace decides why personal information is collected and used. You remain responsible for the notices, consents, and fare collection that the law requires for the cases you place in IMECore. When the customer is a public body such as WorkSafeBC, FOIPPA applies to that work.

IMECore, processor

IMECore processes personal information only to provide the service and only on your documented instructions. We do not sell case data. We do not use case data to train a general model. Any instruction that would conflict with Canadian law requires a written resolution before we act.

ICBC is a Crown corporation. We treat its work under the public-body FOIPPA-style rules set out in the trust page.

Information

Categories of personal information

The agreement lists what we may process on your behalf. Treat every item below as sensitive.

Claimant identity
Name, date of birth, address, personal health number, and claim numbers such as ICBC, WorkSafeBC, and long-term disability policy numbers.
Medical records
Referral record packages. Often thousands of pages per case: clinical notes, imaging reports, specialist consults, and hospital records.
Exam findings
The examiner's notes, measurements, and dictated observations.
Reports and drafts
The finished IME report and every draft. It links identity to medical opinion, so it is the most sensitive object we hold.
Examiner payment details
Personal and financial details used to pay examiners and to issue invoices. We protect this in the same way as health information.

Purpose

Purposes of processing

IMECore processes personal information only for these purposes:

to open and run IME cases from referral intake through to billing;
to collect, organize, and index medical records for a specific case;
to schedule examinations and support report drafting, review, and delivery;
to keep the audit trail and to provide the service securely; and
to support you with case handling on your written request.

We do not pool personal health information across cases to train models or for analytics outside the case.

Subprocessing

Subprocessors and permitted use

We use a small set of subprocessors. Each one has a written agreement that carries the same residency and confidentiality duties.

The signed data processing agreement lists the subprocessors that may touch customer data. See the subprocessor list for the current names, what each does, where it runs, and whether personal health information may reach it.

We may add or change a subprocessor only in line with the notice duty in the signed agreement. The notice period and your right to object are set there. We will not reduce the Canada residency protection through a subprocessor change without your agreement.

The agreement includes a DPA with Cloudflare for Workers, D1, R2, Queues, and KV, and a DPA with Azure where model inference touches personal health information.

Residency

Canadian residency commitment

Data residency is a contractual duty, not a preference.

Case data, extracted fields, and indexes live on Cloudflare. We ask Cloudflare to keep them in Western North America. There is no Canada-only choice for this storage today, so the hint is best-effort. We track this gap for each environment and share the findings on request.
Record PDFs, OCR output, and report files live on Cloudflare. We ask Cloudflare to keep them in Western North America. There is no Canada-only choice for this storage today, so the hint is best-effort.
Model inference that carries personal health information runs only in Canada. We verify that on every request. We do not send health information to providers without a Canada-only option.
No personal health information goes to a United States region, replica, log sink, or analytics tool. Exports and backups follow the same rule.

Security

Security measures

Access control

Workspace tenancy plus role-based permissions. A user in one workspace cannot read another workspace's cases. Each role has the minimum access its work requires. Agents carry their own identity and the same limits.

Human in the loop

AI drafts, a person approves. Intake, booking, report delivery, and outbound email reach a person or the client only after a named human approves. Each approval is itself an audit event.

Transmission and handling

Encryption in transit. Examiners work through the portal. No personal email with attachments. No second copy of the file outside the system.

Least collection

We take the minimum needed to run the case. Referral packages arrive as they are. We do not pull extra data sources.

Audit

Audit trail

Every access is recorded. The log is append-only.

Who, what, when, and why. The log records the user or agent, the case and object, and the time. Where the action carries a reason, such as "opened to QA report," we log the reason.
Reads as well as writes. Viewing a medical record is an access.
Agent actions log the agent identity plus the approving human where a human gate applied.
Audit rows are append-only. No edit. No delete. You may export the trail for a claim file or a grievance response.

Breach

Breach notification, BC PIPA

The agreement tracks the duties that BC PIPA sets for a breach that creates a real risk of significant harm.

Detect. Audit and access logs make unusual access visible.
Contain. Revoke access, kill the token, disable the account, and rotate keys.
Assess. What information, which claimants, how many, and the real risk of significant harm.
Notify. Where the risk bar is met, notify affected individuals and the BC Information and Privacy Commissioner (OIPC) without unreasonable delay. The signed agreement may set a shorter internal notice to you. The shorter duty controls.
Record. Keep a written record of every breach, whether notice was required or not. The OIPC may ask for it.

Lifecycle

Retention, deletion, return, and export

Retention and deletion

Retention periods are set in the customer agreement. At the end of retention, or on a valid request, we delete the case, its records in R2, its rows in D1, and derived indexes such as OCR text, embeddings, and index entries.

Deletion is real deletion. The bytes go. We do not rely on a hidden flag. A small audit stub that records that a case existed and was deleted on a given date may remain if counsel requires it.

Data return and export on termination

You may request export and return of your case data before termination takes effect. Export runs through the system, is logged, and follows the same Canada residency rule for where the file lands.

After the return window, we delete remaining case data in line with the agreement.

Request

How to request the signed agreement

Email privacy@imecore.com with your organization name and workspace. We will send the current data processing agreement for signature or for your counsel to review.

Refer to the subprocessor list for every third party that may process customer data under the agreement.

View subprocessors Read trust and security

FAQ

Questions about the agreement

Does this page replace the signed agreement?

No. This page summarizes the data processing agreement. The signed document between you and IMECore governs. If there is a conflict, the signed document controls.

How do we request the signed agreement?