Understanding resident data security and privacy

Resident records, shift notes, cash entries, and incident reports sit in a managed database. Receipt photos and other uploads sit in managed file storage. Neither one sits on a laptop, in a filing cabinet, or on a machine in an office.

No uploaded file sits behind a public link. Each one is filed under your organization and fetched through an address that stops working after five minutes, so a link forwarded by accident has already expired by the time anyone else tries it.

The database and the uploaded files sit in Montreal. The application servers that read them run in Virginia, in the United States. The privacy policy sets out what that means for information leaving the country, and the same regions are written into the agreement you sign.

Easydocks runs on services operated by other companies. They are set out below by category, with the data each one handles.

Managed database and file storage

Holds the record itself: residents, shift notes, tasks, cash entries, incident and abuse reports, and uploaded files. Canada.

Hosted authentication

Holds staff identity only: name, work email, and sign-in credentials. No resident information ever reaches it.

Hosted email delivery

Sends account and notification email. Touches staff email addresses and the contents of those messages.

Push notification delivery

Delivers alerts to a staff member’s phone. Touches device tokens and the text of the notification.

Care records and receipt images are stored in Canada. The application servers that read them, render your screens and generate report PDFs run in the United States. Sign-in, email delivery and push notification delivery also occur outside Canada. Alberta’s Personal Information Protection Act carries a notification obligation about service providers outside the province, and the full disclosure it requires, including the Privacy Officer to contact, is in the privacy policy.

The named list is provided on request and written into the data processing agreement. It is deliberately not published here. Naming your suppliers on a public page hands anybody hunting a newly disclosed weakness in one of them a ready-made list of who to try it on. In the agreement that same list is contractually binding, which is worth considerably more to you than a web page you cannot enforce.

Access follows the houses a person actually supports. Working for your organization does not open your whole organization. A support worker assigned to two houses sees the residents in those two houses. When the assignment ends, the access ends with it.

Administrators see the whole organization, because the role requires it. It is assigned deliberately and is never enabled by default.

This is applied when the data is fetched, before anything reaches the phone. A resident outside a person’s houses is not hidden behind a screen they might get around. It is never sent to their device at all.

Every entry carries who wrote it and when. Beyond that, record types behave differently, and the differences matter too much to compress into a single assurance. Each is set out below.

Cash entries, critical incident reports, and abuse reports cannot be changed or removed. The rule lives inside the database, not in the software sitting on top of it. Application-level protection was considered and rejected, because bulk operations, an admin tool, or somebody with direct access to the data all walk straight past it. This holds against all three. A correction is a new record pointing at the one it corrects, and the original stays readable underneath. No one can revise last month after the fact, including Blueprint Solutions Corp.

A shift note can be fixed in place for fifteen minutes after it is written. That window exists because a support worker who types 14:00 when they meant 16:00 should be able to fix it without filing an amendment. After fifteen minutes, a change becomes a numbered revision carrying a stated reason, and every earlier version stays readable.

Once a Critical Incident Report is submitted, the worker who filed it cannot open it, amend it, or read it back. Corrections are filed as a new report. That is deliberate. An account taken at the time is worth more to you at a review than a tidier one assembled afterwards.

A written service agreement and a data processing agreement are in your hands before a single resident record enters the system, never after a pilot has quietly started collecting it.

The data processing agreement names the suppliers, states what each one is allowed to do with your data, and commits to giving it back.

Easydocks is provided by Blueprint Solutions Corp., an Alberta corporation registered in Calgary. Vendor continuity is a fair question for anyone responsible for resident records, and it is answered in the service agreement rather than by assurance.

You can export everything while the account is active, with no request to submit and no support ticket to wait on. The format is documented, so the file opens in something other than Easydocks. Handing your data back on termination is an obligation under the service agreement, enforceable against the corporation, and does not depend on anyone’s discretion at the time.

There is no source-code escrow and no third-party continuity arrangement. Neither is claimed until one exists. If continuity is a requirement for your board, raise it in the demo and it will be answered straight.

You can export everything in your account at any time while it is active. On termination the service agreement obliges Blueprint Solutions Corp. to deliver a complete export and then to return or destroy the remaining records on your written instruction, subject to any retention period your own obligations require. There is no exit fee, and nothing is held back to make leaving harder.