Platform
Identity hub, roles and permissions
The identity hub is the single place where people exist, where their access is decided, and where every access change is recorded. It brings the apps' separate user tables together into one identity per person, with one vocabulary for access across all apps. The old tables and password sign-ins stay in place as a fallback until the last stages of the cutover retire them.
Counts are the same in production and preview, from the identity import (production cutover run sheet, 22 September 2026).
What the hub holds
Tiers: how much of an app you may do
Every app's permission checks reduce to three questions: may this person administer it, change it, or only look? So there is one vocabulary, stored once, and each app displays its own familiar word.
| Tier | May | Site Profiles | Triage | Service Sizing | My HNZ Radiology |
|---|---|---|---|---|---|
| Owner | Admin in every app, including granting and removing owner. A flag on the person, not per app. Screens gated by a grant (the staff registry) still need that grant. | Admin everywhere | |||
| admin | Full control of one app, including granting access to that app. | Admin | Admin | Admin | Admin |
| contributor | Change the things the app is about. | Editor | Editor | Editor | Editor |
| viewer | Read only (Triage reviewers can also comment). | Viewer | Reviewer | Viewer | n/a |
| member | Marks a portal member. Portal sign-in itself still checks the Site Profiles registry (R9). | n/a | n/a | n/a | Member |
Grants: specific capabilities
A tier says how much of an app someone may do. A grant is one specific capability or scope. There are exactly five kinds:
| Grant | Belongs to | What it does |
|---|---|---|
service_sizing:edit | Service Sizing | Makes the person a Service Sizing Editor. Writes are allowed to admins or holders of this grant. |
service_sizing:view | Service Sizing | Makes the person a Service Sizing Viewer (read only). |
radiology_registry:manage | My HNZ Radiology | Makes the person a portal Admin. The staff registry screens in Site Profiles require Site Profiles admin and this grant, because they expose personal data. |
broadcasts:send | My HNZ Radiology | Makes the person a portal Editor, which lets them write and publish announcements. |
region:member with scope region:<id> | Site Profiles | Limits a Site Profiles editor to facilities in that region (Northern, Te Manawa Taki, Central, Te Waipounamu). An editor may hold several. |
For Service Sizing Editor and Viewer, and for every My HNZ Radiology tier, the hub works the tier out from the grants the person holds. For My HNZ Radiology, a person with neither portal grant but with the portal member flag set is a Member. Site Profiles and Triage tiers are set directly. Service Sizing Admin is the exception: no grant produces it, it was set by the identity import, and a later Service Sizing grant change recalculates the tier and demotes that admin to Editor (R27).
Who may change what
These rules are enforced by the hub's API, not only hidden in the screen. The admin screen hides what someone cannot do, and the API refuses it regardless.
| # | Rule | Effect |
|---|---|---|
| 1 | No self-service access | Nobody can change their own access or grants. (An owner can give up their own owner flag.) |
| 2 | Admins are scoped | An app admin can change access to that app only. A Triage admin cannot touch Site Profiles access. |
| 3 | Grant ceiling | An admin can grant up to admin in their own app, never owner. |
| 4 | Owners are protected | Only an owner can make or remove an owner, and the last owner cannot be removed. |
| 5 | Grants follow their app | A grant can be given by an owner or by an admin of the app it belongs to. Region scopes need Site Profiles admin. |
| 6 | Deactivation needs full cover | Deactivating a person needs an owner, or someone who is admin of every app the person holds. Owners cannot be deactivated, and nobody can deactivate themselves. Deactivation ends all their sessions immediately. |
| 7 | Reasons are recorded | The first grant of Site Profiles or Service Sizing access requires a written reason, stored with the access row. |
| 8 | Removing access removes its grants | Taking away someone's app access also deletes that app's grants, so nothing is left behind. |
The admin screen
Administrators use one screen at id.hnzradtools.nz/admin, reached from the launch page by anyone who is an owner or an admin of any app. It has five views:
People
Everyone, grouped by tier, with a tab per app and region sub-tabs. Opening a person shows a card with their addresses, access in each app, grants, roles, specialties, service area, portal status and recent activity.
Add person
Create an identity from an email address and name, with starting access in each app. Duplicate addresses are refused. The person then signs in with a code; their address is marked verified the first time.
Announcements
Write, preview, publish, unpublish and archive announcements for the member portal, with images and targeting, and send the email digest. Available to portal Editors and Admins.
Photos
Approve or reject profile photos uploaded by portal members before they appear in the directory.
Activity
The audit log in plain sentences: who changed whose access, when, and why. Filterable by person.
Actions, permissions and audit
| Action | Who may | Audited |
|---|---|---|
| Add a person with starting access | Owner, or any app admin (each tier checked) | Yes |
| Set or remove an app tier | Owner, or that app's admin | Yes |
| Add or remove a grant or region | Owner, or admin of the grant's app | Yes |
| Edit the reason for access | Owner, or that app's admin | Yes |
| Make or remove an owner | Owner only | Yes |
| Deactivate or reactivate | See rule 6 | Yes |
| Portal membership, directory visibility, specialties, service area, photo approval, invitations | Owner, or My HNZ Radiology admin | Yes |
| Leadership roles and role note | Owner, or any app admin | Yes too broad, R12 |
| View people, their addresses and the activity log | Owner, or any app admin | Read too broad, R12 |
| Write, publish and email announcements | Owner, portal Admin or Editor | Not yet, R12 |
Common tasks
Give a regional editor access to Site Profiles
- People, find or add the person.
- Site Profiles: set Editor, with a reason.
- Add the region grant for their region.
- The change applies when their app token next renews (within 15 minutes), or at once if they sign in again.
Let someone model workforce
- Open their card.
- Add
service_sizing:edit(or:viewfor read only), with a reason. - Service Sizing now shows them as Editor.
Someone leaves
- Deactivate them. All hub sessions end immediately.
- Any app token already issued expires within 15 minutes.
- Until the cutover retires the old sign-ins, also deactivate their Site Profiles and Triage user accounts, which can still issue tokens (R10).
- Remove them from the registry in Site Profiles; portal access is governed there today (R9).
Invite a radiologist to the portal
- Make sure they have a registry row in Site Profiles; portal sign-in checks it (R9).
- Set portal membership on their card and send an invitation. The email points them to
hnzradiology.nz. - They sign in there with an email code.
What the audit log records
Recorded: sign-in codes issued, throttled, failed, locked and redeemed, and sign-in attempts for unknown addresses, with the IP address; every access, grant, owner, activation, role, visibility, specialty, service-area and membership change; invitations; photo decisions; and profile edits and photo removals made by members in the portal. Admin actions record the actor and the subject. Sign-in events record the person where known, and the IP.
Not yet recorded: sign-out, token renewal, a code accepted again within the 60-second replay window, and announcement authoring, publishing and sending (R12). The log is append-only by convention: nothing in the code updates or deletes it, but the database does not prevent it.
Recovery and bootstrap
- Lockout protection. The last owner cannot be removed, nobody can remove their own access, and owners cannot be deactivated.
- Lost mailbox. The model supports several addresses per person. Adding a second address from the admin screen is not built yet (R23).
- Break-glass. Until the older password sign-ins are retired, they remain the fallback. After that, a documented break-glass path is planned. Creating the first owner, or recovering if every owner is lost, is a direct database write today (R23).