Health New Zealand | Te Whatu Ora
Radiology Tools Architecture and handover

Overview

HNZ Radiology Tools: architecture and handover

HNZ Radiology Tools is a small family of web applications used by the national radiology network: facility profiles, workforce sizing, an imaging triage reference, and a portal for radiology staff. All of it runs in one Cloudflare account, is built from one GitHub repository, and shares one sign-in through an identity hub.

This pack is for Health New Zealand Digital's architects and senior technical staff who are considering taking on governance of the platform, management of the Cloudflare account, and supervision of development and releases. It aims to answer, in one sitting, what exists, how it fits together, why it was built this way, and what is still open.

4 + 1applications, plus the identity hub they share
313people with one identity across the apps
45+radiology facilities profiled
~2,600clinical triage scenarios
US$10per month, total Cloudflare spend
0servers, VMs or containers to patch

How to read this pack

The pages describe the platform as it runs in production once the current promotion completes. The identity hub and the latest application changes are live on the preview environment. Reaching the same state in production follows the cutover run sheet (docs/production-cutover-runsheet.md): a hub hostname and secrets, a hub production branch, pointing each app at the production hub, and opening the hub's sign-in and admin pages, which production deliberately refuses until then. Where something still differs from that end state, the page says so. Gaps that remain after promotion are not hidden: every one is in the risk register with a severity, a status and a fix.

MarkerMeaning
In productionRunning for users today, or on completion of the current promotion.
PlannedDesigned and agreed, not yet built.
Partly fixedA known weakness with some mitigation in place.
OpenA known weakness with no mitigation yet.

The system on one page

WHO USES IT Radiology staff admins, editors, viewers Radiology members radiologists, MRTs, others Referrers public triage search ONE CLOUDFLARE ACCOUNT Edge: DNS, TLS, DDoS, caching APPLICATIONS (EACH WITH ITS OWN DATABASE) portal API, relayed to the hub Site Profiles facilities, equipment, staffing, registry My HNZ Radiology member portal Service Sizing SMO workforce demand vs capacity Triage scenario to modality and priority facilities and staffing data signed 15-minute token, one per app Identity hub (hnz-identity) email sign-in, sessions, access tiers and grants, person profiles (encrypted), announcements, audit Email worker hnz-email Cloudflare Email Also in the account: Cloudflare Images (photos), Workers AI and Vectorize (triage search), a weekly scheduled digest, and a full, separate preview copy of every component OUTSIDE CLOUDFLARE Anthropic API triage reranking, Site Profiles query Staff inboxes codes, invites, digests GitHub Actions deploy all code
Everything runs inside one Cloudflare account. Site Profiles, Service Sizing and Triage trust a short-lived token signed by the identity hub, so none of them needs to handle sign-in itself (their older password logins are retired once the hub is authoritative). Service Sizing reads facilities and staffing from Site Profiles. My HNZ Radiology is a thin portal: its profile and announcement data lives in the hub, and today it reaches it through Site Profiles, which relays each call. The only traffic that leaves Cloudflare is email delivery, calls to the Anthropic API (planned to move to Health NZ's contained AI endpoints), and triage's password-reset mail through Resend.

The components

What handover involves

Handover moves three things from one person to Health New Zealand Digital:

  1. The code. Transfer the GitHub repository from a personal account into a Health NZ organisation, where branch protection, required reviews and a production approval gate become available. See Repository and pipelines.
  2. The platform. Make Health NZ the owner of the Cloudflare account, with named administrators, enforced two-factor sign-in, and the secrets held in a shared vault. See Operations, cost and handover.
  3. The release decision. Promotion to production already runs through one GitHub Actions workflow. Handover puts a Health NZ reviewer in front of that button.
The first win: sign in with Entra ID

Today people sign in with a six-digit code sent to their email. Because every app already trusts the identity hub, adding Microsoft Entra ID is a change to the hub alone: the hub would accept an Entra sign-in and issue exactly the same token it issues now, and no application would change. The identity data was built for this, with room for several verified addresses per person and a reserved Entra object ID. See Authentication and security.

The short version for decision-makers

What is in good shape

  • No servers, operating systems, networks or database engines to run or patch.
  • Production and preview have separate databases, Workers and encryption keys (the exceptions are in R4, R13 and R21).
  • Staff personal data in the hub and the staff registry is encrypted at rest and looked up through keyed blind indexes. Older user tables still awaiting retirement are the exception (R14).
  • One sign-in and one access model across the apps, administered in one place, with an audit trail.
  • Every change reaches production through a scripted GitHub Actions path.

What needs Health NZ's attention

  • The whole platform currently depends on one person: one GitHub account, one workstation's secrets.
  • No branch protection or release approval is possible on the current GitHub plan.
  • Two items need prompt remediation, set out as critical and high in the risk register.
  • Automated testing is thin: CI runs type checks only.
  • AI calls go directly to Anthropic rather than through Health NZ's contained endpoints.