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 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 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.

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.

Branchen · Etablierte medizinische Software

Anbieter medizinischer Software, deren Produkte seit Jahrzehnten auf dem Markt sind.

C++- und MFC-Desktopanwendungen, die seit fünfzehn bis dreißig Jahren verkauft werden, hängen an wenigen erfahrenen Entwicklern, einer alten Toolchain und einer Softwaredokumentation, die für die MDD geschrieben wurde. Krankenhäuser verlangen FHIR und DICOMweb, und jede Änderung muss den zertifizierten Stand erhalten. Wir übernehmen den Code, stellen den Build auf eine aktuelle Toolchain um und halten das heutige Verhalten in Tests fest, bevor wir die erste Änderung umsetzen.

30-minütiges Gespräch buchen Schreiben Sie uns

Systeme: C++ · MFC · .NET · DICOM · HL7
Normen: IEC 62304 Abschnitt 4.4 · ISO 13485 · EU MDR · FDA
Erster Schritt: Kostenloses 30-minütiges Gespräch mit der Entwicklung

Der Weg der Software

Wie eine Änderung ein Produkt erreicht, das seit Jahrzehnten auf dem Markt ist.

Anforderung

Die ursprünglichen Anforderungen finden sich nur noch in alten Tickets und im Wissen weniger erfahrener Entwickler.

VerbesserungWir dokumentieren die Anforderungen und ordnen sie dem Code zu. So lässt sich jede neue Anfrage anhand der bestehenden Anforderungen prüfen.

Design

Die Architektur ist nur im Quellcode erkennbar, daher wird sie vor jeder Änderung neu erarbeitet.

VerbesserungWir rekonstruieren Architektur und Feinentwurf einmalig und halten beides in Ihren Dokumenten fest.

Implementierung

Der Code benötigt alte Compiler, und nur wenige Entwickler möchten daran arbeiten.

VerbesserungDer Build läuft mit einer aktuellen Toolchain. So können auch neue Entwickler am Code arbeiten.

Verifizierung

Es gibt keine automatisierte Testsuite, daher wiederholt jedes Release die manuelle Regressionsprüfung.

VerbesserungTests sichern das bisherige Verhalten ab und laufen bei jeder Änderung automatisch.

Freigabe

Jedes Release erfordert eine Auswirkungsanalyse anhand einer Softwaredokumentation, die noch für die MDD erstellt wurde.

VerbesserungFür jedes Release erstellen wir eine Auswirkungsanalyse und bringen die bisherigen Dokumente auf den Stand der technischen Dokumentation nach MDR, die für das MDR-Zertifikat nötig ist.

Feldsupport

Bei Kunden wächst der Speicherverbrauch, und die Anwendung stürzt ab. Im Labor lassen sich diese Fehler nicht reproduzieren, sie bleiben offen.

VerbesserungWir reproduzieren Fehler aus dem Betrieb mit einem Build, der der beim Kunden eingesetzten Version entspricht, und sichern jede Korrektur durch einen Regressionstest ab.

Änderung

Ausschreibungen verlangen FHIR und DICOMweb. Das Produkt unterstützt bisher HL7 v2 und DIMSE.

VerbesserungWir ergänzen FHIR und DICOMweb, ohne die bestehenden Schnittstellen zu ersetzen. So funktionieren die bereits installierten Systeme weiter.

Das Ziel

Ein Produkt, das auf dem Markt bleibt und sich weiterentwickeln lässt.

Für den Hersteller

Bewertung wesentlicher Änderungen bei jedem Release
Wissen über den Kern in Ihren Dokumenten gesichert
Neue Entwickler können mit einer aktuellen Toolchain arbeiten

Für Krankenhäuser und medizinisches Fachpersonal

Eine Anwendung, die auch bei langen Sitzungen stabil läuft
Aktuelle Schnittstellen für die Anbindung an Krankenhaussysteme
Updates, die das vertraute Verhalten beibehalten

Für Patienten

Schnelle Fehlerkorrekturen für die Software, auf die sich das Krankenhaus verlässt
Neue Funktionen, die die Patientenversorgung verbessern und Krankenhäuser früher erreichen
Ergebnisse, die nach jedem Update mit dem dokumentierten Verhalten abgeglichen werden

Probleme und Lösungswege

Was wir hören und was wir dagegen tun

Die Entwickler, die den Kern entworfen haben, sind nicht mehr da.

Wir rekonstruieren Architektur und Feinentwurf anhand des Quellcodes und des Builds. Ihre erfahrenen Entwickler helfen uns in kurzen Gesprächen, offene Fragen zu klären. Die Ergebnisse halten wir in Ihren Dokumenten fest.

Modernisierung und Übernahme von Altsystemen

Bei Kunden wird die Anwendung langsam oder stürzt ab. Wir können die Fehler nicht reproduzieren.

Wir stellen die Bedingungen beim Kunden mit einem Build nach, der der dort eingesetzten Version entspricht. Dabei wiederholen wir die in den Fehlerberichten beschriebenen Abläufe und analysieren vorhandene Crash-Dumps. Jede Fehlerkorrektur sichern wir durch einen Regressionstest ab.

Modernisierung und Übernahme von Altsystemen

Wir können den Kern nicht ändern, ohne die Zertifizierung erneut prüfen zu müssen.

Vor der ersten Änderung sichern wir das bisherige Verhalten durch Tests ab. Für jedes Release erstellen wir eine Auswirkungsanalyse und bewerten, ob eine wesentliche Änderung vorliegt.

IEC-62304-Gap-Analyse

Ein Rewrite dauert Jahre und macht unsere bisherigen Verifizierungsnachweise hinfällig.

Der Kern bleibt erhalten. Zunächst stellen wir den Build auf eine aktuelle Toolchain um und erstellen Regressionstests. Wir ersetzen ein Modul erst, wenn wir es verstanden und getestet haben. Jeder Schritt ist ein reguläres Release mit eigener Auswirkungsanalyse und schriftlich festgelegtem Umfang.

Wie wir arbeiten

Krankenhäuser verlangen FHIR und DICOMweb. Unsere Schnittstellen unterstützen bisher HL7 v2 und DIMSE.

Wir ergänzen die neue Schnittstelle als eigene Schicht neben den Wegen über HL7 (ein Standard für den Austausch klinischer Nachrichten) v2 und DIMSE, auf die installierte Standorte angewiesen sind. Diese Wege laufen weiter, die neue Schicht erhält eine eigene Authentifizierung, einen verschlüsselten Transport und eine Aktualisierung des Threat Model (eine strukturierte Analyse, wie das Gerät angegriffen werden könnte), und wir testen sie gegen die Systeme vor Ort.

Interoperabilität

Unsere Softwaredokumentation stammt aus der MDD-Zeit. Die Benannte Stelle wird die Lücken erkennen.

Die Gap-Analyse (eine Prüfung, was gegenüber der Norm fehlt) liest den Code, die Dokumente und den Prozess. Für Software, die bereits am Markt ist, schreiben wir den Bericht als Teil der Aufzeichnung, die Abschnitt 4.4 der IEC 62304 verlangt, mit der Auswertung von Rückmeldungen aus dem Feld, dem Plan zum Schließen der Lücken und der Begründung für die Weiterverwendung. Die Dokumente folgen danach Ihren Vorlagen, Reviews und Freigaben.

Retrospektive IEC-62304-Dokumentation

Unsere Drittanbieterbibliotheken sind seit Jahren nicht mehr aktuell.

Wir führen jede Bibliothek von Drittanbietern in der SBOM (Software Bill of Materials, die Liste aller Softwarekomponenten im Build) auf und erfassen jede einzelne als SOUP (Software unbekannter Herkunft, also Code von Drittanbietern, der im Gerät verwendet wird). Bibliotheken werden aktualisiert, wo es sicher ist, und jedes Update wird wie jede andere Änderung getestet.

Cybersecurity für Medizinprodukte

Code-Review

Was eine Code-Review in altem C++-Code aufdeckt und wie wir die Ergebnisse dokumentieren.

Befund	Wie wir daran arbeiten	Nachweis in der Dokumentation
Steigender Speicherverbrauch bei langen Sitzungen	Wir stellen die lange Sitzung mit einem Build nach, der der beim Kunden eingesetzten Version entspricht. Mit Werkzeugen zur Speicheranalyse ermitteln wir die Ursache.	Problembericht · Regressionstest
Abstürze, die sich im Labor nicht reproduzieren lassen	Wir analysieren Crash-Dumps und prüfen gemeinsam genutzte Zustände sowie das Threading.	Problembericht · Anomalieliste
Veraltete Compiler und nicht mehr gepflegte Bibliotheken	Wir stellen den Build auf eine aktuelle Toolchain um, erfassen die Drittanbieterbibliotheken und aktualisieren sie, soweit dies sicher möglich ist.	SOUP-Liste · SBOM
Keine automatisierten Tests	Wir erstellen Tests, die das bisherige Verhalten absichern, und ergänzen einen Simulationsmodus für Hardware- und Netzwerkschnittstellen.	Verifizierungsplan · Testberichte
Design, das nur im Code dokumentiert ist	Wir rekonstruieren Architektur und Feinentwurf anhand des Quellcodes und des Builds. Ihre erfahrenen Entwickler helfen uns in kurzen Gesprächen, offene Fragen zu klären.	Architektur · Feindesign
Schnittstellen, die den Anforderungen von Ausschreibungen nicht mehr genügen	Wir ergänzen FHIR und DICOMweb in einer eigenen Schicht. Die bestehenden HL7-v2- und DIMSE-Pfade funktionieren weiter.	Schnittstellenspezifikation · DICOM Conformance Statement

Eignung

Wann wir der richtige Partner sind

Sprechen Sie uns an, wenn

Sie Ihr Produkt weiter verkaufen möchten, auch wenn die Kernentwickler in den Ruhestand gehen
Fehler beim Kunden gefunden und behoben werden sollen, die Ihr Team nicht reproduzieren kann
Sie den Code von einem Lieferanten übernehmen möchten, der sich zurückzieht
Sie eine technische Dokumentation nach MDR einschließlich der bisher fehlenden Softwaredokumentation benötigen

Sprechen Sie mit uns

Sagen Sie uns, woran Sie arbeiten.

Ein Fehler beim Kunden, eine alte Toolchain, eine neue Schnittstelle oder Softwaredokumentation für die MDR. Schreiben Sie uns einige Zeilen zur Programmiersprache, zum Alter der Codebasis und zur Geräteklasse. Oder vereinbaren Sie ein kostenloses 30-minütiges Gespräch mit unserem Entwicklungsteam.

30-minütiges Fachgespräch buchen

FAQ

Häufige Fragen.

Können Sie unsere C++- und MFC-Anwendung modernisieren, ohne die CE-Kennzeichnung zu gefährden?

Ja, wenn jede Änderung Ihre Change Control mit Auswirkungsanalyse und Verifizierung durchläuft und die Frage der wesentlichen Änderung für jedes Release beantwortet wird. Ein Gerät mit einem Zertifikat nach der MDD behält seine Übergangsfrist nur, solange sich Design und Zweckbestimmung (was der Hersteller als Verwendung der Software angibt) nicht wesentlich ändern, und MDCG 2020-3 beschreibt, was als wesentlich gilt. Wir planen die Modernisierung als Reihe solcher Releases, mit einer vor der ersten Änderung festgehaltenen Regressionsbasis.

Sollen wir das Produkt neu schreiben oder den bestehenden Code refaktorieren?

Das entscheiden wir nach der Code-Review für jedes Modul einzeln. Ein Rewrite des Kerns macht die über Jahre gesammelten Verifizierungsnachweise hinfällig. Wir refaktorieren Module, deren Code sich durch Tests absichern lässt, und ersetzen die übrigen. Der Bericht zur Gap-Analyse enthält für jedes Modul eine Empfehlung.

Unsere Softwaredokumentation stammt aus der MDD-Zeit. Gilt IEC 62304 auch für ein Produkt, das bereits auf dem Markt ist?

Die MDR verlangt einen Software-Lebenszyklus nach dem Stand der Technik. IEC 62304 ist der anerkannte Weg, dies nachzuweisen. Abschnitt 4.4 der IEC 62304 Amendment 1 behandelt Legacy-Software. Er verlangt, Rückmeldungen aus dem Betrieb und das Risikomanagement zu bewerten sowie eine Gap-Analyse durchzuführen. Außerdem fordert er einen Plan zur Beseitigung der Lücken und eine Begründung für die weitere Verwendung.

Können Sie FHIR oder DICOMweb in ein Produkt integrieren, das auf HL7 v2 und DICOM DIMSE basiert?

Ja. Wir spezifizieren und entwickeln die neue Schnittstelle als eigene Schicht. Die bestehenden HL7-v2- und DIMSE-Pfade bleiben erhalten, damit installierte Systeme weiter funktionieren. Wir testen die neue Schicht mit den Systemen vor Ort. Anschließend dokumentieren wir sie in der Schnittstellenspezifikation und im DICOM Conformance Statement.

Wie lange darf ein nach MDD zertifiziertes Produkt auf dem Markt bleiben?

Nach der Verordnung (EU) 2023/607 bis Ende 2027 oder 2028, je nach Klasse. Die Verlängerung gilt nur, wenn der Hersteller bis zum 26. Mai 2024 bei einer Benannten Stelle (die unabhängige Organisation, die ein Produkt nach der EU MDR zertifiziert) die MDR-Zertifizierung beantragt und bis zum 26. September 2024 eine schriftliche Vereinbarung mit ihr geschlossen hat, ein Qualitätsmanagementsystem nach der MDR betreibt und keine wesentliche Änderung an Design oder Zweckbestimmung vornimmt. Ohne diese Voraussetzungen braucht das Gerät jetzt ein MDR-Zertifikat.

Wir verkaufen das Produkt auch in den USA. Was müssen wir bei Änderungen beachten?

Bei jeder Softwareänderung an einem Produkt mit FDA-Freigabe (510(k)) prüfen wir anhand der FDA-Guidance, ob eine neue 510(k) eingereicht werden muss. Wir dokumentieren das Ergebnis zusammen mit der Änderung und der Bewertung, ob für die EU eine wesentliche Änderung vorliegt.

Wie fangen wir an?

Wir beginnen mit einer IEC-62304-Gap-Analyse. Dabei prüfen wir Code, Dokumente und Prozesse. Sie erhalten einen schriftlichen Bericht und einen Maßnahmenplan, der die Modernisierungsschritte in der vorgesehenen Reihenfolge aufführt. Jeden weiteren Schritt bieten wir einzeln an und vereinbaren ihn schriftlich.

Weiterführend