Every request passesthe samesix checks.

The six layers · 1

The only way in.

A server-rendered application covering the whole clinical and administrative surface, sitting behind a reverse proxy that terminates TLS. It is the only tier anything outside can reach.

Underneath: Next.js 16 · React 19 · TLS 1.2 and 1.3 · Reverse proxy.

The six layers · 2

What you may see.

Every route names the permission it requires. Before a query reaches a domain module it has already been cut down to the caller's branch and role, so there is no path where a general login stands in for authorisation.

Underneath: Permission per route · Branch scoping · Least privilege · Separation of duties.

The six layers · 3

Each domain on its own.

Each clinical or administrative domain is its own module, owning its own services, rules and screens. A module never reaches into another module's tables, which keeps a fault in one from becoming a fault in all of them, and lets new domains be added without disturbing what is already running.

Underneath: NestJS 11 · Node.js 24 · No cross-module reads.

The six layers · 4

Modules talk by events.

An order placed, a result verified, a charge raised: these travel as durable events rather than direct calls. Dashboards and projections stay consistent without one module being able to stall another.

Underneath: NATS JetStream · Durable consumers · Transactional outbox · Event contracts.

The six layers · 5

One record, kept inside.

One relational record of truth behind a typed data layer, reachable only from the application tier. A patient moving from emergency to intensive care to discharge stays on a single continuous encounter.

Underneath: PostgreSQL 16 · Prisma ORM · Reachable only from the app tier.

The six layers · 6

Every action written down.

Activity is recorded append-only, so history is added to and never quietly rewritten. Sensitive records, medico-legal cases among them, carry SHA-256 hash chains, which means an altered history is detectable rather than merely unlikely.

Underneath: Append-only · SHA-256 hash chains · Per-module tracing · Metrics and dashboards.

When the answer is no

It stops at the boundary, and says nothing.

A refused request never reaches a domain module. Nothing is returned, not even a hint, and the refusal is written down like everything else.

When something is unclear, the answer is no. A system that guesses in order to stay helpful will eventually show the wrong record to the wrong person.

Proving it later

History is added to, never quietly rewritten.

Activity is recorded append-only. Sensitive records, medico-legal cases among them, carry SHA-256 hash chains: each entry is tied to the one before, so an altered entry breaks the chain.

That makes tampering detectable, rather than merely unlikely.

Working with your team

Your security people, in the room early.

Not at the end, signing off something already built. These are the conversations we expect to have with them.

• Understand what you already require: Your policies, Your identity provider, Data classification, Retention rules, Who signs off.
• Map your branches and your roles: The branch structure, The roles in each, Break-glass access, What is never shown.
• Decide how people sign in: Platform login or OIDC federation, How roles map across, Joiners and leavers, Service accounts.
• Settle the audit trail and how long it lives: Which actions, Refusals as well, Where it is kept, How long, Who can read it.
• Test it the way an attacker would: Try the wrong role, Try another branch, Try a stale session, Check nothing leaks in the error.
• Keep watching after go-live: Tracing and metrics, Reviewing access, Handling incidents, Re-checking after changes.