Organization boundaries
How workspace identity, roles, and private-file checks shape access in Curenium.
Start with the active workspace
Users can belong to more than one organization. The active organization in the session determines which workspace a request is acting within. Switching workspaces changes that context; it does not grant access to another organization's records by itself.
Application features must check the signed-in user, active organization, and the permission required for the action. An organization ID in a URL or request body is not, on its own, authorization.
Accounts and roles
Review the account types and role-based access used across the platform.
Audit activity
See how administrative and clinical actions are recorded for review.
Private file access
Private storage keys include an organization scope. Before a private file is served, the file-access helper checks that the requester is signed in and that the file belongs to their active organization. Patient-scoped files have an additional patient identity check for patient accounts. Shift-verification images have their own owner and role checks.
Storage is deployment-dependent: private files may use Cloudinary or Cloudflare R2 according to configuration. Public assets, such as organization logos and staff avatars, use a separate path. The choice of provider does not replace access checks.
Review permissions for each workflow and route. Do not assume that a workspace-scoped session, by itself, makes every record or action available to every member of that workspace.
Compliance and assurance
This guide explains product behavior; it is not a certification, legal opinion, or promise of a particular hosting region. For current contractual terms, data-processing arrangements, and security commitments, refer to the organization's approved agreements and the security and compliance pages.