Remediation Example

Legacy Medical Device Software Remediation

Assessment, remediation planning and technical support for legacy software under IEC 62304 expectations

Many medical device manufacturers operate legacy software that has grown over years and no longer matches current documentation, architecture descriptions or verification expectations.

This becomes critical when software has to be maintained, transferred, extended, prepared for audit, or aligned with IEC 62304 and related quality expectations.

Radius Z supports focused remediation activities: technical assessment, architecture reconstruction, remediation planning, verification review and targeted engineering support.

Typical situations

  • legacy codebase with unclear software item boundaries
  • software architecture not reflected in current documentation
  • missing or weak traceability between requirements, software items and tests
  • insufficient unit, integration or regression test coverage
  • product changes accumulated without structured software documentation updates
  • need to determine whether documentation update is sufficient or refactoring is required

Service phases

Phase 1 - Technical Assessment
 
  • review of available software documentation and selected code areas
  • reconstruction of relevant architecture and software structure
  • assessment of software item boundaries and technical documentation consistency
  • review of current verification landscape
  • identification of major remediation gaps and priorities
Phase 2 - Remediation Design
 
  • definition of remediation scope and priorities
  • distinction between documentation-only updates and required code changes
  • verification improvement concept
  • prioritized remediation backlog
  • proposal for phased execution
Phase 3 - Technical Remediation Support
 
  • support for internal engineering teams during remediation
  • targeted architecture and refactoring guidance
  • support in restructuring verification activities
  • review of technical implementation decisions
  • contribution to documentation and engineering alignment
Typical outcome: controlled technical progress with reduced remediation risk

Why Class B/C devices often require technical remediation

For software safety classes B and C, remediation often goes beyond documentation updates and may require technical restructuring, verification redesign and targeted code changes. The actual scope depends on device context, software complexity and existing engineering assets.

Commercial model

Typical commercial setup 

  • Initial Technical Assessment
  • Assessment + Remediation Plan
  • Ongoing Technical Support 

Final scope depends on device class, codebase size, documentation quality and existing verification assets.

Request an initial technical review

If your legacy device software no longer matches the expected level of architecture clarity, verification structure, or documentation consistency, the first step is a focused technical review. This helps define whether remediation can stay documentation-based or requires technical changes.
A short written project outline is enough for an initial discussion.

Contact

For initial discussions, please send:

  • a short device description
  • current software situation
  • main remediation concern
  • available artifacts, if known

Konstantin Mirny
k.mirny@radius-z.de
Linkedin: Konstantin Mirny

 

 

Who delivers the work

Konstantin Mirny is an embedded software architect and engineering consultant with 20+ years of experience in complex device software, including regulated and safety-relevant systems.
The work focuses on technical remediation of legacy software: architecture reconstruction, verification-oriented analysis, remediation planning, and support for targeted implementation changes.

  • embedded and device software architecture
  • legacy code understanding and restructuring
  • verification-aware engineering support
  • work in regulated development environments
  • cooperation with internal engineering, quality and regulatory teams
See remediation example
When is Phase 1 enough?
 
Phase 1 is enough when the main need is to understand the current software structure, identify the main remediation gaps, and define a realistic next-step plan. It is often used to decide whether the remediation can remain limited to documentation updates or requires technical changes.
When does remediation require code changes?
 
Code changes are usually required when the current software structure does not support clear software item boundaries, interface definition, traceability, or practical verification. For higher-risk systems, documentation updates alone are often not sufficient.
Can this be done with an internal team?
 
Yes. The work can be delivered as an external assessment, as a remediation plan for the internal team, or as targeted technical support alongside internal engineering and quality functions.