Security

PAWTAL holds a hospital's operating record, and, when the hospital uses it as the medical record, the chart. The controls below are the ones the product enforces. This page is a summary for hospitals and the people evaluating them. It is not an internal specification. A hospital or partner doing security diligence can ask for more detail at support@pawtal.com.

1. Our approach

Where a protection can live in the software, we put it there. The clearest example is hospital separation: access rules are enforced in the database for the signed-in user, rather than only in a page that someone might forget to check. The Privacy Policy describes what we collect and who receives it.

2. Hospital isolation

Each hospital is a tenant. Rows that belong to a hospital are tied to that hospital, and the database rejects a signed-in request that asks for another hospital's rows. Inside a hospital, what a person can open follows the role the hospital assigned. A hospital that uses PAWTAL beside its existing practice-management system keeps that system as the source of the chart. PAWTAL does not copy the chart across hospitals.

3. Authentication

Hospital accounts are provisioned by the hospital. The public site does not hand out a clinical login. Passwords are hashed by the authentication provider. A person who suspects unauthorized access should change the password and email support@pawtal.com.

4. Encryption

• Traffic between the browser and PAWTAL is encrypted with TLS.
• Stored data is encrypted at rest with AES-256 by the database host (Supabase on Amazon Web Services).
• Credentials we store for a connected system — a practice-management key, a messaging secret, an OAuth refresh token — are encrypted with AES-256-GCM before they are written. Those keys are not sent to the browser.

5. What we will not do

• We do not sell hospital, staff, client, or patient information.
• We do not use it for advertising.
• We do not use it to train PAWTAL models. AiVA requests go to OpenAI under an API agreement that does not allow that content to be used to train their models.
• We do not send SMS or email except for a program the hospital has turned on, a message a person sends through the product, or a notification the recipient has opted into. Staff SMS categories are off until that person turns them on. Opt-out is described in the Privacy Policy and at /sms-opt-in.
• We do not send those messages from a staff member's personal mailbox. They go out through the messaging providers named in the Privacy Policy.

6. Logging

Sign-in is handled by the authentication provider. Notification delivery is logged with the event, the channel, and whether it was delivered, so a hospital can see what was sent and so we can avoid sending the same message twice. We do not use those logs for advertising.

7. How changes ship

Changes are reviewed before they are promoted to the hospital production application. Database changes that remove or rewrite data are applied as their own step. A page deploy does not apply them.

8. Your control

• The hospital decides who has an account and what that account can open.
• A staff member can turn notification categories off, or reply STOP to opt out of staff SMS.
• A request to delete personal information goes to support@pawtal.com. Because the hospital owns the practice record, we confirm a request that would erase hospital data with the hospital before removing it.

9. Reporting a vulnerability

If you believe you have found a security vulnerability, email support@pawtal.com with enough detail to reproduce it. We will acknowledge the report and tell you when we have a fix. We will not pursue legal action against good-faith research that avoids privacy violations, data destruction, and interruption of the service. If you suspect your own account has been compromised, use the same address.