MedDeviceGuide: Recording Configuration After a Software Restore

This article answers one healthcare technology management (HTM) job: after an authorized original equipment manufacturer (OEM) software or configuration restore, which fields identify the restored software and configuration, which fields identify the unchanged asset, and what the responsible acceptance reviewer still cannot verify. It is an after-restore provenance worksheet. It is not a restore procedure, not a remanufacturing classification tree, and not a generic work-order contents list.

The scenario question is: after an authorized service restore, how should HTM distinguish the restored software and configuration evidence from the asset serial identity and document what the responsible acceptance reviewer still cannot verify? The chassis serial number can remain exactly the same while the installed software version, configuration, or export identity changes or remains unread. Treat the serial as hardware identity only. Record, in separate fields, the approved restore source and version actually used, any configuration or export identity, the time and authorized action, whether OEM acceptance evidence exists, and every unresolved deviation.

MedDeviceGuide is a publication. It is not a service contractor, not a regulator, and not a source of restore authority. MedDeviceGuide's field-service traceability page for software-enabled devices is adjacent manufacturer quality-system background for multi-component version strings and complaint-linked service logs. It does not authorize this restore, does not prove that a hospital backup is an OEM-authorized source, and does not close a hospital acceptance record.

Copying a chassis serial number into a work order records hardware identity. It does not record a restored software version. The public legal split is in 21 CFR part 801 labeling rules, not in a hospital form template. The Electronic Code of Federal Regulations (eCFR) displays used here are unofficial; Title 21 was accessed 10 September 2026.

21 CFR 801.3 defines a unique device identifier (UDI) as an identifier that adequately identifies a device through its distribution and use by meeting 21 CFR 830.20. A UDI is composed of a device identifier—a mandatory, fixed portion that identifies the specific version or model of a device and the labeler—and a production identifier—a conditional, variable portion that identifies one or more of the following when included on the label: (i) the lot or batch within which a device was manufactured; (ii) the serial number of a specific device; (iii) the expiration date of a specific device; (iv) the date a specific device was manufactured; and (v) for an HCT/P regulated as a device, the distinct identification code required by 21 CFR 1271.290(c).

Serial number and lot or batch are different production-identifier elements. The same section defines lot or batch as:

one finished device or more that consist of a single type, model, class, size, composition, or software version that are manufactured under essentially the same conditions and that are intended to have uniform characteristics and quality within specified limits.

Software version in that definition is a manufacturing-grouping attribute for finished devices of a single software version. It is not a substitute for recording the restored version actually present after service, and it is not the serial-number field. Version or model means all devices that have specifications, performance, size, and composition, within limits set by the labeler. A serial number on the chassis is therefore not the software-version field.

21 CFR 801.40(b) requires every UDI to include a device-identifier segment. Whenever a device label includes a lot or batch number, a serial number, a manufacturing date, an expiration date, or an HCT/P distinct identification code, the UDI must include a production-identifier segment that conveys such information. If the label includes a serial number, copying that serial into a work order records the serial production identifier. It still does not record a restored software version, a configuration-export identity, or OEM acceptance of the restore source.

21 CFR 801.50 applies to stand-alone software regulated as a medical device. It does not automatically label software that is only a component of a hardware device. Under 801.50(a), stand-alone software that is not distributed in packaged form (for example, when downloaded from a website) is deemed to meet the UDI labeling requirements of Subpart B if it complies with 801.50(b) and conveys the version number in its production identifier. 801.50(b) requires stand-alone software regulated as a medical device, whether or not distributed in packaged form, to provide its unique device identifier through either or both of: an easily readable plain-text statement displayed whenever the software is started; or an easily readable plain-text statement displayed through a menu command (for example, an About command). 801.50(c) allows stand-alone software distributed in both packaged and unpackaged form to be identified with the same device identifier. Hardware UDI or serial identity does not substitute for that version disclosure after a restore of stand-alone software.

FDA's Unique Device Identifier System: Frequently Asked Questions, Vol. 1 (issued 20 August 2014) states, in Question A.9, that the UDI Rule does not provide any special requirements for a device that contains software as a component of the device, but does require stand-alone medical software to be labeled with a UDI. Unpackaged stand-alone software must convey the version number in its production identifier. After an embedded-software restore, the chassis serial can remain unchanged while the installed version is still unverified unless it is read from the device and recorded separately. Do not apply 801.50 as if it automatically labeled component software on a hardware chassis.

FDA's Unique Device Identification System: Form and Content of the Unique Device Identifier guidance (issued 7 July 2021) restates that if the UDI of stand-alone software required to bear a UDI includes a software version on the label, that version must be conveyed through the production identifier, citing 21 CFR 801.3 and 801.50. Those are labeling rules. They are not proof that a hospital backup matches the labeled version.

21 CFR 830.50(a) states that whenever you make a change to a device that is required to bear a UDI on its label, and the change results in a new version or model, you must assign a new device identifier to the new version or model. The UDI FAQ, Question A.10, quotes that sentence and adds that the labeler has the responsibility to determine whether device upgrades or variations constitute different models or versions, and that a software update will require a new device identifier only if the upgrade results in a new version or model. Those are labeler duties. They are not HTM restore commands, not proof that a hospital backup matches the labeled version, and not a new-device-identifier assignment the acceptance reviewer can complete from a copied serial number.

FDA issued Remanufacturing of Medical Devices, guidance for industry, entities that perform servicing or remanufacturing, and FDA staff, on 10 May 2024 (docket FDA-2018-N-3741). The landing page banner is content current as of 9 May 2024; the PDF is issued 10 May 2024. The document is current Agency thinking. It does not establish rights and is not binding on FDA or the public; an alternative approach may be used if it satisfies applicable statutes and regulations. Guidances should be viewed only as recommendations unless a specific regulatory or statutory requirement is cited. The word should means suggested or recommended, not required. Do not convert any software-activity example in the guidance into a hospital legal duty, a universal release criterion, or permission to restore without OEM authorization.

The hardware-component flowchart in the guidance should not be applied to changes involving software. Section VII instead identifies certain software activities that are likely not remanufacturing because they generally do not significantly change the performance or safety specifications of the device. The listed activities include:

• Activities performed on behalf of or otherwise explicitly authorized by the OEM that return the legally marketed device to its performance and safety specifications, or maintain those specifications and intended use;

• Implementing updates and upgrades authorized, approved, or otherwise provided by the OEM;

• Running software-based hardware diagnostics;

• Assessing for viruses, malware, and other cybersecurity-related issues;

• Reinstalling OEM software to restore original performance and safety specifications;

• Reverting software to a previous configuration;

• Installing cybersecurity updates that are authorized by the OEM;

• Turning on or off connectivity features (for example, Wi-Fi and Bluetooth connections) consistent with OEM intended use;

• Performing data backup and recovery operations;

• Assessing software inventory;

• Collecting system logs;

• Managing user accounts;

• Accessing diagnostic and repair information.

Other activities involving changes to software are likely to significantly change a device's performance or safety specifications, such that the activity is likely remanufacturing. Any activity involving software changes that significantly modifies a device's intended use would be remanufacturing. This article assumes the restore was already authorized as servicing. It does not retell the published six-principle decision tree, and it does not decide whether a non-OEM patch is remanufacturing.

The same guidance encourages OEMs, as an industry best practice, to provide servicing instructions for reusable devices. OEM labeling of reusable devices should include at least the following, as applicable: a description of key performance and safety specifications; critical technical or functional specifications; recommended maintenance activities and schedule; recommended troubleshooting steps, routine testing, and acceptance criteria to confirm that the device remains within its performance and safety specifications; precautions and warnings relevant to servicing; and the version number and release date of software. FDA's 9 May 2024 press announcement restates that those labeling recommendations are a best practice and are not intended to encourage disclosure of trade secrets. Those labeling fields are inputs to a restore record. They are not proof that a given backup, export, or media set was the OEM-authorized source, and they do not replace OEM acceptance evidence or unresolved-deviation fields.

As manufacturer quality-system background on field-service traceability for software-enabled devices, MedDeviceGuide discusses multi-component version strings and complaint-linked logs. That publication can show how a manufacturer quality system traces those strings. It cannot authorize this restore, cannot certify a hospital-made image, and must not be cited as a restore-permission source. Do not recast that manufacturer guide as this HTM provenance worksheet.

FDA's remanufacturing-and-servicing page includes an update dated 2 February 2026 stating that the Quality Management System Regulation became effective that day, amending 21 CFR part 820 and incorporating ISO 13485:2016. The page repeats that FDA focuses on the specific activities an entity performs on a particular device, not on self-identified designation as a servicer or remanufacturer. That update is freshness context. It does not convert a hospital HTM restore worksheet into a remanufacturer obligation under the Quality Management System Regulation.

A restore provenance record is not a return-to-service finding. 42 CFR 482.41(d) is the current facilities standard. 42 CFR 482.41(d)(2) requires that facilities, supplies, and equipment must be maintained to ensure an acceptable level of safety and quality. The eCFR Title 42 display used here is unofficial and was accessed 10 September 2026.

CMS Survey-and-Certification memorandum S&C: 14-07-Hospital, Hospital Equipment Maintenance Requirements, revises the Appendix A interpretive guidelines for 42 CFR 482.41 equipment maintenance (then Tag A-0724 at §482.41(c)(2)). Medical equipment in the memo includes devices intended for diagnostic, therapeutic, or monitoring care, with examples such as IV infusion equipment, ventilators, laboratory equipment, and surgical devices. The memo states:

All equipment must be inspected and tested for performance and safety before initial use and after major repairs or upgrades.

QSO-25-24-Hospitals, original release 5 September 2025, recodifies Tag A-0724 to §482.41(d)(2) and still cites S&C memo 14-7. In the QSO-25-24 interpretive text, all equipment should be inspected and tested for performance and safety before initial use and after major repairs or upgrades, and all equipment must be inspected, tested, and maintained to ensure its safety, availability, and reliability. Quote should as should and must as must. The inspect-and-test-after-major-repair sentence in QSO-25-24 is interpretive should language. Do not collapse it into the S&C 14-07 must sentence, and do not call the QSO should sentence a statutory restore-release rule.

Neither the regulation nor those interpretive documents defines every device-class threshold for major repair. This article does not invent a universal numeric definition, and it does not treat every software restore as a defined major repair. If the hospital program treats the work as a major repair or upgrade, inspect-and-test evidence for performance and safety is a separate finding. A restore record that copies model and serial without OEM acceptance evidence, configuration or export identity, or unresolved deviations is not that inspect-and-test finding. A configuration-restore log does not replace later performance and safety testing, and it does not recast published electrical-safety or infusion-pump verification methods as this worksheet.

Keep chassis identity, restored source and version, configuration or export identity, time, authorized action, OEM acceptance evidence, and unresolved deviations as different fields. Mark blank cells as unknown, not as pass. The matrix below, and the packet that follows, are explicitly hypothetical. They use obviously fictional identifiers. They are not an actual device, backup, OEM approval, test result, or release-to-service decision. No restore command, credential, or pass stamp is included.

The table is the required before/after provenance matrix: at least four columns and four substantive rows, with blank cells marked unknown. The fictional packet below uses the same identifiers and the same unknowns. It is not a completed acceptance decision.

The point of the matrix is the last column. An acceptance reviewer can record observed identity fields without filling unknown cells with a pass. The groups below are worksheet prompts for this restore record. They are not a regulatory taxonomy and not universal release criteria.

1. Source and version identity. If the About or startup string was not read, record unknown. If a version string was read, record it as observed and record separately whether OEM acceptance evidence exists for the source actually used. A labeled version in reusable-device labeling is an input. It does not prove that this backup, export, or media set was the OEM-authorized source.

2. Configuration or export identity. If no configuration or export identifier was captured before or after the restore, leave both cells unknown. Do not copy the chassis serial into that field. Manufacturer quality-system discussion of multi-component version strings explains why those strings exist; it does not fill a blank hospital export field.

3. Inspect-and-test remainder. If the hospital program treats the work as a major repair or upgrade, S&C 14-07 still uses must for inspection and testing for performance and safety after major repairs, while QSO-25-24 uses should for that inspect-and-test sentence. A restore log that copies model and serial is not that finding. Do not invent a numeric major-repair threshold, and do not issue a return-to-service decision from the provenance worksheet.

This restore worksheet is a different job from three published Med Device Repair articles. Medical equipment service records: what a work order must contain is a generic work-order contents list. Medical device servicing versus remanufacturing: how to draw and document the boundary is the May 2024 activity-classification tree. CMMS medical equipment inventory: unique identification and survey requirements is survey unique identification versus manufacturer serial on the asset master. None of those articles is this before/after restore-source and configuration-export matrix.

After an authorized restore, keep serial, restored source and version, configuration or export identity, time, authorized action, OEM acceptance evidence, and unresolved deviations in separate fields. Leave unknown cells unknown. The restore log is provenance. It is not permission to treat a hospital backup as OEM-authorized media, and it is not inspect-and-test after major repair.