Safety, authority and evidence

Intended use and excluded use

Intended

Identifying operational constraints in administrative pathway state.
Preparing permitted administrative actions with their evidence attached.
Routing material actions to named humans for approval.
Monitoring whether an action produced its expected outcome, and escalating when it did not.
Producing an inspectable record of what was decided, by whom, on what basis.

Excluded

Diagnosis, treatment recommendation or clinical prioritisation.
Determining clinical suitability or eligibility.
Live appointment booking or any write to a real operational system.
Unsupervised communication with patients.
Any processing of real patient data at this stage.

Administrative fact, clinical judgement

The line the current research focus is built on, and the one worth arguing with first.

What the system may establish

That a review expected by a recorded date has no matching booking. It compares two things a person wrote down — the date a clinician intended, and whether an appointment exists against it — and reports the difference.

What only a clinician may decide

Whether this patient should be seen sooner, whether their risk has changed, what priority applies, whether they are suitable, and anything about diagnosis or treatment. A request to decide any of those is refused, recorded, and routed to a clinician.

An overdue review is not a clinical judgement about a patient. It is an observation about a record. The distance between those two sentences is the entire safety argument, and the demonstrator is built so that crossing it is refused rather than discouraged.

There is a third case the system also has to get right: where the record does not say enough to be sure. An appointment exists but nothing links it to the review; no interval was ever recorded. It abstains and sends those to a person rather than resolving them one way or the other, because a confident wrong answer about a patient who already has an appointment is worse than no answer.

What that looks like in a service, and what the evidence does not show

Authority classes

Every action exists in an explicit catalogue, and its class is a property of that catalogue resolved at decision time. The planner proposes; it cannot promote its own permissions.

A: The system acts; Reversible, low-risk administrative work that policy permits outright. Raising a coordination task, recording that a dependency is outstanding. Every one of these can be undone.
B: One named person confirms; The system prepares the action and stops. Chasing an external provider, escalating an overdue dependency. Nothing leaves the building until someone with the authority says so.
C: Two named people confirm; Higher impact, patient-facing or capacity-affecting. Offering a recovered slot needs both a booking decision and a human confirmation of clinical suitability, and they cannot be the same person.
D: Clinical judgement — routed, never decided; Anything touching diagnosis, treatment, clinical priority or eligibility. The system may put it in front of a clinician. It may never answer it. A refusal here is the system working correctly.
E: Outside the catalogue — never runs; If an action is not explicitly catalogued, it is denied and recorded. There is no general-purpose capability waiting behind the catalogue to be discovered.

Classes D and E deliberately carry no alarm colour. A clinical request being routed to a clinician is the system working correctly, and colouring it as a fault would teach people that safety is failure — which is how staff learn to route around a control.

Human approval and separation of duties

A bounded operational action needs one named role. A higher impact action — patient facing, or affecting capacity — needs two, and they cannot be the same person. Capacity actions specifically require a human confirmation of clinical suitability; the system never infers it.

An approval can be given, refused, amended or allowed to expire. An expired approval is never treated as consent: the action does not run and the problem is escalated.

Approver roles are validated against policy but are not authenticated identities. Named approval is a policy mechanic in the demonstrator, not an identity assured control. Identity assurance is part of the assurance route below.

Evidence provenance

Every material statement on this website resolves to an entry in a claim evidence register carrying a classification, an evidence source, an owner and a review date. A claim missing any of those does not render — the page shows a visible gap rather than unreviewed copy.

Synthetic demonstration A functioning synthetic demonstrator that processes pathways end to end, enforces an authority model, requires human approval where policy demands it, and records a verifiable audit trail.

Synthetic demonstration Runs reproduce exactly from a seed: the same scenario run twice produces an identical event ledger hash.

Tamper evident audit

Each record hashes its own content together with the hash of the record before it, so altering or removing any record breaks verification from that point onward. The demonstrator includes a control that alters a record in a sandboxed copy and shows verification failing while the live chain stays intact.

Every action is recorded in a hash-chained ledger in which altering any record breaks verification from that point onward.

We describe this as tamper evident, never as immutable. Demonstrator manifests are not yet cryptographically signed or externally anchored, so the chain detects alteration rather than preventing it.

Current limitations

Synthetic data only: Every pathway, event, resource and external response is invented. Nothing here says how the system behaves on real data.
Detection thresholds are defaults: They are demonstrator values with no evidential basis, shown next to the figures that depend on them rather than hidden in a footnote.
Approval is a policy mechanic, not identity assurance: Approver roles are supplied by the caller and validated against policy. They are not authenticated identities.
The audit chain is in memory: There is no retention policy, no access control and no external anchoring. Manifests are not cryptographically signed.
No accessibility conformance is claimed: Contrast ratios are checked arithmetically. Browser, keyboard, screen reader, zoom and reflow testing must be completed before any conformance statement.
No production readiness of any kind: A synthetic demonstrator is not evidence of production security, reliability, scale, safety or compliance.

Production assurance route

None of the following is complete. A roadmap is not proof of compliance, and Leva Health holds no certification, approval or assurance status of any kind.

Intended use and classification: A formal intended-use statement and regulatory classification assessment. We do not assert that Leva Health sits outside medical device regulation because the intended scope is operational.
Clinical safety: Competent clinical safety leadership, DCB0129 activity and the partner DCB0160 interface, as applicable.
Information governance: Controller and processor roles, lawful basis, DPIA, retention, rights and transfer positions.
Security: Threat modelling, penetration testing, incident response, supplier risk and logging approach.
Interoperability: Partner architecture, NHS standards and APIs, terminology and conformance testing.
Evaluation: A pre-registered design with a declared comparator, agreed measures and independently reviewed assumptions.

Controls that can be tested outside the prompt