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 member signs in with their own account, a practice owner (or a clinic owner, for staff) gives each member a role by invitation, and what a role may open is enforced by the keys each person holds — a record is sealed for the people who may open it, and nobody else holds the key. The roles the software ships, what they can access, and this practice's justification for each:

Role	Access to patient information	Justification
Practice owner	Every record made under the practice's number — automatically, without a request or a consent; every opening of a note they did not write is logged. The practice's file is the practice's: its owners keep it under the practice's retention number, and only they decide its Keep or Delete.	The owner holds the practice number and is the custodian of the practice's records and of this policy; continuity of care and supervision require the whole record.
Associate (clinician)	Their own patients' full record: identity details, session notes (read and write), encounters, scheduling, consent and data-subject-request tooling. Other patients only as the software records: a cover by a colleague of the same profession who is a member of this practice, from a date to a date; a change of treating clinician made by a practice owner or by the patient's treating clinician; a copy sent to them by a clinician of another profession on the patient's recorded consent — the entries as they stood when sent, read-only, with nothing written afterwards reaching them; or a handover from another practice. Holds their own copy of what they wrote, which becomes a copy of their own to keep when they leave (§4, Offboarding); while they are a member, the file is the practice's.	Treatment. A clinician needs the whole record of the patients they treat; access to anyone else's patients is recorded by the software, never a default.
Assistant	Only the patients their supervising clinician assigns; writes entries that wait for the clinician's co-signature; keeps no copy.	Works under one named clinician's supervision; sees exactly what that clinician assigns.
Front desk	Identity details and the money layer (bookings, invoices, payments) of the practices they serve. No clinical notes; keeps no copy.	Reception needs to identify patients, register arrivals, manage the diary and take payments — nothing more.
Bookkeeper	The money layer by file number only. No identity details, no clinical notes; keeps no copy.	Accounts need amounts and file numbers, not who the patient is or what was said.
Clinic owner	The business side of every practice in the clinic. Never a clinical record.	Runs the clinic as a business; clinical records belong to each practice.
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: what a role may open is decided by the keys the software gives that person, and the rules behind this table ship with the product.

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

This practice grants its practice owners, and each associate for the patients they treat, access to the entire clinical record of those patients, as needed for treatment, without case-by-case review.

Justification: the practice's clinical team shares responsibility for continuity of care — cover for absence, multidisciplinary input, a change of treating clinician and safe handover all require that a treating clinician can read the full history of the patient in front of them, and each of those is recorded by the software (a cover, a copy sent on the patient's consent, a change of treating clinician, a handover). 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 member has their own account — an email address, a password that never leaves their devices, and a recovery code only they hold; accounts are never shared. Roles are given by invitation from a practice owner (or a clinic owner, for staff) and are visible to them.
• 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 companion phones are not audited. The Audit Console can export a signed segment for an external reviewer 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 operator of the sync server cannot read it.
• The front-desk wall. The front desk and the bookkeeper structurally cannot read clinical session notes — they never hold the key, so the software cannot show a note whatever is clicked.
• Optional own-notes restriction. The practice may additionally enable the setting "Clinicians can only see notes they authored" (Settings → Security, controlled by a practice owner), 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 the phone's access next refreshes; practice owners 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: companion phones still hold the records their person may open (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, controlled by a practice owner), 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 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, and does not extend to 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 member leaves, a practice owner removes them from the practice (or they leave it themselves). A membership may also be given an end date — in the invitation, or by a practice owner later — for a locum covering a leave or anyone whose work in the practice ends on a known day; on that date the membership ends on every device, with or without a connection, exactly as a removal. The practice's keys are rotated at that moment, so nothing written afterwards reaches the leaver on any of their devices, and the keys to the practice's records they may no longer hold are deleted on their own devices. What a leaving clinician keeps — their own entries, and the identity details and bookings of the patients they treated — is set by the practice's "members keep their own copy" setting, which the practice owner may switch off; assistants, the front desk and bookkeepers keep nothing. The copy a leaver keeps is theirs, under their own retention number; the practice's file stays the practice's, under the practice's number. Devices belong to the person, not the practice: only a person can remove their own devices, and the practice does not need to — removal from the practice ends the practice's access on every device at once.
• Companion (phone) devices. A phone signs in with its person's own account and is approved from another of their devices (or with their recovery code or authenticator), and it is capped below desktop access (no administration, billing, consent management, exports, or note signing from a phone). A phone holds the records its person may open, protected by the phone's own lock and the app's biometric gate on every start. The practice should treat a member's phone as holding whatever that member's role may open; removal from the practice (above) takes the practice's records off it, and only the person can Remove or Mark as lost a phone of theirs.

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.4, published 2026-10-20 by SideClick (Pty) Ltd from the software's actual shipped access-control model. The practice completes the bracketed fields when adopting.