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.
- Hospital operations
- Biomedical engineering
- Field technicians
What is equipment fault reporting?
Definition
Fault reporting
Fault reporting is the process by which a problem with a piece of equipment is captured against that specific asset, with a timestamp, an identifiable reporter and enough detail to act on, and turned into work that somebody owns.
The definition contains the two things most implementations get wrong. Against that specific asset: a report that says "the pump on ward 6 is broken" is a puzzle, not a report. And turned into work somebody owns: a report that lands in a shared inbox is a hope.
The third failure is subtler and it is about incentives. Reporting has to be easier than not reporting. If it is not, staff will do what staff sensibly do, which is tell a colleague and move on, and your maintenance system will be confidently reporting numbers about a fraction of reality.
Why login-free reporting matters more than it sounds
Because the people who notice faults are almost never the people your software has accounts for, and every credential you require is a reason the fault never gets reported at all.
The people who spot equipment problems in a hospital are nurses, healthcare assistants, porters, cleaners, radiographers, students on rotation and agency staff on their first shift. The people with a login to the maintenance system are a handful of engineers. The overlap is almost empty. Every system that requires an account has, in effect, decided that only engineers may report faults, which means faults are reported when an engineer happens to walk past.
The workaround hospitals actually use is a phone number or a shared mailbox. Both work, in the narrow sense that a message arrives. Both also lose the asset identity, the timestamp, the photo and the ability for the reporter to ever find out what happened. Six weeks later, nobody can tell you whether the pump was fixed, replaced or is sitting in a cupboard.
Rydya takes the other route. A QR code on the equipment opens a report form scoped to that exact asset. No account, no app, no training. The reporter describes the problem, can attach a photo, and gets a reference. That reference is what turns reporting from shouting into a conversation, and it is the single biggest reason reports keep arriving after week one.
How a fault gets reported, from scan to owned work
Scan, describe, attach, submit, and the fault is already an owned piece of work with a timestamped record.
- 1
The code identifies the asset
Each QR code resolves to a token-scoped link for one specific piece of equipment. The reporter never has to know an asset number, a model or which of the four identical pumps on the ward this one is. The equipment identifies itself, which removes the single largest source of unusable reports.
- 2
The form asks for what a non-engineer can actually give
What is wrong, in plain words. Whether patient care or a clinical service is affected, as a simple flag. The form explicitly asks reporters not to include clinical detail, because Rydya stores no patient clinical records at all and that boundary is worth defending at the point of entry.
- 3
A photo, if a photo helps
Any fault report can carry an equipment photo, from staff and from login-free public reports alike. Images are stored as real bytes and are viewable when the fault is triaged, so an engineer can often diagnose the error code before walking to the ward. Uploads are image-only and size-limited.
- 4
The reporter gets a reference
A reference they can use to check the status without phoning anyone. This is the part that keeps the reporting habit alive, and it is why it is not an optional extra.
- 5
The fault becomes owned work immediately
An alert routes to the responsible team and an assignee, and must be acknowledged so that somebody owns it explicitly. Reminders and escalation run on your rules. If the asset has a revenue figure configured, the fault shows an estimated downtime cost straight away, while it can still change a decision.
From code to owned work
What makes the record hold up later
A fault report is often the first document in a chain that ends in an incident investigation or a replacement business case. It has to survive that.
Timestamped proof, not a claim
Every report carries the server time it was received and who reported it, shown on the record as a proof strip and backed by the audit trail. Not the time somebody remembered to write it down.
Append-only audit
The report and every transition after it are written to an append-only, hash-chained audit trail in the same transaction as the change. There is no update path and no delete path, so the history of a fault cannot be tidied up after the fact.
Photos as evidence, not decoration
Images are held in the real byte store and served through fault-scoped, audited downloads. A photo of the damage taken at the moment of reporting is frequently the difference between a supported warranty claim and a conversation about who broke it.
Isolation at the row
Reports carry the organisation id like every other tenant record, protected by row level security and a server-side permission check. Public report links are token-scoped to one asset and are explicitly disallowed from search indexing.
Ways hospitals capture faults, compared
Most hospitals run two or three of these at once, which is itself the problem: the same fault arrives twice and neither copy is complete.
| Channel | Asset identity | Reporter can follow up | Evidence | Reporting effort |
|---|---|---|---|---|
| Phone call to the workshop | Whatever was described | Only by phoning again | None | Low |
| Shared email inbox | Free text, often wrong | Rarely | Attachments, if remembered | Low |
| Paper fault book on the ward | Free text | No | None | Low |
| CMMS with user accounts | Exact, if the reporter finds the asset | Yes, if they have a login | Yes | High, and gated by a credential |
| Rydya QR report | Exact, from the code on the device | Yes, by reference, no account | Photo, timestamp, audit trail | Low |
Common fault-capture channels against what each preserves
When to put codes on equipment
Early, and on the equipment that hurts most when it stops, rather than waiting to label everything.
The instinct is to complete the asset register first, label everything in one campaign, and launch. The instinct is wrong, because it delays the only thing that produces new information. Import the register, print codes for the assets whose failure costs the most, and put them on. The reports start immediately, and the reports tell you what the register got wrong.
The second reason to start early is that the QR code is the cheapest possible change-management exercise. It requires no training session, no account provisioning and no policy. A member of staff sees a code on a broken pump and scans it, because that is what people now do with codes. Adoption is the one part of this that does not need managing.
Questions
Do people need an account to report a fault?
No. Anyone can scan the QR code on a piece of equipment and report a fault in seconds without logging in, attach a photo, and use the reference they receive to check the status. Staff who do have accounts can also report from inside the workspace, and both routes carry photos and produce the same owned work.
What stops people submitting junk through a public link?
The links are token-scoped to one specific asset rather than open to the internet, uploads are image-only and size-limited, and every report lands in a triage queue rather than directly into somebody's work. In practice the bigger risk in hospitals is under-reporting, not over-reporting, which is why the friction belongs in triage rather than at the point of capture.
Can the person who reported the fault see what happened?
Yes. The reference they receive lets them check the status on the public status view without an account. That feedback loop is the reason reporting survives past the first month.
Does the fault report capture patient information?
No. Rydya stores no patient clinical records at all. The report captures whether patient care or a clinical service is affected as a simple flag, and the forms explicitly ask reporters not to include clinical detail.
What happens in the first five minutes after a report?
The fault raises an alert routed to the responsible team and an assignee and must be acknowledged, so ownership is explicit rather than assumed. It appears in the notification inbox, can be pushed to a subscribed webhook, and if the asset has a revenue figure configured it shows an estimated downtime cost immediately. Reminders and escalation then run on the rules you configure.
Keep reading
Work orders
What the fault becomes: ownership, parts, repair and an evidenced return to service.
Hospital equipment maintenance
The whole loop, and why the gaps between steps are where hospitals lose equipment.
Preventive maintenance
The planned work that was meant to stop the fault happening in the first place.
See it on your equipment
Live in an afternoon, useful the same week. A person replies, usually within one working day.
Contact us