Trust
How your data is handled
Controls we run, described plainly. We do not hold a security certification, and you should be suspicious of a product this young that claims one.
Separation
One hospital cannot see another
Every record belongs to exactly one organization, and that ownership is enforced in the database query rather than in the interface. A request for a record belonging to another hospital returns a not-found response — not a permission error, because confirming that a record exists is itself a disclosure.
Patient identifiers
Encrypted, audited, and never in a log
Encrypted per field
Patient identifiers are encrypted individually with authenticated encryption, not stored as plain columns.
Decryption is audited
Viewing an identifier writes an audit record naming the actor. If that record cannot be written, the view is refused rather than served unlogged.
Never in a log or a URL
Identifiers do not appear in log lines, error reports, or addresses. Records are addressed by opaque identifiers throughout.
No patient data leaves in a message
Email leaves systems we control, lands in previews on lock screens, and is kept by mail hosts indefinitely. So our email has no parameter through which a message body could arrive: a notification names a template and a small set of validated values, and the subject lines are fixed constants.
The same rule applies inside the application — a notification stores a reference to what happened, never a copy of it. This is a property of the interface, not a convention somebody has to remember, which is the only version of such a rule that survives contact with a deadline.
Audit
A trail that cannot be edited
Sensitive actions are recorded with the actor, the organization and the target.
- Append-only at the database level, not merely by convention in the application.
- No free-text field that could absorb patient data into the trail itself.
- Retained against a six-year floor, and the purge command refuses a shorter retention.
- Denied access is recorded too, so an attempt tells you as much as a success.
- Administrator overrides are distinguished from ordinary access rather than blended into it.
Facility data
Nothing about a patient is sent outward
Public government sources, fetched over TLS from official endpoints — no third-party mirrors or scraped intermediates. We retrieve whole published datasets on a schedule, so there is no request that could carry a case detail outward, by accident or otherwise.
Facility data: Centers for Medicare & Medicaid Services; New York State Department of Health. The New York State Department of Health makes no representation, warranty or guarantee relating to the data or analyses derived from these data.
Straight answers
What we do not have
You are going to ask. Here it is before you do.
No third-party security attestation
We hold no independent security certification and make no claim to one. If a current attestation report is a hard gate in your vendor-risk process, we are not there yet and would rather say so in the first email than in the fourth meeting.
No compliance badges
You will not find a health-privacy framework named anywhere on this site, in a badge or in a sentence. Those frameworks describe an obligation and an agreement, not a product feature — and a vendor who prints one on a landing page is telling you something about their rigour. We will discuss our obligations with you directly.
No published penetration test
Automated dependency-vulnerability and accessibility checks gate every release. An independent penetration test is not yet among them.
Contractual terms, by conversation
Anything involving an agreement or a named third party is a commitment rather than a web-page claim, so we handle it directly with you and your counsel rather than asserting it here.
For reviewers
Reviewing us for your hospital?
Send your security questionnaire and we will answer it directly — including the questions where the answer is “not yet”.