Staff and roles

Adding staff

An Owner or Administrator invites staff by email and assigns them a role in this organization. The invitee accepts and gets a membership. Removing a member ends their access to the organization's operational data.

The default roles

Each role ships with a fixed permission set for now (a per-organization permission editor is planned, not built):

Role	Scope
Owner	Everything, including staff, billing, and the organization profile
Administrator	Like Owner, for day-to-day operations
Doctor	Their own schedule, appointments, and — via patient consent — their patients' records
Secretary	Scheduling and appointments; patient contact/scheduling info
Nurse	Patient list (contact/scheduling info); records vitals during a visit

Permissions are action-level per data domain — for example read/write patients, read/write appointments, manage staff, manage billing, manage services.

The consent boundary

Business permissions govern operational data — scheduling, billing, patient contact and logistics. They do not grant clinical access.

• "Read patients" for a Secretary or Nurse means contact and scheduling information, not clinical history.
• Seeing a patient's notes, results, or diagnoses always requires the treating doctor's own access grant from that patient.

A staff member's business role is never a backdoor around patient consent.

Super-admin is different

Platform super-admins are not an organization role. They're a platform-wide support function and are not part of this scoping model — and being a super-admin does not grant clinical access to patient records.