Chapter 7 — Identity and access foundations

Chapter 7 — Identity and access foundations

Lesson map

Lesson 07 published. Map, example, EX019.

flowchart TD
  N0["Learning outcomes"]
  N1["7.1 Life cycle"]
  N2["7.2 Roles"]
  N3["7.3 Shared accounts"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX019"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["7.1 Life cycle"]
  N2["7.2 Roles"]
  N3["7.3 Shared accounts"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX019"]

[Learning outcomes]
    |
    v
[7.1 Life cycle]
    |
    v
[7.2 Roles]
    |
    v
[7.3 Shared accounts]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX019]

Learning outcomes

You will (1) manage accounts through staff life-cycle events; (2) apply role-based access; (3) handle shared accounts.

7.1 Life cycle

Dental clinics employ many part-time and temporary staff. Priya maps how Riverton creates, changes and removes accounts. New staff receive accounts quickly, but locum dentists and temporary nurses often keep access after their last shift because clinic managers forget to tell IT. She proposes that temporary accounts be created with an end date that disables them automatically, and that managers confirm extensions. This reduces reliance on memory. An end date set at creation means a locum's access lapses even when nobody remembers to tell IT.

7.2 Roles

Priya defines roles for the practice system: receptionist, dental nurse, dentist, hygienist and clinic manager. Each role has the access needed for its tasks. Receptionists can see appointments and contact details but not clinical notes. Dentists can see full records for their patients. She learns that role-based access simplifies governance because reviews check role assignments rather than hundreds of individual permissions, making them faster and more accurate. Mr. Lind notes that keeping clinical notes out of the receptionist role also reduces how many staff could leak them by mistake.

7.3 Shared accounts

Some clinics use a shared reception account so staff can switch quickly. Priya explains that shared accounts make it impossible to know who did what, which matters for patient record audits. She suggests quick user switching with individual accounts and short sign-in using badges. Clinics agree to try it in two sites first. She learns that removing shared accounts requires a usable alternative, or staff will recreate them. Starting with two sites lets the badge sign-in be tested at busy reception desks before all fourteen clinics adopt it.

Worked example

Priya adds automatic end dates for temporary accounts, defines five practice-system roles and pilots individual quick sign-in instead of shared accounts.

Synthetic case. Roles and processes are synthetic.

Errors and limits

End dates can cut off needed access. Badge systems cost money.

Exercises

• EX019 — Temporary fix. How are temporary accounts controlled? Rubric: 3 = created with an end date that disables them automatically;; 2 = expiry;; 1 = vague;; 0 = none.
• EX020 — Receptionist access. What can receptionists not see? Rubric: 3 = clinical notes;; 2 = notes;; 1 = appointments;; 0 = none.
• EX021 — Shared account problem. Why are shared reception accounts a problem? Rubric: 3 = impossible to know who did what;; 2 = accountability;; 1 = vague;; 0 = none.

Synthesis

Identity governance handles temporary staff, role-based access and usable alternatives to shared accounts.

Continue studying — chapter 07 of 30

← Chapter 06 (draft) · Course chapter index · Chapter 08 (draft) →