Solutions
Equipment lifecycle
A device does not have a status, it has a life: planned, bought, commissioned, used, repaired, sometimes quarantined, eventually retired or replaced. Most systems model that as a dropdown, which is why nobody can answer what state anything is really in.
- Biomedical engineering
- Clinical engineering
- Executive and finance
What is equipment lifecycle management?
Definition
Equipment lifecycle management
Equipment lifecycle management is governing a device through every stage from planning to disposal as a set of explicit, permission-checked transitions, so that its current state is always a fact rather than an opinion and its history is a defensible record.
The alternative, which is what most organisations run, is a status field anyone can set to anything. That makes state a claim rather than a fact: the difference between "quarantined" and "in service" is whoever last opened the record.
Lifecycle management is what makes the end of a device's life arguable. A replacement case is not a feeling that something is old; it is a history of failures, downtime, spend and unavailable hours, and it only accumulates if the lifecycle was recorded rather than described.
Why lifecycle governance fails
Because the expensive stages are at the ends, and the ends are owned by people who do not use the maintenance system.
Commissioning involves procurement, clinical and engineering; retirement involves finance and estates. Only biomedical engineering, which owns the middle, has a maintenance system. So the middle is recorded well and both ends live in email, which is backwards: the ends are where the money is.
The visible consequence is the device still on the register three years after it left the building, still generating planned work that a technician closes without ever finding the asset. The compliance report counts them.
The less visible consequence is the replacement that never gets made. If nobody recorded the failures, the downtime and the cost, the capital conversation is anecdote against a finance spreadsheet, with a predictable outcome.
How Rydya governs the life of a device
One explicit state machine, transitions that are permission checked and audited, and a history that accumulates into a case.
- 1
Planned and received
The asset exists as a record before it exists in the building, so receipt is a transition rather than a data-entry event. Procurement, quotes and purchase orders live in the same system, so the asset arrives with its commercial history attached.
- 2
Inspected, installed, commissioned
Each is a distinct transition rather than a status somebody types. Commissioning can require the tests and evidence you decide, so a device does not become operational because a form was filled in.
- 3
Operational, and accumulating
Faults, planned work, tests, parts and downtime attach to the asset through its working life, quietly building the evidence for the last stage.
- 4
Quarantined, restricted, transferred
The exceptions are first-class states, not annotations. Quarantine is a server-authoritative gate, and transfers move custody while preserving history.
- 5
Replaced or retired, with a case
Replacement cases draw on the accumulated history: recurrence, health score, measured downtime, cost of ownership. CAPEX requests carry the case.
What makes a state mean something
A state is only useful if it constrains something. These are the constraints Rydya actually enforces.
Transitions are permission checked on the server
Not hidden in the interface. Hiding a button is not access control, and a lifecycle governed by UI visibility is governed by nothing.
Some transitions are gated
Return to service requires the required tests and an authorised clearance. There is no bypass, and the gate is server authoritative so an offline client cannot decide otherwise.
Every transition is audited in the same transaction
Append-only and hash-chained, with no update path and no delete path. The lifecycle history cannot be tidied afterwards.
History survives custody changes
A transfer moves the asset without resetting it. An asset that has moved twice still carries every fault it ever had, which is exactly what the replacement case needs.
Retirement is a transition, not a deletion
A retired asset keeps its record. Deleting it would destroy the evidence for why it was retired.
Where the cost of a device actually sits
Purchase price is the number everyone knows and the smallest part of the answer.
| Stage | What it costs | Recorded by |
|---|---|---|
| Acquisition | Purchase, delivery, installation | Procurement, purchase orders, receipts |
| Commissioning | Inspection, initial testing, training time | Lifecycle transitions and test records |
| Operational life | Planned work, parts, labour | Work orders, inventory, cost ledger |
| Failure | Repair, and the downtime it causes | Faults, downtime events, financial impact |
| End of life | The replacement, and the case for it | Replacement cases, CAPEX requests |
Cost across the life of a device, and what records it
When a replacement case becomes winnable
When the history is already there. You cannot start collecting evidence at the moment you need it, which is the moment everyone tries.
A capital request built the week before a budget meeting is a request. One built from three years of recorded failures, each with a measured downtime cost, is a calculation. The work is identical; the difference is whether the recording happened as the failures did.
The value is not tidier records; it is that biomedical engineering stops arguing from anecdote. Health scores and reliability signals surface the assets that keep coming back, and the cost of ownership view puts the total next to the replacement price. The conversation becomes arithmetic.
Questions
What are the lifecycle states in Rydya?
Planned, received, inspected, installed, commissioned, operational, quarantined, transferred and retired, as one explicit state machine. Every transition is permission checked on the server and written to the append-only audit trail in the same transaction, so the current state is a fact.
Can a retired asset be deleted?
Retirement is a transition, not a deletion. The record stays, because it holds the evidence for why the device was retired, which is often the most valuable thing it ever produced. The audit trail has no delete path by design.
What happens to history when equipment moves site?
Transfers move custody while preserving history. The asset keeps every fault, test and downtime event it has ever had rather than starting a new life at the new location, which is precisely what a replacement case needs.
How does Rydya decide when equipment should be replaced?
It does not decide. It assembles the evidence: recurrence, health score, measured downtime, cost of ownership against replacement price. The decision belongs to your engineering and finance people, deciding from a calculation rather than from who remembers the failures better.
Does commissioning require evidence before a device goes live?
It can require whatever you configure it to require. Commissioning is a real transition rather than a status, so you can bind the tests and evidence you decide are necessary to it. Rydya enforces your rule; it does not supply the rule.
Keep reading
Asset tracking
The register the lifecycle runs on, and how to stop it rotting.
Executive reporting
Where the replacement case gets made, and to whom.
Downtime management
The measured cost that turns a replacement request into a calculation.
Vendors and leasing
The lifecycle seen by whoever owns the device but does not hold it.
See it on your equipment
Live in an afternoon, useful the same week. A person replies, usually within one working day.
Contact us