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.

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

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.

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.

Controls that can be tested outside the prompt