Features
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.
- Biomedical engineering
- Hospital operations
- Quality and compliance
What is equipment management?
Definition
Equipment management
Equipment management is the maintenance of one authoritative record per physical device, carrying its identity, location, ownership, documents, images and complete history, such that every module in the system attaches to the same record rather than to its own copy.
The load-bearing phrase is one record per device. It sounds trivial and it is the single hardest thing to hold true in this category, because every module wants to describe equipment slightly differently. Maintenance wants a serviceable unit. Finance wants a depreciable asset. Procurement wants a catalogue line. Left alone, each grows its own version and the organisation ends up with three answers to one question.
A register is not a spreadsheet with more fields. It is the thing everything else points at, which is why an imperfect register that everything shares beats a perfect one that half the modules ignore.
Why registers rot
Because keeping them accurate is unpaid work whose benefit lands on somebody else, so it loses to whatever is urgent that morning.
Nobody ever decided to let the register drift. What happens is smaller and more forgivable: a device moves to another ward during a busy week and the move is not recorded, because recording it helps a person who is not in the room. Multiply that by three years and the register describes a hospital that no longer exists.
The second cause is the duplicate. A device is re-imported from a new supplier list, or re-created because nobody could find the original, and now there are two records with half a history each. Neither is wrong exactly, and that is the problem: the history that would answer a question is split across two rows that nobody knows are the same device.
The third is the attachment that was never really there. A manual "attached" as a link to a shared drive that has since been reorganised, or a photo recorded as a filename rather than as bytes. It looks like the register holds the document. It does not, and you find out at the worst possible moment.
How Rydya keeps the record true
By making the correct action the convenient one, and by never storing a pointer where the thing itself belongs.
A scan is a confirmation
A technician scanning a code to start a job also confirms the device is where the register says it is. This is the important one: the accuracy is a by-product of work that was happening anyway, so it does not depend on anyone doing unpaid data entry.
Images and documents are real bytes
Stored in an object store with organisation-prefixed keys and served through permission-checked, audited downloads. Not a link to a drive, not a filename in a metadata field. If the register says it has the photo, it has the photo.
Duplicates are surfaced rather than assumed away
Likely duplicate records are flagged for a person to judge, because merging two histories is a decision with consequences and an automatic merge that gets it wrong destroys the very history you were protecting.
Data quality is a running scan, not an annual project
Missing serials, absent locations, records with no history, fields that contradict each other. Surfaced continuously as work, so the register is corrected in small pieces rather than in a doomed six-month cleanse.
The history is append-only
Every change lands in a hash-chained audit trail in the same transaction as the change itself. The record can be corrected; what it used to say cannot be quietly removed.
Why the same record serves finance and maintenance
Because a device that is expensive to run and a device that keeps failing are usually the same device, and you cannot see that if the two facts live in two systems.
The strongest argument for one record is not tidiness, it is the question it makes answerable. "Which devices cost us the most and why" requires the repair history, the parts, the downtime and the purchase price to be facts about one object. In two systems joined by a spreadsheet, that question takes a fortnight and the answer is contested.
This is also why the commercial fields sit on the same record rather than in a finance module of their own. A revenue figure against an asset is what lets a downtime interval become an estimated impact, and a replacement case is just that history read at a different altitude. None of it works if finance and maintenance are describing different objects that happen to share a name.
The word we use is asset, and the word technicians hear is equipment
The data model says asset, because that is what it is: a thing you own, with a history and a cost. Frontline screens say equipment, because that is what people standing next to it call it. This is deliberate rather than an inconsistency. A register that speaks the vocabulary of the person filling it in gets filled in.
When to start, and who should own it
Start before it is clean, and give it to whoever is accountable for the equipment rather than to whoever is good with spreadsheets.
The instinct is to perfect the register before turning anything else on. It is backwards, and expensively so. The register gets accurate through use: through scans, through jobs, through technicians standing in front of real devices and finding that the record is wrong. Waiting for a clean import means paying for a discovery exercise that the first month of ordinary work would have given you for nothing.
Ownership matters more than tooling. A register nobody is accountable for decays at exactly the rate you would expect, and no amount of data-quality scanning fixes an organisational gap. The scans tell you what is wrong; a person still has to care that it is wrong.
Questions
Can we import our existing register?
Yes, and you should, imperfections included. Import gets you to a starting point in an afternoon, and the register then becomes accurate through ordinary use rather than through a cleansing project. Waiting until a spreadsheet is perfect before importing it is the most common way this work stalls for a year.
What happens if the same device ends up in the register twice?
Likely duplicates are flagged for a person to judge rather than merged automatically. Merging two records means merging two histories, and an automatic merge that gets it wrong destroys the history you were trying to protect. The system finds the candidates; a human decides.
Are photos and manuals actually stored, or just linked?
Stored as real bytes in an object store with organisation-prefixed keys, and served through permission-checked, audited downloads. A link to a shared drive is not an attachment, it is a promise about someone else's folder structure, and it breaks silently at the worst possible moment.
How do we stop the register drifting again?
Mostly by making accuracy a by-product of work rather than a separate task. A technician scanning a device to start a job confirms its location without doing data entry. Continuous data-quality scans surface the gaps as small pieces of work. What software cannot supply is someone accountable for caring, and that part is organisational.
Keep reading
QR codes
The scan that confirms identity and location as a side effect of doing the job.
Equipment lifecycle
The same record read over years, from commissioning to replacement.
Audit trails
Why what the record used to say cannot be quietly removed.
The platform
Why one data model, and the refusals everything else follows from.
See it on your equipment
Live in an afternoon, useful the same week. A person replies, usually within one working day.
Contact us