Data protection

Most software sold to medical practices is built to hold patient records and then hardened around them. Vesyra was built the other way: it answers a financial question — what does each service line actually earn after the cost of what it consumed — and that question does not require knowing who the patient was.

So the schema has no place to put one. This is not a setting a practice can switch on, and not a policy an engineer has to remember. There is no column, so there is nothing to protect, leak, subpoena or breach.

Names. Dates of birth. Street addresses. Telephone numbers. Email addresses belonging to patients. Social Security or other government numbers. Medical record numbers issued by another system. Health plan or insurance identifiers. Account numbers. Certificate or licence numbers. Vehicle, device or biometric identifiers. Photographs. Web URLs or IP addresses associated with a patient. Clinical notes, diagnoses or treatment narratives.

The application also provides no file upload of any kind, so a scanned chart or an intake form cannot be attached to a record even by someone trying to.

• A practice-assigned reference code. The practice generates it in its own clinical or practice-management system and keeps the mapping on its own side. Vesyra stores the code and cannot resolve it to a person.
• A date. Stored to the day, because margin is reported by month and a coarser date would make the reports wrong.
• A service line — IV therapy, peptides, weight loss, HRT, general medicine — and the amount charged.
• The products drawn, the lot each came from, and the cost of that lot frozen at the moment of the sale.
• Which user rang the sale and which administered it. These are staff, not patients, and they hold accounts.

The application validates the reference code field and rejects values that look like a name or an email address. That is a guard rail against a habit, not a guarantee against a determined misuse: a practice that insists on typing identifying information into a free-text note has put data into Vesyra that Vesyra is not designed to hold, and should tell us so we can remove it.

Everything above is a description of the software. None of it is a legal conclusion, and we will not publish one. In particular we do not claim that Vesyra data is de-identified under any particular standard, that a practice does not need a business associate agreement, or that any regulation does or does not apply to your use of the product.

Those determinations turn on facts about your practice, your other systems and how you use ours. They belong to you and your counsel. What we will do is give them everything they need to make the call: the complete data model, in writing, listing every table and every column, on request to legal@vesyra.app.

If a practice’s counsel concludes that a business associate agreement is appropriate, we will discuss and enter one. We would rather sign an agreement that turns out to be belt-and-braces than argue a practice out of asking for it.

Every table that holds practice data carries the identifier of the practice it belongs to, and every row is protected by a row-level security policy evaluated by the database against the identity of the signed-in user.

The consequence worth stating plainly: a query written incorrectly by us returns nothing rather than returning another practice’s records. Isolation does not depend on application code remembering to add a filter, which is the mechanism that fails in most multi-tenant breaches.

Access is scoped per practice and per role, so a user who works at two locations gets exactly what each of them granted, and administrator rights at one confer nothing at the other.

Application hosting is provided by Vercel and the database and authentication service by Supabase, in the United States. Transactional email is delivered by Resend. These are named, with what each one does, in the privacy notice, and we will notify account administrators before adding a provider that processes practice data.

• TLS in transit; encryption at rest by the database provider.
• No self-service signup. Accounts are created by an administrator and first access is by an invitation link that expires.
• Role-based permissions, enforced in the database rather than only in the interface, so a request that bypasses the interface is still refused.
• Staff access to production data only where required to operate the service or resolve a support request, and logged when it happens.
• Regular encrypted backups, expiring on the schedule in the privacy notice.

If we become aware of unauthorised access to a practice’s data we will notify that practice without undue delay, tell them what we know and what we do not yet know, and say what we are doing about it. We will not wait until the investigation is complete to make the first call. What we commit to on availability and response times is in the service and support policy.

Data protection questions, data model requests, or a business associate agreement discussion: legal@vesyra.app.