Medical software vendors whose products have been on the market for decades.

C++ and MFC desktop applications sold for fifteen to thirty years depend on a few senior developers, an old toolchain and a software file written for the MDD. Hospitals ask for FHIR and DICOMweb, and every change has to keep the certified state. We take over the code, move the build to a current toolchain and record today's behaviour in tests before the first change.

Book a 30 minute call Write to us

Systems: C++ · MFC · .NET · DICOM · HL7
Standards: IEC 62304 clause 4.4 · ISO 13485 · EU MDR · FDA
First step: Free 30 minute call with engineering

The software path

How a change reaches a product that has been on the market for decades.

Requirement

The original requirements are in old tickets and in the memory of a few senior developers.

ImprovementRequirements are written down and traced to the code, so a new request can be checked against them.

Design

The architecture exists only in the source tree, so it is worked out again before each change.

ImprovementArchitecture and detailed design are reconstructed once and kept in your documents.

Implementation

The code needs old compilers, and few developers want to work on it.

ImprovementThe build runs on a current toolchain, so new developers can work on the code.

Verification

There is no automated test suite, so every release repeats the manual regression.

ImprovementTests record today's behaviour and run automatically on every change.

Release

Each release needs an impact analysis against a software file written for the MDD.

ImprovementEach release ships with its impact analysis, and the documents are brought up to the MDR technical documentation for the MDR certificate.

Field support

Memory growth and crashes show up at customer sites. They do not reproduce in the lab and stay open.

ImprovementField defects are reproduced on a build that matches the field version and fixed with a regression test.

Change

Tenders ask for FHIR and DICOMweb, and the product speaks HL7 v2 and DIMSE.

ImprovementFHIR and DICOMweb are added next to the existing interfaces, so installed sites keep working.

The goal

A product that stays on the market and can keep changing.

For the manufacturer

A significant change assessment with every release
Knowledge of the core written down in your documents
New developers who can work on a current toolchain

For hospitals and clinicians

An application that stays stable through a long session
Current interfaces that connect to the hospital's systems
Updates that keep the behaviour they rely on

For patients

Fixes for the software their hospital relies on that arrive quickly
New functions that improve their care reaching the hospital sooner
Results checked against the recorded behaviour after every update

Problems and solutions

What we hear, and what we do about it.

The people who designed the core have left.

We reconstruct the architecture and the detailed design from the source tree and the build. Your senior developers fill the gaps in short sessions, and the result goes into your documents.

Legacy modernisation and takeover

The application slows down or crashes at customer sites, and we cannot reproduce it.

We reproduce the field conditions on a build that matches the field version, replay the workflows from the field reports and analyse crash dumps where they exist. Each defect is fixed together with a regression test.

Legacy modernisation and takeover

We cannot touch the core without reopening the certification.

Before the first change we record today's behaviour in tests. Each release gets its impact analysis and an answer to the significant change question.

IEC 62304 gap analysis

A rewrite will run for years and throw away the verification evidence we have.

The core stays in place. First we move the build to a current toolchain and write the regression tests. A module is replaced only after it is understood and tested, and every step is a normal release with its own impact analysis and written scope.

How we work

Hospitals ask for FHIR and DICOMweb, and our interfaces speak HL7 v2 and DIMSE.

We add the new interface as a separate layer next to the HL7 v2 and DIMSE paths that installed sites rely on. Those paths keep working, the new layer gets its own authentication, encrypted transport and threat model (a structured analysis of how the device could be attacked) update, and we test it against the systems on site.

Interoperability

The software file was written for the MDD, and the notified body will find the gaps.

The gap analysis (a review of what is missing against the standard) reads the code, the documents and the process. For software already on the market we write the report as part of the record that clause 4.4 of IEC 62304 asks for, with the review of field feedback, the plan to close the gaps and the rationale for continued use. The documents then follow your templates, reviews and approvals.

Retrospective IEC 62304 documentation

The third party libraries are years behind their current versions.

We list every third party library in the SBOM (software bill of materials, the list of every software component in the build) and record each one as SOUP (software of unknown provenance, meaning third party code used in the device). Libraries are updated where it is safe, and each update is tested like any other change.

Medical device cybersecurity

Code review

What a review finds in old C++ code, and what goes into the file.

Finding	How we work on it	Record in the file
Memory growth over a long session	We reproduce the long session on a build that matches the field version and find the cause with memory analysis tools.	Problem report · regression test
Crashes that do not reproduce in the lab	We analyse crash dumps and review shared state and threading.	Problem report · anomaly list
An old compiler and unmaintained libraries	We move the build to a current toolchain, list the third party libraries and update them where it is safe.	SOUP list · SBOM
No automated tests	We write tests that record today's behaviour and add a simulation mode for hardware and network interfaces.	Verification plan · test reports
Design that exists only in the code	We reconstruct the architecture and the detailed design from the source tree and the build, and your senior developers fill the gaps in short sessions.	Architecture · detailed design
Interfaces that tenders no longer accept	We add FHIR and DICOMweb as a separate layer, and the HL7 v2 and DIMSE paths keep working.	Interface specification · conformance statement

Fit

When we are the right partner.

Call us when

You want to keep selling the product after the core developers retire
You want field defects that your team cannot reproduce found and fixed
You want to take over the code from a supplier that is leaving
You want an MDR technical file with the software documentation the product never had

Talk to us

Tell us what you are working on.

A field defect, an old toolchain, a new interface or a software file for the MDR. Write a few lines with the language, the age of the code base and the device class, or book a free 30 minute call with engineering.

Book a 30 minute technical call

FAQ

Frequently asked questions.

Can you modernise our C++ and MFC application without losing the CE mark?

Yes, when each change passes your change control with its impact analysis and verification, and the significant change question is answered for each release. A device still under an MDD certificate keeps its transition only while its design and intended purpose (what the manufacturer states the software is for) do not change significantly, and MDCG 2020-3 describes what counts as significant. We plan the modernisation as a series of such releases, with a regression baseline recorded before the first change.

Should we rewrite the product or refactor it?

We decide it module by module after the code review. A rewrite of the core discards verification evidence collected over years. We refactor where the code can be brought under test and replace modules where it cannot. The gap analysis report gives the recommendation for each module.

Our software documentation was written for the MDD. Does IEC 62304 apply to a product already on the market?

The MDR asks for a software lifecycle that follows the state of the art, and IEC 62304 is the accepted way to show it. Clause 4.4 of IEC 62304 Amendment 1 covers legacy software. It asks for a review of field feedback and risk management, a gap analysis, a plan to close the gaps and a rationale for continued use.

Can you add FHIR or DICOMweb to a product built on HL7 v2 and DICOM DIMSE?

Yes. We specify and build the new interface as a separate layer, so the HL7 v2 and DIMSE paths that installed sites depend on keep working. The new layer is tested against the systems on site and documented in the interface specification and the DICOM conformance statement.

How long can a device certified under the MDD stay on the market?

Under Regulation (EU) 2023/607 until the end of 2027 or 2028, depending on its class. The extension holds only if the manufacturer applied to a notified body (the independent organisation that certifies a device under the EU MDR) for MDR certification by 26 May 2024 and signed a written agreement with it by 26 September 2024, runs a quality management system under the MDR and makes no significant change to the design or intended purpose. Without these, the device needs an MDR certificate now.

We also sell the product in the US. What does a change mean there?

Each software change to a cleared device is assessed against the FDA guidance on deciding when to submit a 510(k) for a software change to an existing device. The answer is recorded with the change, next to the significant change assessment for the EU.

How do we start?

With an IEC 62304 gap analysis. We review the code, the documents and the process, and you receive a written report and a remediation plan with the modernisation steps in order. Each step after it is quoted individually and agreed in writing.

Related services and sectors.

Legacy modernisation and takeover IEC 62304 gap analysis Retrospective IEC 62304 documentation Interoperability Medical device cybersecurity Medical imaging OEMs