Two Lights, Two Versions: Write the Software Baseline Into the Order

A mixed fleet is a maintenance problem long before it is a cybersecurity problem, and the two lights that boot with different versions are the first symptom. What the factory owes you is a version baseline: one approved production software level, the release notes that say what it changes, the method of updating, and a record that ties each delivered unit to the version it was shipped with. The hospital’s engineering department needs the same information for a different reason, because an equipment file that cannot say what software a device runs is a file that cannot support a fault report, an update plan or an audit.

What the version actually tells you

On most surgical lights and tables the software sits behind the control panel, the handset and the safety functions, and the version number is firmware rather than an application. That matters because the parts a hospital can see, the lamp, the arm, the motor, behave identically across versions, while the parts it cannot see, the control limits, the fault handling and the communication with a pendant or a network, may not. A version difference is therefore not automatically a defect, and it is not automatically harmless either: it is information, and the question is whether anyone has it.

Two units of the same model running different versions is normal in a fleet that was built over several months, and it becomes a problem at three moments. When a fault appears on one unit and the other cannot be used to compare. When the hospital wants to update something and discovers that the update path was never documented. And when the manufacturer changes the baseline without telling anyone, so a reorder six months later arrives with a different behaviour that nobody wrote down.

The baseline record the factory should supply

Four documents make the software manageable, and they should travel with the shipment rather than live in an email. The first is the production baseline: the version that this model is currently built with, with the date it was adopted and the release note describing what changed. The second is a per-serial record: the version each unit was shipped with, which is best presented as a table with serial numbers and versions, because that table is what a hospital’s engineering department files. The third is the update method: how a version is installed, by whom, with what tool, and whether it requires a service visit. The fourth is the version history for the model, so that a device in service can be placed in a sequence rather than in a mystery.

Where the factory cannot produce a per-serial table, the fallback is honest and useful: instruct the receiving engineer to record the version shown at start-up for each unit, with the serial number in the same photograph, and build the table at the hospital. That exercise takes an hour for a shipment and immediately exposes any unit that does not match the rest.

Updates: who does what, and when

An update is an event with a cost and a risk, and both belong in the contract. The cost is the visit, the tooling and the downtime, and on a distributed fleet it is usually the reason updates never happen. The risk is that a version change alters a behaviour the clinical team relies on, which is why an update should never be applied silently during a service call without a note to the user. Write the rules down: updates are notified in advance with a description of the change; updates are applied with the equipment’s history recorded; and a version is not changed during a clinical session or without the engineering department’s agreement.

There is also the question of who owns the update when the equipment is out of warranty. The factory’s answer is often a service price per unit, and the hospital’s answer is often that it will manage the fleet itself if it has the tool and the instructions. Both are legitimate, and the buyer who settles the question at the quotation stage avoids the conversation that otherwise happens when a fault is finally traced to a version difference between two units in the same theatre.

What the hospital’s IT and engineering teams will ask

Two departments will ask questions, and they are not the same questions. Engineering wants the version, the update method and the history, because its job is the equipment file. IT wants to know whether the device is connected to anything, what data it carries, and how the connection is managed, which is the ground covered by the notes on cybersecurity for connected equipment. The buyer’s job is to make sure both sets of answers come from the same document, so that a device is not described as standalone by one department and networked by the other.

Where a device is connected, the version question and the security question meet: an update may be the fix for a cybersecurity finding, which makes the update path a security control rather than a convenience. That is worth one line in the contract with the factory, and it is worth asking before the order rather than after an audit, because the answer determines whether the hospital can maintain the device’s security posture at all.

Two complications the version question always brings

The first is the accessory. A handset, a control panel, a camera or a communication module often carries its own software, and it is updated on its own schedule or not at all. A light whose head runs the current baseline and whose handset runs an older one is a light with two versions, and the documented baseline for a delivered unit therefore has to cover the accessories as well as the main device. Ask for the version list rather than the version, and check it against what the hospital actually uses, because an obsolete handset is the item that gets sent back rather than repaired.

The second is the spare part that arrives with the wrong software. Where a replacement control box or driver is supplied for a unit already in service, that part has to be compatible with the unit’s other components, and compatibility is a version question rather than a shape question. The buyer’s protection is the same as in the delivery case: the replacement part should be supplied with its version identified, and the factory should confirm compatibility with the serial number it is being fitted to. On a fleet of twenty units built over two years, that confirmation is the difference between a repair and a return shipment.

What a version difference costs in practice

The cost appears in three places. Engineering time for comparison, because diagnosing a fault on one unit normally starts by comparing it with another, and units that run different versions cannot be compared reliably for the functions that changed. Update visits, because a fleet that has drifted out of step has to be brought back, and each visit is a scheduled slot with the equipment out of service. And occasionally a clinical consequence, where a behaviour that the clinical team learned on one version does not occur on another, which is the case that makes the whole question worth the paperwork.

None of those costs is large enough to appear in a business case, and all three are large enough to be avoided by a table with serial numbers in it. That is the awkward truth about documentation work: the value shows up as the problems that did not happen, and the only way to demonstrate it is to keep the file that would have been needed if they had.

The buyer’s handling checklist

Seven steps make the delivered fleet legible. Ask for the baseline and the per-serial table at the order stage rather than at delivery. Photograph the version screen for every unit at commissioning, with the serial number visible. File those photographs per serial number in the equipment record. Ask the factory for the update method in writing, with the tool and the competence required. Agree the notification rule for baseline changes. Put the version in the acceptance test record, which is the discipline described in the remote diagnostics note, since a fault report without a version is a fault report that starts with a guess. And review the table before the next order, so a reorder is placed against a known baseline rather than an assumed one.

None of this is exotic, and all of it depends on the factory being able to say what it ships. A supplier who answers the version question with a model name has told you that software is outside its documentation, which is a risk you can price; a supplier who sends a table has told you that a fleet problem can be diagnosed in a morning. The difference is a page, and it is the page that decides whether the two lights in your next shipment boot the same way. Ask the question in your next request for quotation, in writing, and keep the answer with the order file.