Features

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.

  • Biomedical engineering
  • Clinical engineering
  • Quality and compliance

What is safety testing in Rydya?

Definition

Safety testing and the return-to-service gate

Safety testing is the recording of test results against limits your organisation configured, using instruments whose own calibration status is known, feeding a gate that prevents a device returning to clinical use until the required tests are present, passing, and an authorised person has cleared it.

The gate is the feature. The tests are evidence; the gate is what makes the evidence matter. A system that records a failed test and then lets the device go back anyway has not implemented safety testing, it has implemented a form.

Rydya does not know what a pass looks like on your equipment. The limits, the required tests and who may clear a device are configuration, set by your qualified staff. What Rydya guarantees is that once you have set them, they hold, including on the afternoon when holding them is inconvenient.

How the return-to-service gate works

Required tests present, results passing, authorised clearance recorded. Missing any one of the three means the device stays out of service.

A gate showing a device coming out of repair or maintenance. Three conditions must be satisfied before it returns to clinical use: the required tests exist, their results pass against the configured limits, and an authorised person has recorded a clearance. If any condition is unmet the device remains out of service, and the attempt itself is recorded in the audit trail.RepairedWork doneSafety testCannot be skippedClearedAuthorised return
Three conditions, all required. There is no fourth path.

Why safety gates get bypassed, and why ours cannot be

Because every bypass is built for a genuinely sympathetic reason, and the sympathetic reasons arrive on exactly the days when the gate is load bearing.

Nobody builds an override for a bad reason. It is built because a ward is desperate, because a test instrument is away being calibrated, because the paperwork is a formality and the engineer is certain. Each individual case is reasonable. The aggregate is that the gate now has a door in it, and the door gets used on the worst days rather than the ordinary ones.

The second route is subtler and more common: the gate exists but nothing enforces it. The status can be set directly, or an API accepts a transition the interface would have refused, or an import writes the field. The gate was a screen rather than a rule, and screens do not travel to the places where the decision actually gets made.

Rydya takes the position that a gate with an override is not a gate. There is no convenience bypass, no demo mode that relaxes it, and no way to make a failing test pass. The transition is checked on the server, enforced regardless of which client asked, and recorded in an append-only, hash-chained audit trail in the same transaction as the change. We will not weaken this to make a demonstration smoother, and there is no demonstration configuration in which the gate behaves differently.

What the gate requires, and what it refuses

Three requirements, and a short list of things that are simply not available.

The required tests must exist

Which tests are required is your configuration, because it depends on the device, its class and your policy. Once configured, an absent test is not a pass. The absence of evidence is never treated as evidence.

The results must pass against your limits

You set the limits. Rydya compares the reading to them and records both. It does not interpret, round in a helpful direction, or decide that a marginal result is probably fine.

An authorised person must clear it

Not the system, and not whoever happens to be logged in. Clearance is a permission-checked human decision with a name against it, because returning a device to clinical use is a judgement someone is accountable for.

It cannot be done offline

Return to service and quarantine are server authoritative and unavailable offline rather than queued. An offline device cannot establish that equipment is safe, so the honest answer is to refuse rather than to accept and hope.

The instrument's own status counts

A test is only as good as the thing that measured it. Test instruments carry their own calibration status, so a result from an instrument that is out of calibration is visible as such rather than silently trusted.

We will not invent your limits

Rydya ships no safety-test values, no intervals and no thresholds, and it never will. Those are clinical and regulatory decisions belonging to your qualified staff and your applicable standards, and a helpful default here would be a piece of software making a medical claim about equipment it has never seen. What we provide is the machinery that holds your decisions and does not bend them.

When quarantine applies, and who decides

Quarantine is the other half of the same gate: it removes a device from use immediately, and it is a human decision that the system enforces rather than an outcome the system infers.

A failed test, an incident or a recall can all mean a device should not be used right now. Quarantine makes that authoritative the moment it is made, which is why it is server authoritative and not available offline. A quarantine that syncs later is a device that stayed in use for the hours in between, and those are precisely the hours it mattered.

Coming out of quarantine runs the same route as any return to service: required tests, passing results, authorised clearance. There is no separate quicker path for a device that was quarantined by mistake, because "it was a mistake" is a judgement, and the gate exists to make judgements explicit and attributable rather than assumed.

Questions

Can a device be returned to service without passing the required tests?

No. There is no override, no convenience bypass and no demo mode that relaxes it. The required tests must exist, their results must pass against the limits you configured, and an authorised person must record a clearance. The transition is checked on the server, so it holds regardless of which client asks, and every attempt lands in the audit trail.

Does Rydya tell us what the pass limits should be?

No, and it never will. Safety-test limits are clinical and regulatory decisions belonging to your qualified staff and the standards that apply to you. A default here would be software making a medical claim about equipment it has never seen. Rydya holds the limits you configure, compares readings to them, and refuses to bend them.

Can a technician clear a device from their phone offline?

No. Return to service and quarantine are server authoritative and are unavailable offline rather than queued for later. An offline device cannot establish that equipment is safe, so refusing is the honest answer. Observation work such as checklists, readings, notes and photos does work offline.

What if the test instrument itself is out of calibration?

It is visible rather than silently trusted. Test instruments carry their own calibration status, because a result is only as good as the thing that measured it. A reading from an instrument whose calibration has lapsed is exactly the kind of quiet problem that makes a compliance record look complete and mean nothing.

See it on your equipment

Live in an afternoon, useful the same week. A person replies, usually within one working day.

Contact us