What happens to resident information once it is in here

Resident records, shift notes, cash entries, and incident reports sit in a managed Postgres database. Receipt photos and other uploads sit in managed file storage. Neither one lives on a laptop, a desk drawer, or a machine in somebody’s 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, and pretending otherwise would fall apart the first time you asked. They are listed here by category, with the data each one touches.

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 somebody has to. You hand that role out deliberately. It is never switched on 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. Past that, different records behave differently, and the difference matters far too much to round off into one reassuring sentence. So here is each one.

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. Nobody can quietly tidy up last month, and that includes me.

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. Ask for both documents during the demo and you will get them, with no procurement process to sit through first.

Easydocks is provided by Blueprint Solutions Corp., an Alberta corporation, and it is a small operation. If you are responsible for resident records, that is a fair question to ask out loud, and the honest answer is a set of commitments you can hold me to in writing.

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 when you leave is written into the service agreement as an obligation, so it does not depend on my goodwill on the day.

You can export everything in your account at any time while it is active. If you leave, you get a full export and written confirmation that your data has been deleted. There is no exit fee, and nothing is held back to make leaving harder.