Applications

The applications

Four applications and two supporting services. Each section gives the purpose, the people who use it, how it is built, what data it holds, and what it connects to.

Site Profiles

The national record of radiology facilities. For each of more than 45 sites it holds equipment and machine schedules, staffing FTE by role, contacts, specialty services, performance measures and the digital tools in use, with national and regional dashboards and a map. It also holds the registry of radiologists, MRTs and other members that the member portal is built on, although the profile half of that data now lives in the identity hub.

Used by

Radiology leaders and administrators. Admins, editors (limited to their region) and viewers.

Address

site-profiles.hnzradtools.nz

Shape

One Pages project serving the React app and the server functions under /api, /auth, /v1 and /upload.

Data

Facilities (with satellites), machines and availability, staffing, contacts, specialty services, performance metrics, digital tools; the staff registry; announcements tables (now superseded by the hub); audit log, which also drives the weekly freshness digest.

Scout

A natural-language question box. The question goes to Anthropic's Claude Haiku, which writes a SQL query limited to an allowlist of non-person tables; the results are summarised back in prose. Person tables are excluded by design.

Connects to

Identity hub (binding), email worker (binding), Service Sizing (grains). Serves the portal's internal API and the read-only /v1 API.

My HNZ Radiology

A personal portal for members of the radiology network at hnzradiology.nz. Members manage their profile, specialties and photo, see peers in their region and a national directory, read announcements, and contact a peer. A peer message goes out from the platform with the sender as reply-to, so nobody's address is disclosed until they choose to reply.

Used by

About 320 people: radiologists, MRTs and other members (clinical leads, regional delivery leads, and others). Administration happens in the identity hub.

Address

hnzradiology.nz

Shape

One Pages project. The server functions are a thin backend-for-frontend: almost every request is forwarded to Site Profiles' internal API.

Data

Its own database holds only sessions (hashed) and rate-limit counters. It stores no names or addresses and holds no encryption keys.

Sign-in

Email code, verified against the Site Profiles registry; its own session cookie (4 hours, or 30 days if remembered). Not yet on the hub, because it is on a different domain (R9).

Connects to

Site Profiles only.

Service Sizing

Models senior medical officer (SMO) capacity against demand. The unit of planning is a grain: a facility, or a group of facilities that share SMO resource. For each grain it combines reporting volumes, multidisciplinary meetings, non-clinical activity and modality time standards to compute the FTE required, and compares it with the effective FTE available.

Used by

Workforce planners and radiology leaders. Admins, editors (by grant) and viewers.

Addresses

UI at service-sizing.hnzradtools.nz; API on a workers.dev hostname (R8).

Shape

A static Next.js frontend on Pages, and a TypeScript Worker API. It has no sign-in of its own: every API call needs a hub token for the Service Sizing audience.

Data

55 grains and their facilities, staffing snapshots, activities and meetings, reporting and demand volumes, modality time constants, FTE configurations and calculations, forecasts, audit log. CSV uploads kept in R2; Site Profiles responses cached in KV.

Connects to

Reads facilities and staffing from Site Profiles; serves grains to Site Profiles and the hub.

Triage

A vetting reference for radiology referrals. About 2,600 clinical scenarios, organised by section and subheading, each mapped to the recommended modality and a priority (P1 to P5, S1 to S5). People can browse, search by keyword, or paste referral text into AI triage, which finds the closest scenarios.

Used by

Reading is open to anyone with the link. Editing is for admins and editors; reviewers can read drafts and comment. Section leads are recorded per section.

Addresses

UI at triage.hnzradtools.nz; API on a workers.dev hostname (R8).

Shape

React frontend on Pages; TypeScript Worker API built with Hono.

Search

Keyword search matches text in the database. AI triage embeds the pasted text with Workers AI, retrieves candidate scenarios from Vectorize and a SQLite full-text index, and asks Claude Haiku to rerank them. The pasted text is not stored.

Content pipeline

Scenarios were expanded from a year of referral data by an offline pipeline that classified referrals with Claude and consolidated them into new scenarios for editorial review. Only the synthesised scenarios reach the database; see R5 on the source data.

Data

Sections, subheadings, scenarios and comments, abbreviations, leads, audit log, and its own staff accounts until the hub cutover completes. Database exports kept in R2.

Connects to

Verifies hub tokens. No server-side calls to other apps.

Identity hub

Covered in full on Identity hub, roles and permissions and Authentication and security. In brief: a TypeScript Worker at id.hnzradtools.nz with its own D1 database, holding every identity, sign-in, access decision, person profile and announcement, plus the admin screen. It has 12 test suites, the most of any component.

Email worker

The single outbound mail path for Site Profiles and the hub. It has no web address of its own in the intended design; other components call it through a service binding, naming a template and a payload. It holds fourteen templates, from sign-in codes and invitations to peer messages and announcement digests, and sends through Cloudflare Email from hello@hnzradtools.nz or hello@hnzradiology.nz.

Every Monday morning (9am NZST, 10am NZDT) it also runs the stale-profile digest: it reads the Site Profiles database, works out which facility sections have not been updated in 60 days, and emails the regional leads.

The launch page

hnzradtools.nz is a static page that asks the hub whether the visitor is signed in, and shows a card for each app they can use, plus the admin link for owners and admins. It is presentation only: every app enforces its own access.