Security and data handling

Each hospital has its own roles. Start from the default roles or build your own from a fixed list of permissions, then give each person the role their job needs.

The server checks the permission on every protected request, so hiding a button is never the only control. If a role does not grant an action, the request is refused.

Every request is tied to one hospital. Records are read and written through shared checks that always limit the query to that hospital, and a person must hold an active membership at a hospital before working there.

Staff who work at more than one hospital sign in once and choose where they are working. Automated tests in our build pipeline check that staff at one hospital cannot reach another hospital’s records.

When your front desk finds that a patient already has a careOS 360 record from another hospital, the record joins your hospital only after the patient confirms a one-time code sent to their phone.

The codes expire after a few minutes and stop working after repeated wrong attempts. Each step, from sending the code to linking the patient, is logged.

Sensitive actions are recorded with who did them, when, and from which IP address and browser. They include:

• sign-ins, including failed attempts
• changes to roles, permissions and staff access
• refunds, cancelled bills and other corrections to money already recorded
• opening and linking patient records

careOS 360 has no screen or interface for editing or deleting these entries.

Passwords are stored only as one-way bcrypt hashes, never as readable text. Repeated sign-in attempts from the same address are slowed down by rate limiting.

After sign-in the browser holds a short-lived access token. The longer-lived session token is kept in a cookie that page scripts cannot read and that is never sent with requests from other websites.

All traffic between your browser and careOS 360 is encrypted with HTTPS. Requests made over plain HTTP are redirected to HTTPS.

We use an error-monitoring service to find and fix faults. Before a report is sent, patient details, contact details, passwords and tokens, and clinical notes are removed from it.

The server reports only unexpected errors, and we do not record people’s screens or sessions.

The demo, contact and registration forms on this site are rate-limited and carry a hidden field that catches automated spam.

Links in our emails, such as email verification and account setup, use long random tokens. We store only a one-way hash of each token, the links expire, and the verification and setup links work once.

The privacy notice sets out what the forms collect and why.

If your hospital has a security questionnaire, or wants to see these controls in the product, write to us through our contact page or ask for a walkthrough on your demo.