Security

Every account belongs to a region — Canada or the United States — recorded when it is created, not guessed from your address or your browser. The region travels with the account through the whole system, and the background jobs that process a Canadian account's records run on Canadian workers.

This is what lets us say a Canadian family's records are meant to stay in Canada, rather than hoping they do.

The software honours the region rule today. Placing those regions in specific Canadian and US data centres — choosing the provider, signing the agreements that let a health product use them, and deploying there — is work we do at launch, and it is not finished.

Until this page says otherwise, treat data residency as designed for and enforced in the code, not yet proven in production.

Being the person who created a record does not make you the person allowed to read it. Access flows only from a current relationship — you are the subject, their guardian, or their caregiver — or from a consent that has not been withdrawn.

This closes a real hole we studied in an older system, where “who typed this in” was treated as “who may read this”, so a parent who had lost custody kept access to a child's record indefinitely.

On every route that touches health information, the permission check and the read happen in a single database query. There is no gap between asking “may they?” and doing it in which the answer could change.

Every route is private by default: an unauthenticated request is refused, and an automated test walks the whole API to confirm no route was accidentally left open.

End a guardianship, revoke a caregiver's consent, or suspend someone's membership, and the access stops immediately. A suspended member cannot authorise anything — there is a single gate for that, with a test guarding it.

Relationships are ended, never deleted: the row survives with the date and the reason, because “who could see this in March, and why did that stop” is a question an audit has to be able to answer. The database itself refuses to delete these rows.

Access to and changes of health information are written to an audit log, along with sign-ins, sign-outs, invitations and account changes. The database withholds UPDATE and DELETE on that log from the application, so the application can add to the audit trail and cannot tidy it up afterwards.

Errors carry a stable code and a request identifier, so a problem can be traced end to end. Passwords and session tokens are never written to logs.

Exporting a grid of records is a disclosure of health information, so every completed export writes an audit row saying who exported what and how many rows, and download links are time-limited. This is landing alongside the saved-views and export work and is not finished yet.

Sign-in is real: passwords of at least 12 characters, sessions that can be revoked, and identities stored in our own database rather than handed to a third-party identity provider — which is also what keeps them inside your region.

Time-based one-time-password enrolment and single-use recovery codes are available. Two-factor sign-in is required for owners, administrators, clinicians and assistants, and remains optional for members. Consent changes and exports are registered as step-up actions in the central authentication policy.