...

The fix for drifting presets is not a longer list of questions for the factory. It is three things the hospital can hold: a register that says which profile version each department has approved, a service boundary that keeps calibration parameters out of clinical hands, and a restore test that proves an approved profile can be put back on a table after a controller swap or a factory reset.

Field service engineer commissioning an electric operating table, the moment when clinical presets and service parameters are first separated
Commissioning is where the two parameter sets are still distinguishable. After a year of service visits they are only distinguishable if someone wrote them down.

What Profile Drift Actually Is

A position preset is a stored target: a height, a backrest angle, a leg section angle, a tilt. Drift means the stored set on a table no longer matches the set the department approved. It arrives by two routes. Clinical drift is a user saving over an existing preset because the interface lets a normal adjustment end in a permanent change. Service drift is a technician restoring defaults, replacing a controller or loading firmware, and leaving the table with a clean but unfamiliar set. A third case looks like drift and is not: a surgeon adjusting a table for one patient, which should never touch a stored preset at all. Keeping those three apart is the first design decision, because each needs a different control. Without the register there is nothing to restore to. Without the boundary a technician can wipe a department’s work while doing his job properly. Without the restore test the register is a document nobody has ever used.

Symptoms, Causes and Handling

Drift is usually reported as a complaint about a button rather than a complaint about a setting. The table maps the reports that come back from theatres to the underlying cause and to the handling that leaves a usable record.

What staff report Likely cause Handling and record entry
The same preset button gives a different position on two tables One unit was overwritten during a case and saved Compare both tables against the register version, restore the approved set, log the unit and the deviation
Presets changed after a service visit Defaults restored or a controller replaced without reloading the approved set Treat as a service-induced change, restore from file, require the service report to name the profile version left on the table
One department’s “improved” preset appears on every table A shared profile set with no named approver Name the approver per department, lock the approved set, require save-as-new for experiments
The engineer cannot calibrate without editing a clinical preset Clinical and service parameters sit in one editable set Ask for a separate service mode with its own credential, and record what it is allowed to touch
Nobody can say which version is currently approved No version or approval field on the profile Add version and approval date to the register before the next service visit, not after

The last row is the one that decides whether the other four can be fixed. A profile with no version cannot be restored to, because nobody knows what “correct” was on the day it was approved.

Checking the Control Layer, Item by Item

Three checks cover most of the control layer. Each produces a written answer from the factory, and each answer belongs in the technical file rather than in an email thread.

Accounts and Roles

Ask whether the controller supports individual accounts rather than one shared code per department, and ask for the role list by name: clinical user, supervisor, biomedical engineering, factory service. The point is not sophistication for its own sake. It is that the only way to know who changed a preset is to know who was logged in, and a shared code makes that impossible. Ask too what happens when a staff member leaves: can the account be removed, and does removal leave the presets intact. A control design that cannot answer that question will be managed by changing the department code once a year, which protects nothing and breaks the audit trail on purpose. The usability standard for medical devices, IEC 62366-1, treats this kind of access design as part of use-error control rather than as an IT preference, which is a useful argument when the specification is reviewed by a clinical committee rather than by IT. The IEC 62366-1 usability engineering standard sets out that framing.

The Service Mode Boundary

Service parameters and clinical presets should not live in the same editable set, and a service mode should not be reachable through the ordinary clinical interface. Ask how service mode is entered, whether it needs a separate credential, a hardware key or a one-time code, and whether entering it can change a clinical preset at all. Then ask the awkward question: can a service action change a clinical preset accidentally, through a default restore or a firmware load. A factory that says no should be able to describe the test that shows it. This is the boundary that protects the department, because the alternative is a rule in a binder saying that engineers must not touch presets, which is not a control.

Restore After a Reset or Controller Swap

The restore path is where most fleets fail quietly. Ask for the exact steps to export the approved profile set, and the exact steps to load it back. Then run it once, deliberately, on a table that is not in use: save the approved set, reset the controller, restore, and verify each stored position against the register. Do the same when a controller board is replaced, because a spare board often arrives blank or with factory defaults, and the engineer’s job is to finish the repair, not to rebuild a department’s presets from memory. The record of that test belongs in the service file, and the same file should say who is allowed to perform it.

The Profile Register Your Department Owns

The register is one page per department per table model, and it is the hospital’s document, not the factory’s. It carries the profile identifier, the version, the approval date and the name of the approver, a short description of each stored position in the department’s own language, the tables that carry that version, and the date each table was last verified against it. The stored values themselves can sit in an attachment, exported from the controller, so the register stays readable.

Two rules keep the register alive. First, a change to a preset is a change to the register, with a new version and an approval, so the version number always means something. Second, every service visit ends with a comparison: the engineer or the biomedical technician reads the profile version off the table and writes it next to the version in the register. A mismatch is not a fault, it is a finding, and it is resolved before the table goes back into the list. Our guide to the preventive maintenance schedule a manufacturer should supply is the natural place to hang that comparison, because the visit already exists and the engineer is already at the table.

Service Visits and the Code That Must Not Travel

Service credentials have a habit of becoming territory-wide. One engineer is trained, one code is issued, and within two years every dealer technician in the region uses the same code on every table. The hospital then has no way to know who entered service mode, and the factory has no way to revoke access that has already spread.

Ask for per-person service accounts with an expiry, a list of who currently holds access, and a written revocation step for when an engineer leaves the dealer. Ask whether the hospital can see, from the table or from a service report, which account entered service mode and when. If the controller keeps an audit log, ask how it is exported and how long it is kept, because a log that only the factory can read is an assertion rather than evidence. Tie the whole arrangement to the service agreement rather than to a purchase order, and use the same discipline you would apply to fault codes in a dealer agreement: named codes, named owners, a defined escalation. The training and competency records for the technicians who hold those accounts are the other half of the same control.

What to Put in the Service Contract

Four clauses carry most of the weight, and none of them is unusual enough to slow a negotiation. First, the manufacturer states that service actions do not alter approved clinical presets, and names the test that demonstrates it. Second, any action that does alter them requires the approved set to be restored before the table returns to use, and the service report records the profile version left on the table. Third, service access is per person, time limited and revocable, with a current holder list supplied on request. Fourth, the hospital may export and reload its own profile set without factory involvement, using a documented procedure. The last clause is the one that turns the register into an asset the hospital controls, and it is also the clause most often missing, because manufacturers assume the hospital will call them for anything involving a controller.

Closing Perspective

Presets are small data with a long memory. A department that loses its approved set does not lose a button, it loses the ability to say what its standard setup was, and that affects training, audits and every conversation about why two tables behave differently. The register, the boundary and the restore test are unglamorous, and together they cost a few hours at commissioning plus a line in every service report. What they buy is a fleet where a profile version is a fact rather than a recollection. Start with the register, because it is the only one of the three the hospital can build without the factory, and it is the one that makes the other two worth asking for. A table that can be restored to a known set is also a table that can be moved between theatres without losing its adjustment, and that is the same guarantee in a different room.

Leave a Comment

Back to top
Need a fast quotation? Chat with our export team on WhatsApp.