Component Obsolescence and Lifecycle Engineering

Plan for support before choosing technology

Medical devices can remain in use after a component manufacturer has stopped production or a software supplier has ended support. The manufacturer must reconcile the intended service life, production horizon and support commitments with the availability of parts, tools, skills and evidence.

Obsolescence means an item is no longer available or supported in the form needed. Ageing means its characteristics change with time or use. A supply shortage may be temporary. Each can require action, but the response and evidence differ.

Define separately when you expect to stop selling the product, how long installed devices should remain supported, and which parts or services are necessary to maintain safety and performance. A sales discontinuation date does not automatically end responsibilities for devices already supplied.

IEC 62402:2019 provides a general framework for obsolescence management. It complements device risk management, design controls and supplier control; it does not establish medical-device regulatory compliance by itself.

Look beyond the bill of materials

Create a supportability register linked to controlled product configurations. Include direct dependencies and critical dependencies of suppliers.

• Electronics: microcontrollers, sensors, memories, displays, power supplies, batteries and connectors.
• Mechanical and material items: moulds, seals, coatings, adhesives, specialist materials and consumables.
• Software: operating systems, libraries, drivers, third-party software, cryptographic services and cloud interfaces.
• Production and verification: programming tools, compilers, test fixtures, calibration equipment, reference materials and licence servers.
• People and services: specialist knowledge, repair capability, supplier processes and external support.

A component may remain purchasable while the compiler, programmer or production test system needed to use it becomes unsupported. Include reproducible build instructions and retained tool versions where licences permit.

Monitor warnings and prioritise by consequence

Assign an owner to receive and assess product change notices, discontinuation notices, last-order dates, final-delivery dates and software support announcements. Check that notices reach engineering and quality rather than remaining in a purchasing mailbox.

Record the exact affected manufacturer part numbers and revisions, configurations, stock, installed population, approved alternatives and evidence dependencies. Confirm whether a notice concerns a die revision, package, manufacturing site or entire product family.

• Consequence: could unavailability affect a medical function, risk control, security, calibration or servicing?
• Exposure: how many products, markets and fielded units depend on the item?
• Alternatives: are replacements approved, technically feasible and available?
• Time: is there enough time for qualification, regulatory assessment and implementation?
• Uncertainty: how credible are demand estimates and supplier commitments?

Use a documented priority and review date. A simple risk score should not hide an imminent order deadline or a dependency with no practical alternative.

Compare the available responses

Compare total cost and remaining life, including verification, tooling, documentation, service, regulatory work and inventory risk. An inexpensive part can create an expensive system change. A stock purchase can buy time, but cannot resolve an unsupported operating system or an unmitigated security vulnerability.

Calculate a last-time buy with explicit assumptions

Separate production demand from service demand. Account for stock already allocated elsewhere, expected yield, repair rates, replacement strategies and uncertainty. Use several demand scenarios rather than treating one forecast as certain.

The allowance and yield are illustrative planning assumptions, not recommended default values. Avoid counting the same loss twice. Recalculate if production, field failure rates or the planned redesign date changes.

Check storage duration, moisture sensitivity, packaging, handling, shelf-life limits where applicable, periodic inspection and any justified requalification. Verify authenticity and traceability through approved sources. Broker stock requires a specific supplier and acceptance assessment; commercial availability is not proof of suitability.

Demonstrate equivalence at system level

Pin compatibility and a similar headline specification do not establish equivalence. Compare the characteristics that matter to the complete device, its manufacturing process and its risk controls.

• Electrical limits, start-up behaviour, current consumption, thermal performance and analogue accuracy.
• Clocking, peripheral behaviour, interrupt timing, watchdogs, reset states and known errata.
• Firmware drivers, compiler assumptions, memory layout, bootloaders and programming interfaces.
• Diagnostic coverage, fault responses, security features and protection of stored records.
• Materials, dimensional tolerances, environmental durability and cleaning compatibility where relevant.
• Production programming, calibration, test coverage, repair and configuration identification.

Build a comparison matrix: old characteristic, new characteristic, device requirement or hazard affected, assessment method, evidence and unresolved question. Absence of an identified difference must be supported by information, not a blank cell.

Use MTL-129 for the controlled change process and MTL-116 for verification and validation planning. Explain which existing evidence remains applicable and why.

Treat software support as a lifecycle dependency

Operating systems, libraries and cloud platforms have support horizons that may be shorter than the device’s intended life. Track maintenance status, vulnerability information, interface changes and the ability to rebuild and deploy a supported configuration.

Ending vendor support does not prove that a device immediately becomes unsafe; it removes an important source of future fixes and assurance. Assess exposure, available controls, monitoring, patch capability and remaining support commitments. Likewise, continued commercial support does not prove that known vulnerabilities are adequately controlled.

Plan migration before a deadline forces an emergency change. Include data conversion, interoperability, update sequencing, failed-update recovery and compatibility with older fielded hardware. Evaluate changes to third-party software through the applicable software lifecycle and cybersecurity processes.

Plan evidence and regulatory decisions before cut-in

Start with the affected requirements, architecture, interfaces, risk controls and prior evidence. Specify required analyses and tests before confirmatory execution. Include boundary conditions, fault behaviour and the actual production configuration.

Possible work includes hardware characterisation, firmware verification, integration testing, risk-control tests, accuracy, runtime, thermal and EMC checks, reliability assessment, production-test qualification and validation of affected user or service tasks. Select and justify the scope; neither repeating every historical test nor accepting one nominal functional test is an automatic answer.

Regulatory reviewers must assess the specific change, device pathway and target markets. For US 510(k)-cleared devices, use the applicable FDA device-change and software-change guidance. A PMA device follows a different change pathway. For EU devices, assess relevant conformity-assessment and notified-body requirements. A supplier-driven change is not automatically exempt from regulatory assessment.

Document whether submissions, notifications or approvals are needed and complete required actions before implementation. Retain the technical rationale when no new submission is required.

Control production, service and the installed base

Define the cut-in by revision, lot or serial number. Decide the disposition of old stock, work in progress, service stock and returned devices. Maintain an approved compatibility matrix for hardware, firmware, accessories and production tools.

• Release the bill of materials, drawings, firmware and relevant manufacturing instructions together.
• Qualify programming and test fixtures; update calibration and acceptance methods where needed.
• Prevent unintended mixing of parts or firmware across incompatible revisions.
• Give service teams clear replacement rules, identification methods and post-repair tests.
• Retain previous configurations and supporting evidence for investigations.
• Monitor the changed population and compare results using appropriate exposure denominators.

A production substitution does not automatically require replacing all fielded devices. Assess the existing population separately for safety, performance, serviceability and support. Conversely, a production-only implementation does not remove a field risk that the assessment has identified.

Worked example: a discontinued microcontroller

Fictional scenario: a released infusion pump uses controller A for motor control, local alarms and event records. Its supplier announces a final-order date in six months. Controller B has the same pin layout, but different peripheral behaviour and reset defaults. A hardware watchdog provides an additional protective function. The intended medical purpose is unchanged.

1. Establish the baseline

   identify affected board and firmware revisions, annual demand, usable stock, service demand and fielded configurations.

2. Buy time deliberately

   evaluate a controlled bridge purchase while the replacement is assessed. Record forecast uncertainty and the redesign schedule.

3. Compare characteristics

   investigate timer behaviour, motor-drive outputs during reset, watchdog interaction, alarm timing, non-volatile memory and power consumption.

4. Update the design

   revise drivers and start-up configuration where necessary. Reassess firmware requirements, interfaces, diagnostics and risk controls. An unchanged software safety class must be justified, not presumed.

5. Verify the system

   test delivery performance across specified conditions, start-up and reset behaviour, alarms, watchdog faults, power interruption, record integrity and relevant environmental and EMC behaviour. Define production and service acceptance tests.

6. Approve the change

   close anomalies, review residual risks, complete market-specific regulatory assessments and release the exact hardware–firmware combination.

7. Implement and monitor

   set a serial-number cut-in, prevent incompatible firmware programming, train service staff and trend performance of the new configuration.

Decision: do not approve B simply because a nominal infusion test passes. Approve it only when the affected requirements, risk controls, manufacturing and service arrangements, and regulatory decisions are supported by evidence. If this cannot be achieved before stock depletion, revisit the bridge strategy or production plan.

Practical exercise: choose and justify a response

A fictional laboratory analyser has 250 usable spare display assemblies. Forecast service use is 70 per year for four years. The supplier offers a final order in eight weeks. An alternative display fits the enclosure but uses a different driver and has a smaller viewing angle. Production of new analysers is expected to end next year; display demand for that production is not included in the service forecast.

1. Calculate the service-stock shortfall without an allowance.
2. List the information missing from a defensible final-order quantity.
3. Compare a bridge purchase with qualifying the alternative.
4. Identify affected requirements, risks and verification or validation activities.
5. Describe configuration controls and decisions needed before implementation.

Keep this output: a one-page decision record with options, assumptions, chosen response, required evidence, owners, deadlines and review triggers.

Review checklist and evidence to retain

Retain the notice, decision record, comparison matrix, demand model, supplier assessment, change request, updated design and risk records, evidence plan and results, regulatory conclusions, approvals and implementation records. Define review intervals and escalate overdue actions.

Authoritative references and related learning

Use the applicable editions and market-specific requirements. These references support the process; they do not replace a device-specific assessment.

• IEC 62402:2019 — Obsolescence management
• FDA — Deciding When to Submit a 510(k) for a Change to an Existing Device
• FDA — Deciding When to Submit a 510(k) for a Software Change to an Existing Device
• MTL-123 — Supplier and Outsourced-process Control
• MTL-129 — Configuration and Change Management
• MTL-116 — Verification and Validation
• MTL-127 — Post-market Support
• MTL-108 — Software Lifecycle
• MTL-109 — Medical-device Cybersecurity