Features
Work orders
Every maintenance system has work orders. The difference is what happens at the two ends: whether a human ever explicitly accepted the job, and whether the system will let anyone close it before the equipment is provably safe to use again. Rydya is opinionated about both.
- Biomedical engineering
- Clinical engineering
- Field technicians
- Quality and compliance
What is a work order?
Definition
Work order
A work order is the record of a single piece of maintenance work against a specific asset: what needs doing, who owns it, what was actually done, what parts it consumed, and what had to be true before the equipment could be used again.
In healthcare that last clause carries all the weight. In most industries a work order is complete when the work is complete. On a medical device, work being complete and equipment being safe to return are two different facts, established by two different activities, and a system that treats them as one is quietly dangerous.
Why work orders stall
Because assignment is not acceptance. A system saying somebody should own this is not a person saying they do, and jobs die in that gap.
Watch a stalled job and it is almost never stuck on the repair. It is stuck between things: between diagnosis and a quote, between a quote and an approval, between an approval and a part, between a part arriving and someone noticing it arrived. Each of those handovers is a place where the work stops moving while everybody assumes it is somebody else's turn.
The pattern has a name in most departments: the job that is technically open and practically forgotten. It shows in the numbers as a long tail of ageing work orders that nobody can explain, and it is almost always a handover problem rather than a capacity problem.
Rydya attacks it at the front. A fault raises an alert that must be acknowledged. Not assigned, acknowledged, by a person, explicitly. If nobody acknowledges, that absence is itself an event the system can escalate on. You cannot fix every stall with software, but you can refuse to let the first one be silent.
How a work order moves through Rydya
Raise, acknowledge, diagnose, resource, repair, test, clear, close. The gates are real and there is no path around them.
- 1
Raised against a real asset
From a fault report, a preventive plan, or directly. It inherits the asset, its location, its history and its configured revenue figure, so the cost of it being down is visible from the first minute rather than reconstructed afterwards.
- 2
Acknowledged by a person
The alert routes to the responsible role and an assignee and must be acknowledged. Reminders and escalation run on the rules you configure. Ownership is a fact in the record, not an inference from an assignment field.
- 3
Diagnosed, with the finding recorded
What was actually wrong, captured against the asset, which is what makes recurring-failure analysis possible later. An asset that has been diagnosed with the same fault four times is an asset with a replacement case, but only if the diagnoses were recorded somewhere comparable.
- 4
Resourced from real stock
Parts come from the inventory you actually hold. Reservations and stock movements are written as they happen, procurement and approvals run where thresholds require them, and the cost lands against the work order rather than in a separate finance conversation months later.
- 5
Tested, where testing is required
Calibration and safety testing run as their own work with measurements and pass or fail results against the limits you configured, producing certificates and, where needed, restrictions.
- 6
Cleared and returned to service, or not
Return to service is a gate. The required tests and an authorised clearance must both exist. There is no override for convenience, for a demonstration, or to make a deadline. Equipment that has not cleared the gate stays quarantined, and quarantine is server-authoritative so no offline client can talk its way out of it.
The return-to-service gate
Two conditions, both required, no third path. This is the single structural difference between healthcare maintenance and facilities maintenance.
What Rydya refuses to do
The constraints are the product. A tool that will bend under pressure is a tool that will bend at exactly the wrong moment.
It will not close a work order past the safety gate
No return to service without the required tests and an authorised clearance. Not for convenience, not for demos, not to make a test suite pass. If that is inconvenient, the inconvenience is the feature.
It will not let the UI be the security boundary
Every protected action is permission checked on the server, and every tenant record carries an organisation id enforced by row level security. Hiding a button is not access control, and Rydya does not pretend otherwise.
It will not let history be edited
The audit trail is append-only and hash-chained, written in the same transaction as the change it records. Corrections are audited amendments, not quiet edits. Closed financial records are never edited in place.
It will not invent a cost
If you have not configured what an asset earns and no finance-approved rate applies, the downtime cost is reported as not configured. An invented number is worse than no number, because somebody will make a decision with it.
Ownership signals compared
These look interchangeable on a spec sheet. Operationally they are completely different, and only one of them tells you a human accepted the job.
| Mechanism | What it proves | What it misses |
|---|---|---|
| Assigned to a queue | The work reached the right team | Nobody in particular has it |
| Assigned to a person | The system nominated an owner | That person may be on leave, or may never have looked |
| Acknowledged by a person | A named human accepted the job at a known time | Nothing, at this stage. This is the signal you want |
| First status change | Somebody started work eventually | Arrives far too late to escalate on |
What each ownership mechanism actually establishes
Who works in it, and where
Engineers work in the web workspace; technicians work from a phone in a plant room with no signal. Both are first-class, and the offline boundary is drawn on safety rather than convenience.
The workshop and the field are genuinely different jobs. A biomedical engineer triaging a queue wants density: ranked work, filters, history, cost. A technician standing in front of an autoclave wants one task, its checklist, and a camera. Serving both from one data model rather than two products is what keeps the record whole.
Offline is where the healthcare-specific judgement shows. Approved field actions work offline with visible sync state, and queued work syncs when the connection returns. But safety-critical actions, quarantine, approvals, return to service, final cost, stay online and server-authoritative by design. An offline device cannot be allowed to decide that a ventilator is safe again, and the conflict rules make that structural rather than a matter of policy.
Questions
What stops a work order being closed before the equipment is safe?
Return to service is a gate rather than a status. The required tests and an authorised clearance must both exist before equipment goes back into use, and there is no bypass path, including for demonstrations or deadlines. Quarantine and return to service are also server-authoritative, so an offline client cannot override them.
How is escalation configured?
On your rules, not on ours. Alerts route to responsible roles and an assignee, must be acknowledged, and escalate when acknowledgement or progress does not happen inside the windows you set. Anything meaningful that becomes due or done also reaches the notification inbox and any subscribed webhook.
Do parts and costs flow into the work order automatically?
Yes. Parts are issued from real stock with reservations and movements written as they happen, procurement and approvals run where your thresholds require them, and cost lands against the work order. Estimated and confirmed financial impact stay separate records and are never merged.
Can technicians complete work orders offline?
Approved field actions work offline on mobile and desktop with visible sync states, and queued work syncs when the connection returns. Safety-critical actions such as quarantine, approvals and return to service stay online only by design.
Can we see which assets keep coming back?
Yes, because diagnoses and work are recorded against the asset rather than against a job sheet. Recurring failures, health scores and reliability signals surface the assets that repeat, which is what turns a replacement request into a replacement case.
Keep reading
Fault reporting
Where most work orders begin: a QR scan by someone with no account.
Preventive maintenance
Where the rest begin: planned work, generated from the rules you set.
Hospital equipment maintenance
The whole loop end to end, including what the downtime costs.
Biomedical maintenance companies
The same jobs, seen from the service company side.
See it on your equipment
Live in an afternoon, useful the same week. A person replies, usually within one working day.
Contact us