Features
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.
- Quality and compliance
- Clinical engineering
- Hospital operations
What is device incident management?
Definition
Device incident management
Device incident management is the handling of an event where equipment may have caused or contributed to harm or risk: containing the immediate danger, identifying what else could be affected, investigating the cause, and driving corrective actions to completion, with every step recorded in a timeline that cannot be revised.
The order in that definition is the substance. Containment comes before investigation, because the first question is not why it happened, it is what else is currently exposed. A system that opens with a root-cause form is asking the wrong question at the wrong minute.
Rydya stores no patient clinical records. An incident here concerns the device, its status, its history and the work done to it. The clinical record belongs in your clinical systems, and keeping that boundary sharp is deliberate rather than a limitation.
Why incident records fail when they are needed
Because they are written for the filing rather than for the reconstruction, and the difference only becomes visible under scrutiny, by which point it is not fixable.
The failure is recognisable and almost universal. The incident happens on a Tuesday. It is recorded properly on the Friday, by someone reconstructing it from memory and a couple of messages. Every field is filled. The record looks complete. It is not a record of the incident, it is a record of what people remembered on Friday, and the difference is invisible until somebody investigates properly.
The second failure is the tidied history. A status was set wrongly and corrected, so the record shows the corrected version. A note was rephrased. Nothing dishonest happened, and yet the timeline now reads as a smooth sequence of correct decisions, which is not what happened, and is exactly the thing an investigator is trying to establish.
The third is the deadline that expires quietly. A containment action, an investigation step or a corrective action has a date. The date passes. Nothing happens, because a date is a piece of data rather than an actor. Six months later the incident is technically open and practically forgotten.
How Rydya handles an incident
Contain, identify who else is exposed, investigate, drive actions to completion, and record all of it as it happens rather than afterwards.
- 1
Contain first
The device is quarantined, which is server authoritative and immediate. Not queued, not pending review. The first act is removing the risk from clinical use, and everything else can wait a few minutes.
- 2
Identify what else is exposed
The same model, the same batch, the same lot, the same fault pattern. One failing device is an incident; the same device type across four wards is a different problem, and you find out which one you have by asking rather than by waiting.
- 3
Investigate with the history intact
The device's full record is already there: maintenance, tests, parts fitted, who worked on it and when, against which procedure version. Investigation is reading a history rather than assembling one.
- 4
Drive corrective actions to completion
Actions have owners and dates, and the dates escalate rather than lapse. An overdue corrective action becomes somebody's problem while it still matters, which is the only thing that separates a CAPA from a wish.
- 5
The timeline records itself
Every state change, decision and clearance is written append-only and hash-chained, in the same transaction as the change. What the record says was believed on Tuesday stays retrievable, whatever was concluded later.
What the module deliberately does not do
Three refusals, each one a place where a helpful feature would produce a dangerous record.
It does not decide whether a device caused harm
That is a clinical and regulatory judgement made by qualified people. Rydya holds the evidence, the timeline and the actions. It does not classify causation, and it does not interpret whether an event is reportable to a regulator.
It does not let the timeline be edited
Corrections are audited amendments that sit alongside the original, never replacements. A timeline that can be tidied is a timeline that proves nothing, and its tidiness is precisely what an investigator will not accept.
It does not store patient clinical records
None, at all. An incident here is about the device. Keeping the clinical record in your clinical systems is a deliberate boundary that limits what a breach of Rydya could ever expose.
When to open one, and who should own it
Open it early and downgrade later, because the record is only as good as the minute it started, and owned by someone with authority to stop things.
The instinct is to wait until it is clear whether the event is serious. It is the wrong instinct, because the cost of opening one that turns out to be minor is a few minutes, and the cost of opening one late is that the first hours exist only as recollection. Downgrading a contained incident is easy. Reconstructing an uncontained one is not.
Ownership needs authority. Incident management that reports to someone who cannot quarantine a device, halt a procedure or stop a ward using a model is administration rather than safety. The software enforces the gates; it cannot supply the mandate, and an incident process without one produces excellent paperwork about things that kept happening.
Questions
Does Rydya decide whether an incident is reportable to a regulator?
No. Reportability is a regulatory and clinical judgement made by qualified people against the rules that apply to you, and software asserting it would be inventing a legal interpretation. Rydya holds the evidence, the timeline and the corrective actions so that the people making that judgement have something solid to make it from.
Can we correct an incident record that was entered wrongly?
Yes, as an audited amendment that sits alongside the original rather than replacing it. The timeline is append-only and hash-chained. This is deliberate: a record that can be tidied proves nothing, and its very tidiness is what an investigator will refuse to accept.
How do we find other devices that might be affected?
By the same model, batch, lot or fault pattern, from the register rather than from memory. One failing device is an incident; the same device type failing across four wards is a different problem entirely, and the point of asking early is to find out which one you actually have.
Does Rydya hold patient information about an incident?
No. Rydya stores no patient clinical records at all. An incident here concerns the device: its status, history, the work done to it and the actions arising. The clinical record belongs in your clinical systems, and that boundary limits what a breach of Rydya could ever expose.
See it on your equipment
Live in an afternoon, useful the same week. A person replies, usually within one working day.
Contact us