How the software is secured

The agreement

We act as a business associate to every customer agency and sign a Business Associate Agreement before any protected health information is stored. The BAA, not this page, governs how PHI is handled; this page describes the controls behind it.

Where the software runs

• AWS, United States. The application and the databases run on Amazon Web Services under our account, inside the AWS shared-responsibility model and AWS's own HIPAA-eligible services.
• One instance and one database per agency. Each customer has its own hostname and its own Postgres database. There is no shared table between agencies, and the browser scopes each agency's login cookies to its own hostname.
• Least-privilege database roles. The application connects with a role that can reach only the tables it owns; a defect or a leaked credential in one product cannot read clinical records held by another.
• TLS everywhere. Every connection — browser, phone app, aggregator API, SFTP — is encrypted in transit; SFTP peers are verified against a pinned host key and never trusted on first sight.

How data is protected

• Encryption at rest for the database and backups, and field-level encryption for the most sensitive values — a caregiver's Social Security number, where a state requires it on the EVV record, is encrypted with a key held outside the database and shown only as its last four digits.
• Secrets are write-only. Aggregator passwords, API keys, SFTP keys and payment credentials can be set and replaced from the settings screens but are never displayed back.
• Automated backups on a schedule, encrypted, with restores tested.
• No PHI on this website. The marketing site, the demo form and the videos carry no patient data; the screenshots you see are a fictional demo agency.

Who can see what

• Roles and access levels. Office staff, caregivers, and patients or their family members each get their own login and see only what their role allows; administrators grant and revoke capabilities per person.
• No self-signup. Every account is created by an administrator's single-use, e-mail-bound invitation.
• An audit log records who changed what and when — visits, times, documents, settings, sends to the state — and the log can be verified for tampering.
• EVV records are write-once. A visit's original device times are never overwritten; a correction is a new record with who made it, when and why, which is also what the state receives.

Sending data to your state

EVV connectors deliver over the transport the aggregator specifies — REST over TLS with the credentials the aggregator issued, or SFTP with a key pair — and every send, every answer and every rejection is kept on the visit. A test-environment account cannot reach a production endpoint and a production account cannot be used for certification tests.

What we will tell you

• Incidents: notification under the BAA's timelines, with what happened, what was affected and what changed.
• Subprocessors: AWS (hosting), Cloudflare (this website), Resend (transactional e-mail), Twilio (telephony clock-in, where used), Stripe (family payments, where used). We will tell you before adding one that touches PHI.
• Questions: [email protected] — a security questionnaire gets a written answer, and anything above can be shown on a screen-share.