Trust
Security and data handling
Standby Health holds patient contact details, so the design starts from what we refuse to put in a text message. Here is how the system works today.
What we send, and what we leave out
- A patient notification names your clinic and carries a single-use link. It contains no patient name, no procedure, and no reason for the visit.
- Those links use opaque tokens. No patient information is encoded in the URL or in any token we issue.
- Before a patient is added to your list, they confirm their date of birth against what your staff entered. After five failed attempts the link locks.
Where the data lives
- Canadian clinic data is stored in AWS ca-central-1. United States clinic data is stored in us-east-1. Neither crosses the border.
- Data is encrypted at rest with AWS KMS and in transit with TLS.
Who can see what
- A clinic only ever sees its own patients. Which clinic you are is taken from your signed session, never from the request itself.
- Staff accounts require a password and an authenticator app. Two-factor login is mandatory, not optional.
What gets written down
- Every staff action is recorded with a timestamp and the account that performed it.
- Every step of the patient flow is recorded too: notification sent, link opened, request made, confirmed or denied, expired.
- Patient details never appear in application logs. Diagnostics reference records by identifier only.
Where we are with compliance
Standby Health is built to meet HIPAA in the United States and PHIPA and PIPEDA in Canada. In practice that means the things above: data residency, encryption, access control, an audit record of every action, and no more information in a message than it strictly needs.
We are pre-launch. Our security review and provider agreements are being completed before the first clinic goes live, and we would rather tell you that than show you a badge. If you need specifics for your own compliance file, ask and we will answer precisely.