Role-Based Access Policy (practice template)

Role-Based Access Policy — practice template

Unlike the rest of the pack, this document is a template your practice adopts as its own policy — SideClick (Pty) Ltd provides it as a starting point and the software facts it states, but the adopted policy is the practice's document, completed and reviewed by the practice.

Health-privacy frameworks expect a practice that runs shared clinical software to be able to point at a written statement of who can access which patient information and why. Under HIPAA this is the minimum-necessary implementation specification (45 CFR 164.514(d)(2) — identify the classes of persons who need access, the categories of information they need, and any conditions on that access; where a role needs whole-record access, say so explicitly and justify it). Under the Australian scheme the same expectation appears as role-level access in RACGP Standards C6.4 and the OAIC's need-to-know guidance; UK (HCPC standard 10.3) and South African (POPIA s 19, HPCSA guidance) regimes phrase it as restricting records to appropriate or authorised personnel. None of these prescribes a particular software architecture — they require this document: an explicit, justified, adopted policy, backed by real controls.

1. Adoption

Field	Value
Practice	[Practice name]
Adopted by (name, role)	[Adopted by]
Date adopted	[Adoption date]
Next review due	[Review date — at least annually and on any role change]

By adopting this policy the practice states that the role assignments below reflect how it actually staffs its clinic, and commits to reviewing them whenever staffing or duties change.

2. Roles and access

SideClick enforces access by role: every staff member signs in with their own account, every account holds one or more roles, and every read or write of clinical data passes a role-permission check inside the application. The roles the software ships, what they can access, and this practice's justification for each:

Role	Access to patient information	Justification
Practitioner (clinical)	Full clinical record: patient demographics, session notes (read and write), encounters, scheduling, consent and data-subject-request tooling. Cannot delete patient records.	Treatment. Clinicians involved in care need the whole record as needed for safe, continuous treatment — see §3.
Admin (practice management)	Patient demographics (read/write/delete), billing, reports, scheduling, consent records (read), data-subject requests. No access to clinical session notes.	Practice operations: billing, reporting, records administration, and privacy-request handling require patient identity and financial data, not clinical narrative.
Receptionist (front desk)	Patient demographics (read, and write for intake) and scheduling. No clinical notes, no deletion, no billing.	Reception needs to identify patients, register arrivals, and manage the diary — nothing more.
Auditor	Consent logs and the audit trail only. No patient clinical or demographic records.	Independent review of the practice's own compliance evidence without exposing care records.
Superadmin (practice owner/principal)	Everything above, plus user and role management.	Ultimate custodian of the practice's records and of this policy; creates accounts and assigns the roles this document describes.
Patient (portal)	Their own portal surface: booking only.	Patients act on their own record through the invited portal, never on the practice's wider data.

Each role's access is enforced in software exactly as stated: the permission grants behind this table ship with the product and are checked on every operation.

3. Whole-record access for treatment roles — explicit statement

This practice grants its treatment-involved roles (Practitioner, and Superadmin where the principal also treats) access to the entire clinical record of the practice's patients, as needed for treatment, without case-by-case review.

Justification: this is a single-clinic deployment in which the clinical team shares responsibility for continuity of care — cover for absence, multidisciplinary input, and safe handover all require that a treating clinician can read the full history of the patient in front of them. Access remains conditioned on professional involvement: opening records of patients one is not professionally involved with, out of curiosity or for any non-clinical purpose, is prohibited by this policy, is a conduct breach under the practitioner codes that bind clinical staff (for example AHPRA shared Code of conduct s 3.3; HCPC standard 10.3), and is detectable in the audit trail (§4).

4. The controls behind this policy

• Unique sign-ins. Every staff member has their own account and passphrase; accounts are never shared. Role assignment happens at account level and is visible to the practice's superadmin.
• Tamper-evident audit trail. Note and patient-record accesses, clinical writes, exports, sign-ins, administrative changes and configuration changes are recorded in a hash-chained audit log inside the encrypted database. Note reads are recorded on the desktop application; reads on enrolled companion phones are not audited. The Audit Console can export a signed segment for an auditor or investigator.
• Encryption at rest and in transit. The practice database is encrypted on disk; patient fields carry additional per-patient encryption; sync between the practice's own devices is end-to-end encrypted and the relay operator cannot read it.
• The receptionist wall. The front-desk role structurally cannot read clinical session notes — the software refuses, regardless of what a receptionist clicks.
• Optional own-notes restriction. The practice may additionally enable the setting "Clinicians can only see notes they authored" (Settings → Security, administrator-controlled), which narrows each clinician's view of session notes to notes they authored or signed — on the desktop application, and on the native companion phone app once each enrolled phone's access grant next refreshes; superadmins retain full access, and notes without a recorded author (imports, records synced from another desktop) remain visible. This is a display restriction, not a security boundary: enrolled phones still hold the practice's synced record (as described below), and browser (web) access is not identity-filtered. A practice that enables it should note that choice in its §6 review record, as it narrows the §3 statement for note content.
• Optional own-caseload restriction. The practice may also enable "Clinicians can only see their own caseload" (Settings → Security, administrator-controlled), which narrows a clinician's view on the desktop application to patients they have appointments or session records with, or added themselves — across patient lists and profiles, the calendar and waitlist, care plans, messages, and exports. Front-desk, practice-administration, and practice-owner accounts keep the whole practice list (reception and billing are whole-practice functions). This restriction is applied by the application, not by encryption — every desktop sign-in shares the practice database — and does not extend to enrolled companion phones. It governs patient records; note content is governed by the own-notes setting above (a practice wanting both enables both). A practice that enables it should note the choice in its §6 review record, as it narrows the §3 statement.
• Offboarding. When a staff member leaves, the practice deactivates their account, which also revokes their sessions and any enrolled companion devices. If the practice runs SideClick on more than one independently-registered desktop, offboarding must be run on each installation — account records are per-installation by design (the software's zero-knowledge sync cannot link staff identities across installs on the practice's behalf).
• Companion (phone) devices. A companion device is enrolled only by explicit desktop approval, is bound to a named staff member, and is capped below desktop access (no administration, billing, consent management, exports, or note signing from a phone). Enrolled companions hold the practice's synced clinical record on the device, protected by the device's own screen lock and the app's biometric lock; the practice should treat companion enrollment as granting the staff member clinical-record access and revoke it at offboarding.

5. Conditions and prohibitions

• Access is granted for the practice's lawful clinical and administrative operations only (see the Acceptable Use Policy).
• Staff must not access records of a patient they are not professionally involved with, except where authorised for a legitimate administrative purpose within their role.
• Staff must not export, photograph, or transcribe patient information outside the practice's systems except through the software's export functions, which are audited.
• Credentials must not be shared; suspected compromise must be reported to [Privacy/security contact] immediately.

6. Review

The practice reviews this policy — role assignments, the whole-record statement in §3, and the staff list — at least [annually] and whenever staffing, duties, or the software's access model change. The review and its outcome are recorded at §1.

---

Template version 1.1, published 2026-09-12 by SideClick (Pty) Ltd from the software's actual shipped access-control model. The practice completes the bracketed fields when adopting.