Features

Fault reporting→

The hardest part of equipment maintenance is not fixing things. It is finding out. Every hour between a fault happening and the right person hearing about it is an hour of downtime nobody chose, and most reporting systems lose that hour by asking a nurse to log in.

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.

Audit trails→

An audit trail is only worth showing anyone if it could not have been edited. Most systems in this category log changes to a table that an administrator can update, which makes the log a record of what somebody was willing to leave there. That is a different artefact, and inspectors know it.

Offline mode→

Medical equipment lives in plant rooms, basements and lift shafts, which is exactly where mobile coverage does not. Any tool for this work has to function without a connection. The interesting question is not whether it works offline, it is what it refuses to do offline, because that answer is where the safety thinking either exists or does not.

Role based access→

Access control in a hospital is not a matrix of roles against features. It is a question of scope: this technician, at this site, for this department, on this work order, for this vendor. A permission model that only knows what someone is allowed to do, without knowing where, is not a model of a hospital.

Mobile app→

The technician surface is not a smaller version of the desktop one. A biomedical engineer triaging a queue wants density: filters, history, cost. A technician standing in front of an autoclave wants one task, its checklist, and a camera. Building the second as a shrunken first is the most common mistake in this category.

Downtime analytics→

This page is about the mechanism: where the clock starts, where it stops, who decides the interval was real, and what happens to the arithmetic when nobody has told the system what an hour of that device is worth. If you are trying to establish what downtime is costing the organisation, the Solutions page is the better starting point.

Equipment management→

This page is about the record itself: what identifies a device, what attaches to it, how two records of the same pump get found and merged, and what the register refuses to lose. If your question is how to find out what you own and where it is, the Solutions page is the better starting point.

Maintenance planning→

This page is about the machinery: how a template becomes a plan, how a plan becomes a task on a real date, what happens to the schedule when the work slips, and why the procedure version travels with the result. If your question is how to get a preventive programme running at all, the Solutions page is the better starting point.

Reporting→

This page is about how a figure is produced and defended: where a metric is defined, how you get from a chart to the records underneath it, what happens when the data is incomplete, and how a report reaches somebody on a schedule. If your question is what to put in front of a board, the Solutions page is the better starting point.

QR codes→

A label is the cheapest piece of infrastructure in equipment management, and it changes more than its cost suggests. It turns "the pump on ward 6, the one by the window" into a specific record, and it does that for a nurse with a phone and no account as readily as for a technician with a job to close.

Safety testing→

This is the part of Rydya with the fewest features and the strongest opinions. A device that has failed a safety test does not go back to a ward because somebody is in a hurry, and the software offers no way to arrange otherwise. Everything else here is negotiable. This is not.

Incident management→

An incident involving medical equipment has two clocks running from the first minute: how quickly the immediate risk is contained, and how well the reconstruction stands up months later. They pull in opposite directions, and a system built only for record-keeping serves the second at the expense of the first.

Corrective actions→

A CAPA register can be excellent at recording that an action was agreed and still establish nothing about whether anything changed. The gap between those two things is where the same incident happens again eighteen months later, to a department that has the paperwork to prove it was addressed.

Notifications→

The hard part of alerting is not sending. It is deciding what is worth a person's attention, routing it to somebody who can actually do something, and escalating when nobody does. Get the first part wrong and you have built an inbox everyone learns to ignore, which is worse than no alerting at all.

Inventory→

A spare parts store is not a warehouse problem in miniature. Its entire purpose is to make a repair shorter, which means the only measure that matters is whether the part was there when the technician needed it, and every other metric in this category is a proxy for that one.

Procurement→

Procurement inside a maintenance system exists for one reason: the part or the service is the thing standing between a broken device and a working one. Every hour spent in an approval queue is downtime, and the only interesting question is where those hours actually go.

Integrations→

Integration is where security models are quietly abandoned. The interface enforces permissions beautifully, and then a shared admin key sits in a CI variable with more access than anyone in the building. This page is mostly about how Rydya avoids that, because the rest is unremarkable and should be.

Financial impact→

Every claim a maintenance department makes about money is eventually checked by someone whose job is checking money. This page is about the rules that decide whether that goes well, and they are unglamorous, restrictive, and the reason the figures hold up.