Skip to content
IMECore

Legal

Security

How we protect personal health information today, and what we do not yet claim. Every control described here is live in the product.

Last updated: 28 August 2026. For the named subprocessors and where each runs, see subprocessors. For the data processing duties, see the DPA summary.

Security documentation on request

We share our security and privacy documentation on request: the Privacy Impact Assessment, records of processing, data processing agreement, subprocessor list, and breach-response runbook. Ask and we will send them.

What is live

Controls that are in the product today

Each control describes what it does for you.

Workspace tenancy

Every case belongs to one workspace. We scope every request to that workspace. A user in one workspace cannot read another workspace's cases.

Role-based access inside the workspace

Roles include intake, records, clinic, scheduler, report writer, QA, finance, workspace admin, examiner, referrer, and examinee. Each role has the minimum access it needs.

Permission check on every request

Every request for personal health information passes a permission check. The check is the gate. Hiding a button in the interface is not the control.

Audit of access to health information

Every time someone opens personal health information, we log who opened it and when, what they opened, and why where a reason applies. The log is append-only. You can export it for a claim file or a review.

Canada-resident AI processing

Every request is checked before any information is sent for processing. Health information may only go to a model that runs in Canada. 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.

Human in the loop

AI proposes. A person approves. Extracted fields, draft mail, bookings, and report deliveries reach a person or the client only after a named person approves. Each approval is logged.

Encrypted tokens

Outlook mailbox tokens are encrypted with AES-256-GCM. We use HTTPS for every connection to the AI provider and for all browser traffic.

Retention and deletion

Retention policies are set per workspace and client type. A closed case enters a review queue. A person approves deletion. Deletion removes the database rows, the files, and the derived indexes. Legal hold blocks deletion.

Residency

Where your data lives

Where your data is stored

Your case files, records, and indexes live on Cloudflare. We ask Cloudflare to keep them in Western North America. Cloudflare does not offer a Canada-only choice for this storage, so we cannot promise that stored data never leaves Canada. We tell you this plainly because public-body work under FOIPPA requires storage in Canada.

Where it is processed

When an AI model works with health information, it runs only in Canada. We verify that on every request. That distinction matters: processing in Canada is verified; storage in Canada is requested, not guaranteed.

We track this gap for each environment and share the findings on request. If a Canada-only storage option becomes available, we will use it.

Evidence

What we can show you

Documentation, not claims

Ask and we will send the Privacy Impact Assessment, records of processing, data processing agreement, subprocessor list, and breach-response runbook. Each one reflects the product as it runs today.

No invented uptime

We do not publish an uptime percentage. We have not measured for long enough to stand behind a number. The service levels describe what we do: respond within one business day, keep the audit trail, respect workspace boundaries and residency, protect transmission, and honor retention. Your signed agreement sets any remedy.

Encryption: what is true

We encrypt data in transit with TLS for all browser traffic and for AI provider connections. We encrypt stored mailbox tokens with AES-256-GCM. For stored case data we rely on the Cloudflare platform and we do not claim more than it guarantees.

Audit: what the log has and lacks

The log records who accessed what and when, including reads. The log is append-only. Each action that carries a reason includes it.

Planned

What is planned next

We will do these in the order that most lowers privacy risk:

  • Add IP address and browser details to the audit record so a breach review can locate access.
  • Capture the specific record or document ID on every view of health information, not only on approvals.
  • Add detection for bulk access to health information.
  • Store the written breach record outside the main database so it survives a platform rebuild. PIPEDA requires 24 months.
  • Pursue a signed data processing agreement with Cloudflare and confirm Azure coverage with counsel. Press Cloudflare for a Canada-only storage option and switch to it when it ships.

If your security questionnaire needs a control mapped to the product, email security@imecore.com or privacy@imecore.com. We will answer plainly and tell you where we cannot yet tick the box.

FAQ

Questions about security

What security documentation can you provide?

On request we provide our Privacy Impact Assessment, records of processing, data processing agreement, subprocessor list, and breach-response runbook. We also share our access-control and audit design.

Which privacy laws apply?

The regime is Canadian: PIPEDA federally, BC PIPA for private clients such as insurers and law firms, and FOIPPA for public bodies including WorkSafeBC and ICBC. We build to FOIPPA, the strictest of the three, so every client type is covered.

How can we verify the controls?

We provide our security and privacy documentation on request: the Privacy Impact Assessment, records of processing, data processing agreement, subprocessor list, and breach-response runbook. You can also export the audit log for any case.

Send us your security questionnaire

We answer every row with what is live and what is not. No badge we have not earned.