Platform
Four modules. One readiness status.
Livel covers the span between listing a patient and wheeling them into theatre. It captures the assessment once, applies risk instruments consistently, coordinates the optimisation window, and publishes one status the whole team can see.

The workspace
One percentage for the service, one row per patient, and nothing hidden behind a score.

On the day
A handover the whole team reads the same way.
Deliberately narrow
Livel owns the weeks before surgery and hands its summary back to your record of truth.
Modules
0
used in order, each one feeding the next. No module works alone.

Optional from day one
HL7 and FHIR when you want them — a pilot can start without either.
01 — Modules
What each part of the platform does.
Four modules, used in order, each one feeding the next.
M1
Structured record
The assessment is captured once, in coded fields, before the patient reaches clinic.
Patient-completed history
Medication reconciliation
Functional capacity and consent
M2
Risk and readiness
Published instruments applied to every listed patient, with the reasoning shown.
Frailty and anaemia screening
Cardiopulmonary reserve
Escalation to specialist review

M3 · the board
Every action in the window has a week, an owner and a date it is due.
M3
Optimisation window
The four weeks before theatre, owned by someone and tracked to a date.
Anaemia, nutrition, exercise pathways
Named owner per action
Automatic patient follow-up
M4
Shared status
One readiness signal that the whole team, including scheduling, can act on.
Team handover summary
Day-of-surgery status
Service-level dashboards
02 — One record, four views
Everyone sees the same patient. Nobody sees the same screen.
What Livel surfaces first for each role on the team.

Same record
Four roles, four first screens, one source.
Anaesthetist · Tomorrow's list
The four patients on this list who need a decision from you.
Top of screen
Patients whose risk profile changed since booking
Then
Coded history, medications and functional capacity, already summarised
Actions
Accept, escalate, or request an optimisation pathway with a due date
Not shown
Anything already resolved — closed items collapse out of the way
Surgeon · Is this booking safe to stand
Whether the patients you listed will actually be ready.
Top of screen
Readiness status for every case you have listed, by list date
Then
Blockers with a named owner and an expected resolution date
Actions
Flag clinical urgency so optimisation is traded off deliberately
Not shown
Assessment detail you do not need to re-read
Pre-admission nurse · Today's clinic
Clinic arrives pre-populated, so the hour is spent deciding.
Top of screen
Today's clinic with each patient's completed history already in
Then
Gaps and inconsistencies flagged for confirmation, not re-collection
Actions
Start a pathway, book an intervention, hand over to the anaesthetist
Not shown
Free-text fields that duplicate coded answers
Scheduler · Next month's lists
A readiness signal you can build a list around.
Top of screen
Cases at risk of near-day deferral, ranked by likelihood
Then
Earliest date each at-risk patient is expected to be ready
Actions
Move, backfill or hold a slot before the week of surgery
Not shown
Clinical detail — schedulers see status, not history
Illustrative interface descriptions. No real or patient-identifiable data.
03 — Fit
It sits beside your record, not on top of it.
A pilot does not require an integration project. Livel reads a booking list, does its work, and returns a structured summary to whatever system holds the record of truth.
How we handle data and privacy →Deployment
Browser-based; no software on hospital desktops to see it working
Data in
Manual booking entry for a pilot; HL7 / FHIR feed when a service is ready
Data out
A structured PDF or FHIR summary back into the record of truth
Identity
SSO where available, otherwise managed accounts with role-based access
Scope
Elective surgical pathways first; emergency lists are out of scope by design
04 — Boundaries
What Livel is not.
Being clear about the edges is part of being safe to deploy.
Not this
Not an EMR
It does not want to be your record of truth, and it hands its summary back to the one you have.
Not this
Not a diagnostic device
It applies published instruments and shows its working. Every judgement stays with the treating clinician.
Not this
Not a billing workflow
Nothing in the product is shaped by item numbers or claiming.
Not this
Not a patient app
Patients complete a structured history. They are not asked to manage their own care in an app.

Bring one of your own lists.
Thirty minutes with the founder, walked through a real pathway. No obligation, no integration required.