HeyDiane Visits: how client data is protected

What we do not claim

We do not claim compliance certification under any privacy or health-information statute: not PIPEDA, not HIA, not PHIPA, not Alberta's Access to Information Act and Protection of Privacy Act. There is no badge on this page and no “compliant” checkbox, and there will not be one without a legal review on file. Compliance belongs to your agency's whole operation: your policies, training, retention schedule and information-sharing agreements. It is not a property of one tool inside it.

HeyDiane Visits is a hosted product. Your records live in a database project we operate, and the master key your agency's key is derived from sits in our deployment configuration. That means we hold the technical ability to decrypt your data. The controls below record and limit access; they do not make decryption physically impossible, and a hosted vendor who says otherwise is describing a client-side-key design we have not built. Assess us on the controls.

The encryption model

What is sealed. Placement and client addresses, contact phone numbers, and case-note narratives are stored as ciphertext, never as readable text in the database.

How. AES-256-GCM, with a 96-bit random IV generated for every field on every write and the authentication tag stored beside it. A ciphertext that has been altered fails its tag and returns nothing. Each ciphertext is also bound to the table, record and field it belongs to, so one record's sealed value moved onto another record does not open.

Per-agency keys. Each agency's key is derived with HKDF-SHA256 from the master key, salted with that agency's own identifier. Another agency's key does not open your records, even if a query is wrong.

The master key. It lives in deployment configuration, not in the database and not in source control. In any deployed environment, preview environments included, a missing key makes the vault refuse to seal or open anything; there is no default key to fall back to. Keys can be rotated: the system reads under retired keys while writing under the current one, and a documented script re-seals stored records.

What is not sealed. Names, file references and visit times are stored in readable form, because scheduling runs on them. Reads of those fields are not in the reveal log below. Ask us for the current list of unsealed fields before you decide.

The reveal log

Day to day, the schedule shows coded file references, first names and zones. A worker sees a sealed address only by deliberately opening it.

Every successful reveal writes a row: which agency, record type, record, field, who, and when. The row is written before the plaintext is returned, and if it cannot be written, nothing is returned.

The database refuses to update, delete or truncate the log for every role, including the service role our own server uses and replica mode. A person with administrative access to the database could still change the schema itself; this constrains the application and its credentials, not an administrator.

We got this wrong once. An earlier migration gave signed-in users a blanket read-write policy on the log, which would have let a worker delete the record of their own reveals. We found it in our own audit and closed it. You can not yet read the log yourself: we can produce it on request, and there is no self-serve view.

Tenant isolation

Every read and write the application makes names the signed-in account's agency. Our server connects with a service-role credential that bypasses row-level security, so on our own code path the database's per-tenant policies are not what stops a mis-scoped query. Scoping is applied by the application. The policies do constrain any signed-in or anonymous connection made directly to the database: the anonymous role holds nothing on Visits tables.

What does not depend on our code being right is the encryption above. HeyDiane Visits also runs on its own database project, separate from our AI-receptionist product, and in a deployed environment the application refuses to connect Visits to the receptionist's project.

A case note that has been submitted or filed cannot be changed in the database by any role. It can move from submitted to filed and nothing else, apart from a key-rotation re-seal. Every saved version of a note is captured in a revision history that is itself append-only.

Where the database is

The Visits database project is in Supabase's Montréal region, ca-central-1, as read from Supabase's API on 2026-09-09. Regions are fixed when a project is created. Do not read that as a residency claim for anything beyond that database: our application functions run in Montréal, but the content-delivery edge is global, and the regions of our other providers are not established in our records. If your review needs residency in writing, ask; we will answer in a contract, not on a web page.

Retention, export and deletion

There is no automatic retention schedule for Visits records yet. How long an agency's records live is a term to agree with that agency in contract. There is no self-serve export or deletion either: both are done by us, by hand, on request. We can delete what we hold. A record you have exported into your own systems, or into an email or a printed care plan, is governed by your retention policy, not ours.

What we have not done yet

• A third-party penetration test. None has been done; when one is, we will publish its date and scope here.
• A tested restore. Both databases run on managed backups, and we have not yet restored one to prove it works. Sealed data is recoverable only if a database backup and the master key both survive.
• A self-serve view of the reveal log, a self-serve export, and a retention schedule.
• Any compliance certification, as above.

Questions, a data-processing agreement, or a list of the providers that touch Visits data? Ask. Our privacy policy names the providers we use.