Software is not an accessory to a medical device. It is part of the configuration that was assessed, and changing it can change the device\’s behavior, its compatibility and its regulatory position. A used unit\’s firmware version is therefore part of what the buyer is buying, not a detail to fix after delivery.

Why Software State Is Part of the Device

Software state is part of the device because the version, configuration and enabled features determine how the unit performs. A different version can change the user interface, the alarms, the output or the compatibility with accessories.

A device that was assessed with one software version may not be identical with another. The manufacturer\’s instructions, the regulatory clearance and the service documentation may all be tied to a version range. A buyer who treats the software as a generic IT layer can miss the fact that the unit has moved outside the configuration that was verified.

A version is also a compatibility statement. The software may be designed for a specific hardware revision, a specific accessory or a specific network interface, and the combination is what the manufacturer supports. The practical consequence is that the version belongs in the asset register, the inspection report, the bill of sale and the maintenance record. It should be read from the device, not from the seller\’s description. The regulatory context varies by market, from FDA rules and the EU Medical Device Regulation 2017/745 to MHRA, TGA and PMDA requirements, while WHO guidance frames the shared principles; the version should be assessed against the rules of the market where the unit will operate.

Version, Configuration and Compatibility

Version, configuration and compatibility are different questions. The version is the software release; the configuration is the set of options and modules enabled; compatibility is whether the version works with the hardware, accessories and network around it.

A unit may run the correct version but the wrong configuration, or a compatible version that is no longer supported. A new handpiece, a different detector or a network interface may require a minimum version. An update may fix one compatibility problem and create another.

The buyer should ask for the version history, the current configuration and the manufacturer\’s compatibility statement for the accessories supplied. Where the unit is connected to a network, the compatibility question extends to the hospital\’s IT environment and the manufacturer\’s supported integration. The buyer should record the version before and after any demo or service visit. A unit can be updated during a demonstration and then sold as the version the buyer first saw. The version at the point of sale, not the version in the brochure, is the one that matters.

Who May Apply an Update

The manufacturer, an authorized service organization, or a trained biomedical team acting under the manufacturer\’s instructions may apply an update. A buyer or a third-party technician should not install software unless the manufacturer permits it.

The permission is not only a warranty question. An unauthorized update can create a different device configuration, affect the regulatory status and leave the unit outside the manufacturer\’s support. The entity that performs the update may also take on responsibilities for validation and records.

The service agreement should state who is authorized to update the software, what evidence is required and who bears the cost if an update fails. A remote update performed by the manufacturer is still an update and should be recorded in the same way as an on-site visit. The authorization question also depends on where the update comes from. A manufacturer\’s download portal, a service laptop or a USB drive can all deliver a release, but only the manufacturer\’s channel carries the assurance that the file is genuine and complete. A buyer should not accept a copied installer or an unverified patch.

Validation and Re-Verification After Update

An update should be followed by the validation or re-verification the manufacturer specifies. That may include a software self-test, a performance check, a safety test or a full acceptance test, depending on the change and the device.

The verification should confirm that the unit still meets the manufacturer\’s criteria and that the intended functions work after the update. The record should show the version before and after, the test performed, the result and the person who approved it. The manufacturer\’s documentation remains the final authority on test criteria.

An update that changes clinical behavior may require more than a technical check. The clinical team may need to review the workflow, and the biomedical team may need to update the device inventory and training records. The update is not complete until those steps are closed. A version number without a validation record is just a number; the record is what makes the software state credible. The re-verification should be proportionate to the change. A minor patch may need a self-test and a version check; a major release may need a full performance verification and a review of the instructions. The manufacturer\’s release notes are the starting point, and the service manual is the authority.

Records That Should Travel With the Unit

The records should let the next owner reconstruct the software state and the validation history. They should include the version history, the source of each update, the validation results and the configuration at the time of sale.

When Updating Is Not Permitted

Updating is not permitted when the manufacturer prohibits it, when the unit is outside the supported hardware configuration, or when the update would change the intended use or performance beyond the cleared configuration.

An update may also be inappropriate when the unit is no longer supported, when the software is unlicensed or when the update requires a hardware change that has not been made. A seller who offers to \”upgrade\” an unsupported unit may be creating a device the manufacturer will not service. A seller may offer an update as a value-added service, but the buyer should ask whether the resulting configuration is supported. An update that is technically possible but not supported can leave the unit in a state the manufacturer will not service, which is worse than the documented older version.

The buyer should ask what the update changes and whether the manufacturer supports the resulting configuration. If the answer is unclear, the safer position is to keep the unit at the documented version and record the limitation, rather than install a change that cannot be validated.

Cyber Patches Versus Feature Updates

Cyber patches and feature updates are different in urgency and effect. A security patch may be urgent and narrow; a feature update may change behavior, add functions or alter the user interface. Both require validation, but the scope and the risk differ.

A security patch should be assessed against the manufacturer\’s advisory and the deployment. If the device cannot be patched, compensating controls may be needed, and the residual risk should be recorded. A feature update should be assessed for compatibility, training and clinical workflow before it is applied.

The buyer should not assume that the latest version is always the right version. A newer release may be incompatible with an accessory or a network, and the manufacturer may support only a defined range. The decision should be based on the manufacturer\’s documentation, not on version numbers alone.

Deciding at Purchase Time

The purchase decision should include the software support position: the current version, the supported range, the update path and the cost of any required change. A unit that is cheap but stuck on an unsupported version is a different lifecycle cost from one that can be updated.

The buyer should ask who will maintain the software, how security patches will be delivered and whether the manufacturer still supports the model. For a used unit, the answer may depend on the original manufacturer\’s service policy and the availability of authorized service. The purchase file should also record the cost of staying current. If a required update is chargeable, the buyer should know the price before the purchase, not after. If the update is not available, the residual risk should be priced into the offer.

The remote software upgradeability guide covers the delivery side, and the Knowledge section has related software and records guides. If you are assessing a unit and want the software state reviewed before purchase, send the version and service records to the HHG team.

{ \”@context\”: \”https://schema.org\”, \”@type\”: \”FAQPage\”, \”mainEntity\”: [ {\”@type\”: \”Question\”, \”name\”: \”Can I update firmware on a used medical device myself?\”, \”acceptedAnswer\”: {\”@type\”: \”Answer\”, \”text\”: \”Only if the manufacturer permits it and you follow the manufacturer\’s instructions and validation requirements. An unauthorized update can change the device configuration, affect regulatory status and void support. A trained biomedical team acting under the manufacturer\’s procedure is different from an ad hoc installation.\”}}, {\”@type\”: \”Question\”, \”name\”: \”Does a software update require re-validation?\”, \”acceptedAnswer\”: {\”@type\”: \”Answer\”, \”text\”: \”Usually yes. The manufacturer specifies the validation or re-verification needed for the change, which may range from a self-test to a full performance and safety check. The record should show the version before and after, the test result and the person who approved it.\”}}, {\”@type\”: \”Question\”, \”name\”: \”What software records should come with a used device?\”, \”acceptedAnswer\”: {\”@type\”: \”Answer\”, \”text\”: \”Ask for the current version and configuration, the version history, the update source and authorization, validation results, the compatibility statement, the service report and the cybersecurity patch status. These records show whether the unit is in a supported and documented state.\”}}, {\”@type\”: \”Question\”, \”name\”: \”Is the latest firmware always better?\”, \”acceptedAnswer\”: {\”@type\”: \”Answer\”, \”text\”: \”No. A newer release may be incompatible with an accessory or a network, or may be outside the configuration the manufacturer supports. The right version is the one supported for the hardware, accessories and intended use, as documented by the manufacturer.\”}} ] }