The whole system on one page

Grace opens the family portal and types: “Did Mum eat dinner? And is the doctor worried about her blood pressure?”

The reply comes back in seconds. Mum had most of her dinner and enjoyed the soup. The second question, it says, is one for the care team, and a nurse will call Grace tomorrow morning.

Grace doesn’t see what happened behind that answer. The agent was never able to read the blood-pressure notes in the first place.

That one exchange contains most of the architecture. This post shows the rest on one page.

The one-sentence architecture

The model drafts. Rules decide. People confirm.

A language model is very good at writing, summarising and translating, but it isn’t a reliable place to keep a decision. So in this design, the decisions live elsewhere:

Consent, entitlement and disclosure (who may see what) are code.
Claim rules and pricing are code.
Roster rules (24/7 registered nurse cover, skill mix, award rules) are a solver plus an independent checker.
Alert triage for Night Watch is deterministic.

The model writes the words. It never makes the decision.

Seven principles

The model drafts, deterministic services decide, people confirm. The decision logic is rules and code, not prompts.
The confirmed record is a hard boundary. Drafts never go into the care record. Billing and Family Communication only read confirmed entries.
Agents hold no data roles. Resident data is reached through a gateway, with one route and one permission for each consumer.
Identity is proven, not chosen. Every agent has its own least-privilege identity, and every human decision records who made it.
One data plane per country. Identifiable data stays in Australia East. A regional plane only ever receives de-identified metrics.
Safety-critical alerting is local. Night Watch runs on site and doesn’t depend on the cloud.
The simpler service wins unless a written decision record shows why something newer fits better.

The picture

Boxes are capabilities, not servers. Dashed boxes are designs that haven’t been built yet.

flowchart TB
    subgraph People
        STAFF["Staff<br/>caregivers, RNs, managers, billing"]
        FAM["Families and supporters"]
    end
    FD["Secure front door<br/>Front Door + WAF, staff and family sign-in"]
    subgraph Agents["Cloud agents · Australia East"]
        CR["Care Record"]
        BI["Billing"]
        SP["Shift Planning"]
        FC["Family Communication"]
    end
    subgraph Support["What the agents lean on"]
        AI["AI runtime<br/>Foundry, regional model"]
        DET["Rules, not prompts<br/>consent, entitlement,<br/>claim rules, roster solver"]
        GW["Care Record Gateway"]
    end
    FHIR[("FHIR care record<br/>synthetic data")]
    NW["Night Watch<br/>on site, local alerting"]
    REG[("Regional view<br/>de-identified only")]

    STAFF --> FD
    FAM --> FD
    FD --> Agents
    Agents --> AI
    Agents --> DET
    Agents --> GW --> FHIR
    NW -- "alerts to handsets" --> STAFF
    NW -. "pseudonymised events" .-> Agents
    FHIR -. "de-identified export" .-> REG

    classDef target stroke-dasharray: 5 5
    class BI,SP,NW,REG target

Two decisions worth unpacking

1. Where does a decision live?

Option	What it means	Verdict
Let the model decide, with guardrails	The prompt says “only share routine information”; content filters catch mistakes	✗ Correct most of the time, which isn’t good enough for disclosure or claims
Rules decide, the model writes	Deterministic code works out what’s allowed; the model only phrases the answer	✓ Chosen

In Grace’s case, a deterministic entitlement service checked who she is, which resident she’s linked to and which kinds of information she may see. The model only got to write the reply after that check.

2. How does an agent reach resident data?

Option	Risk	Verdict
Give each agent a role on the FHIR service	A prompt-injected tool call can read anything the role allows	✗
One shared service account	One compromise exposes everything, and the audit trail can’t tell who did what	✗
A gateway with one route and one permission per consumer	Each agent can only call its own narrow route	✓ Chosen

The Family Communication agent holds a permission called CareRecord.Read.Shareable. It doesn’t hold a FHIR role at all. Even if someone tricked the model into asking for blood-pressure notes, the gateway route it can call simply doesn’t return them.

Agents don’t talk to each other

You might expect five agents to call each other directly. They don’t. They share facts, not permissions:

Care Record is the source of facts. Billing and Family Communication only see entries a caregiver has confirmed.
Night Watch events become draft incident notes for an RN to review, and they put a hold on routine family messages, so Grace doesn’t get a cheerful “quiet night” update after a fall.
Shift Planning publishes the approved roster, which tells Night Watch whose handset to alert.

This means one agent can never gain another agent’s data rights by asking it for something.

What’s built, and what isn’t

Building block	Status
Landing zone (hub and spoke, default-deny egress, private DNS)	As-built
Staff identity and family identity (family accounts hosted in Australia)	As-built
Secure front door (Front Door Premium with WAF, private origins)	As-built
AI runtime (private Foundry project, regional model deployment, Prompt Shields)	As-built
FHIR record behind the Care Record Gateway	As-built with synthetic data
Family Communication	Demo
Care Record	Partial: a synthetic slice, not end to end
Billing, Shift Planning, Night Watch	Target
Facility-level supervision and inter-agent events	Not designed yet
Regional de-identified analytics	Not designed yet

Next: three boundaries (facility, country and region) and what’s allowed to cross each one.