Anmelden
Eine Radiologie-Workstation der vorherigen Generation, über einen Build-Server mit ihrem modernen Nachfolgesystem verbunden
Leistungen · Modernisierung und Übernahme von Altsystemen

Medizinische Software langfristig nutzen, sicher, aktuell und wartbar halten

Produkte, die seit vielen Jahren am Markt sind, brauchen weiterhin Fehlerbehebungen, neue Funktionen und Sicherheitsupdates, während Betriebssysteme, Datenbanken, Treiber und Bibliotheken ihr Lebensende erreichen. Silurus Software wartet und modernisiert diese Systeme, übernimmt sie von einem ausscheidenden Lieferanten, behebt Fehler in Code und Dokumenten und richtet Tests und Builds ein, die in jedem Build den Stand der getesteten Software zeigen. Jede Änderung wird unter Ihrer Change Control auf ihre regulatorische Auswirkung bewertet. Wir bereiten den Softwareteil dieser Bewertung vor, damit Ihr Regulatory-Team vor dem Release entscheiden kann, ob die Benannte Stelle (die unabhängige Organisation, die ein Produkt nach der EU MDR zertifiziert) informiert werden muss oder ein neues 510(k) (die FDA-Meldung vor dem Inverkehrbringen für ein Produkt, das einem bereits vermarkteten Produkt ähnelt) nötig ist.

30-minütiges Gespräch buchen Schreiben Sie uns
Sprachen
C · C++ · C# · Java · Python
Schwerpunkte
SOUP, Supportende und Sicherheit
Prozess
IEC 62304 · ISO 13485 · ISO 14971
Marktzugang
EU MDR · FDA
Leistungsumfang

Ein langjähriges Produkt am Markt halten

01

Plattformen, deren Support ausläuft

Wir prüfen die Abhängigkeiten von der Plattform und bewerten, ob ein Wechsel auf eine unterstützte Version technisch und wirtschaftlich möglich ist. Anschließend migrieren wir das Produkt und verifizieren es auf der neuen Version.

02

Veraltete SOUP-Komponenten mit Sicherheitslücken

Wir prüfen jede Drittanbieterkomponente auf Supportstatus und bekannte Schwachstellen. Jedes Update bewerten, testen und dokumentieren wir.

Cybersecurity für Medizinprodukte →
03

Software vom bisherigen Lieferanten übernehmen

Wir führen Übergabegespräche, übernehmen Code, Build und Dokumentation und führen die Wartung ab dem vereinbarten Termin fort.

IEC-62304-Gap-Analyse →
04

Code, der sich schwer testen lässt

Mit Charakterisierungstests sichern wir das aktuelle Softwareverhalten ab. Diese Tests halten wir von den freigegebenen Anforderungen getrennt. Bekannte Fehler dokumentieren wir, ohne sie als gewünschtes Verhalten festzuschreiben. Wir gliedern den Code in Module und ergänzen Unit-Tests, die in der CI ohne Hardware laufen. Dabei messen wir fortlaufend, wie die Testabdeckung wächst. Auf Hardware-in-the-Loop-Prüfständen testen wir die Module auf der tatsächlichen Hardware.

05

Builds und Regressionstests

Die Builds laufen in der CI mit festgelegten Werkzeugversionen und fixierten Abhängigkeiten. Bei jeder Änderung führen wir die Regressionstests aus.

06

Zuverlässige Schnittstellen für Krankenhäuser

Aus realen Nachrichten und Datensätzen erstellen wir Regressionstests für jedes Release. Bevor die Daten Ihre Umgebung verlassen, anonymisieren wir sie oder pseudonymisieren sie, sofern Ihre Datenschutzvorgaben das erlauben.

Interoperabilität →
07

Fehler im Feld und Wartung

Wir ermitteln die Ursache, beheben den Fehler und veröffentlichen das Release nach Ihrem Wartungsplan. Mit jedem Release aktualisieren wir auch die Dokumentation.

08

Benutzeroberflächen schrittweise modernisieren

Wir modernisieren die Benutzeroberfläche Schritt für Schritt. Neue und überarbeitete Bereiche durchlaufen den vollständigen Prozess zur gebrauchstauglichkeitsorientierten Entwicklung nach IEC 62366-1. Anhang C wenden wir nur auf unveränderte Bereiche der bestehenden Oberfläche an, deren Gebrauchstauglichkeit bisher nicht bewertet wurde.

In der Praxis

Typische Aufgaben unserer Kunden

Ausgangslage

Die Benannte Stelle beanstandet ein langjährig vermarktetes Produkt

Ein Produkt der Klasse IIb stammt noch aus der Zeit der europäischen Richtlinien. Die Benannte Stelle hat Lücken in der Softwaredokumentation festgestellt. Das Produkt soll weiterhin verkauft werden.

Unser Vorgehen

Silurus Software ordnet jedes Ergebnis der zugrunde liegenden Aktivität nach IEC 62304 zu und schreibt die Aufzeichnungen, die die risikobasierte Gap-Analyse (eine Prüfung, was gegenüber der Norm fehlt) des Wegs für Legacy-Software (IEC 62304 Amendment 1, Abschnitt 4.4) als nötig ausweist. Wo kein Nachweis existiert, benennen wir die Verifizierung, die neu durchzuführen ist. Aus dem Code rekonstruierte Anforderungen werden als solche gekennzeichnet und vor der Freigabe von Ihrem Team geprüft. Das Produkt wird nicht neu geschrieben, und jede Änderung durchläuft Ihre Change Control.

Ausgangslage

Der Lieferant stellt den Support in acht Wochen ein

Der externe Lieferant eines Produkts der Klasse IIa stellt den Support in acht Wochen ein. Er verfügt über den Großteil des Wissens zur C++- und Qt-Codebasis sowie zur Build-Umgebung.

Unser Vorgehen

In der ersten Woche nach Projektstart sichern wir Code, Build-Umgebung und den Kontakt zum Lieferanten. Wir führen Übergabegespräche, solange der Lieferant verfügbar ist. Anschließend sorgen wir dafür, dass sich der Build bei uns reproduzieren lässt. Die IEC-62304-Gap-Analyse zeigt den aktuellen Stand von Code und Dokumentation. Nach Ablauf der acht Wochen übernehmen wir die Wartung im vereinbarten Umfang. Wir dokumentieren offene Punkte und planen das nächste Release anhand der Gap-Analyse.

Ausgangslage

Eine Desktop-Anwendung mit Qt 5 und .NET modernisieren

Das Hauptprodukt ist eine Windows-Desktop-Anwendung in C++ mit Qt 5 und einigen .NET-Komponenten. Es verkauft sich gut, doch Änderungen sind aufwendig.

Unser Vorgehen

Wir legen Tests um das aktuelle Verhalten, verlagern die Logik in testbare Module und bewerten den Wechsel auf Qt 6 als Softwareänderung. Bei Geräten, die noch unter einem Richtlinienzertifikat stehen, prüfen wir nach der Leitlinie MDCG 2020-3 der EU-Koordinierungsgruppe Medizinprodukte, ob es eine wesentliche Änderung ist. Danach planen wir den Wechsel Schritt für Schritt, jeden Schritt verifiziert und freigegeben unter Ihrer Change Control.

Ausgangslage

Seit Langem am Markt, die ursprünglichen Entwickler sind nicht mehr da

Ein Gerät ist seit vielen Jahren am Markt. Die ursprünglichen Entwickler sind weitergezogen, Komponenten erreichen das Ende ihres Lebenszyklus, und Sicherheitspatches werden gebraucht.

Unser Vorgehen

Wir übernehmen die langfristige Betreuung: Problemberichte und CAPA (Korrektur- und Vorbeugemaßnahmen)-Eingaben mit Ursachenanalyse, Unterstützung bei Beschwerden und Überwachung nach dem Inverkehrbringen, Updates für SOUP und Betriebssystem, Sicherheitspatches und geplante Releases, mit einem benannten Kernteam und einer dokumentierten Übergabe, falls sich das Personal ändert.

Ablauf

Von der ersten Bestandsaufnahme bis zur laufenden Wartung

Schritt 1

Bewertung

Wir prüfen Code, Build, SOUP und Dokumentation. Dabei erfassen wir Risiken wie auslaufenden Komponentensupport und fehlende Tests.

Schritt 2

Baseline festlegen

Wir erstellen einen Build, der auf einem frisch eingerichteten Rechner läuft. Außerdem erfassen wir aktuelle SOUP-Versionen und sichern das bestehende Softwareverhalten durch Tests ab.

Schritt 3

Software modernisieren

Wir aktualisieren Plattformen, refaktorieren Code und beheben Fehler. Dabei arbeiten wir Modul für Modul und verifizieren und dokumentieren jede Änderung.

Schritt 4

Software warten

Wir bearbeiten Problemberichte, installieren Sicherheitsupdates und veröffentlichen neue Releases nach Ihrem Wartungsplan. Bei jedem Build bleibt der Softwarestand nachvollziehbar.

Übernahme

Was wir für die Übernahme von Ihnen benötigen

Das benötigen wir zum Start

  • Zugang zu den Quellcode-Repositories und zur Build-Umgebung oder jeweils eine Kopie
  • Aktuelle Softwaredokumentation, Risikomanagementakte und offene Problemberichte
  • Eine Liste der freigegebenen Versionen und ihrer Installationsorte
  • Eine Ansprechperson beim bisherigen Lieferanten für die Übergabegespräche
  • Eine verantwortliche Person in Ihrem Unternehmen, die Entscheidungen trifft und Change Control koordiniert
Was Sie erhalten

Software, die Sie langfristig warten können

D-01

SOUP- und End-of-Life-Bericht

Wir erfassen jede Drittanbieterkomponente mit Version, Supportstatus, bekannten Schwachstellen und den geplanten Maßnahmen.

D-02

Reproduzierbarer Build

Wir richten den Build in einer CI-Pipeline mit festgelegten Compiler-, Bibliotheks- und Werkzeugversionen sowie fixierten Abhängigkeiten ein. Zur Überprüfung erstellen wir eine freigegebene Version erneut und vergleichen das Ergebnis mit den freigegebenen Artefakten. Jede Abweichung erklären und dokumentieren wir.

D-03

Regressionstests

Die Tests laufen bei jedem Build und erkennen sofort, wenn eine Änderung bereits getestetes Verhalten beeinträchtigt.

D-04

Kontinuierlich gepflegte Releases

Wir liefern Fehlerbehebungen, Updates und neue Funktionen mit Auswirkungsanalyse, Release Notes und aktualisierter Rückverfolgbarkeit.

EU und USA

Änderungen an zertifizierten Produkten

Europäische Union

EU MDR

Wir bereiten die softwaretechnische Änderungsbewertung für Ihre Benannte Stelle vor. Bei Produkten mit gültiger Bescheinigung nach der bisherigen Richtlinie prüfen wir die Änderungen anhand von MDCG 2020-3.

Vereinigte Staaten

FDA

Bei Produkten mit einer 510(k)-Freigabe bereiten wir die softwaretechnische Bewertung vor, ob eine Änderung einen neuen 510(k)-Antrag erfordert. Ist kein neuer Antrag nötig, dokumentieren Sie die Änderung in Ihren Design- und Entwicklungsunterlagen innerhalb Ihres QMS.

Technologien und Normen

Unsere Fachgebiete

Technologien und Werkzeuge

CC++QtQMLC#.NETWPFWinFormsJavaSonarQubeclang-tidyCoverityGoogleTestNUnitSquishJenkinsAzure DevOpsDockerGitCI/CD

Normen, Vorschriften und Methoden

CharakterisierungstestsSOUP-ListeSBOMIEC 62304ISO 13485ISO 14971IEC 81001-5-1IEC 62366-1EU MDRMDCG 2020-3FDA 510(k)FDA-Guidance zu 510(k) bei SoftwareänderungenFDA QMSR (21 CFR 820)

Silurus Software

  • Silurus Software, gegründet 2017, Standorte in Budapest (Ungarn) und Singapur
  • Mehr als 40 Entwickler, Spezialisten für Regulatory Affairs nach EU MDR und FDA-Berater
  • Wir arbeiten im ISO-13485-Qualitätsmanagementsystem des Kunden und legen die Aufgabenteilung vor Projektbeginn schriftlich fest. Hat der Kunde noch keinen dokumentierten Softwareprozess, bringen wir IEC-62304-Vorlagen mit, die er in sein eigenes System übernimmt
  • Mehrjähriger Entwicklungspartner eines europäischen MedTech-Herstellers
  • Gründer und CTO Péter Török entwickelt seit 1999 Medizintechnik-Software. Zuvor leitete er die Softwareentwicklung bei Siemens Healthcare (syngo.via) und die Forschung und Entwicklung bei Mediso Medical Imaging Systems.
  • Zertifiziert nach ISO 9001:2015 (NQA, Zertifikat 171041, gültig bis März 2027) und ISO/IEC 27001:2022 (NQA, Zertifikat 728872, gültig bis August 2029)
  • 2025 von Dun & Bradstreet mit AAA für höchste Kreditwürdigkeit ausgezeichnet
  • Forschungspartner der ELTE Eötvös-Loránd-Universität in Budapest
  • Ab 2027 Industriepartner im EU-Projekt LOGOS (Horizon Europe) mit den Universitäten Bologna, Pisa und Amsterdam sowie der Masaryk-Universität in Brno
  • Geschäftsführerin Dr. Linda Szántó erhielt die Auszeichnungen Female Business Leader of the Year 2025 und The Pioneer Award 2026
Unsere Arbeitsweise →Qualität und Normen →Arbeitsergebnisse →Fallstudien →
Weiterführend

Verwandte Projekte und Seiten.

Kundennamen werden nur genannt, wenn der Kunde zugestimmt hat.

Fallstudie

Laborgerät: Refactoring und Dokumentation nach IEC 62304

Desktop-Anwendung und Firmware des Laborgeräts eines niederländischen Universitätsklinikums, refaktoriert für Testbarkeit, mit IEC-62304-Dokumentation, in drei Monaten.

Fallstudie

Feature-Entwicklung nach IEC 62304 in einer großen .NET-Codebasis

Senior-Entwickler im Lebenszyklus, im QMS und im Review-Prozess eines europäischen Herstellers, über mehrere Jahre.

IEC-62304-Gap-AnalyseRetrospektive IEC-62304-DokumentationCybersecurity für MedizinprodukteBeratung zu regulatorischen Anforderungen der EU MDR und FDAEtablierte Hersteller medizinischer Software
FAQ

Häufige Fragen

01

Unser Produkt verwendet ein Betriebssystem, dessen Support ausläuft. Können Sie es migrieren?

Ja, sofern die vorherige Prüfung dafür spricht. Wir prüfen die Abhängigkeiten vom Betriebssystem und bewerten, ob eine Migration möglich ist. Anschließend migrieren wir das Produkt auf eine unterstützte Version. Die Änderung verifizieren und dokumentieren wir im Rahmen Ihres Change-Control-Prozesses. Ist eine Migration nicht möglich, dokumentieren wir stattdessen die Maßnahmen zur Risikobeherrschung und planen den Umgang mit dem Supportende.

02

Wie gehen Sie mit veralteten Bibliotheken oder solchen mit bekannten Sicherheitslücken um?

Jedes SOUP-Element wird auf Supportstatus und bekannte Schwachstellen geprüft. Updates werden auf ihr Risiko bewertet, getestet und in der SOUP-Liste und der SBOM (Software Bill of Materials, die Liste aller Softwarekomponenten im Build) festgehalten.

03

Schreiben Sie bestehende Software neu?

Ja, wenn Sie sich dafür entscheiden. Zunächst suchen wir die kleinste Änderung, die das Problem behebt. Anschließend legen wir gemeinsam fest, welche Module bestehen bleiben, welche wir refaktorieren und welche wir neu schreiben. Nur selten muss das gesamte Produkt neu geschrieben werden. Über jeden Schritt entscheiden Sie. Wir entwickeln nach IEC 62304 und geben die Änderungen über Ihren Change-Control-Prozess frei.

04

Können Sie unser Produkt vom bisherigen Lieferanten übernehmen?

Ja. Zunächst qualifizieren Sie Silurus Software als Lieferanten in Ihrem Qualitätsmanagementsystem. Ihr Regulatory-Team entscheidet, ob es die Benannte Stelle über den Lieferantenwechsel informieren muss. Solange der bisherige Lieferant verfügbar ist, führen wir Übergabegespräche. Danach übernehmen wir Build, Wartung und Releases.

05

Wie behalten wir den Überblick über den Softwarestand?

Bei jeder Änderung laufen automatisierte Builds und Regressionstests. Mit jedem Release aktualisieren wir die Rückverfolgbarkeit und die SOUP-Liste.

06

Kann unser eigenes Team das Produkt später zurücknehmen?

Ja. Wir strukturieren Code, Tests und Dokumentation so, dass Ihr eigenes Team oder ein anderer Lieferant die Software weiter warten kann.

07

Arbeiten Sie mit Qt?

Ja. Wir arbeiten mit Qt 5 und Qt 6, C++ und QML und migrieren Anwendungen von Qt 5 auf Qt 6.

08

Wie schnell können Sie ein Produkt übernehmen?

Die ersten Entwickler beginnen zwei bis drei Wochen nach Vertragsunterzeichnung. Den Übergabeplan stimmen wir darauf ab, wie lange der bisherige Lieferant noch verfügbar ist.

09

Unterstützen Sie CAPA und die Überwachung nach dem Inverkehrbringen?

Ja. Wir untersuchen Problemberichte bis zur Grundursache. Die Ergebnisse dokumentieren wir als Eingaben für Ihre CAPA-Prozesse, die Reklamationsbearbeitung und die Überwachung nach dem Inverkehrbringen.

10

Modernisieren Sie Anwendungen mit WPF, WinForms und .NET Framework?

Ja. Unsere Entwickler verfügen über langjährige Erfahrung mit Desktop-Anwendungen in WPF und WinForms. Sie haben Produkte schrittweise von .NET Framework auf aktuelles .NET migriert und jedes Release verifiziert.

Sprechen Sie mit uns

Beschreiben Sie uns Ihr Produkt

Beschreiben Sie Ihr Produkt, die verwendete Plattform und die gewünschten Änderungen. Wir nennen Ihnen den ersten sinnvollen Schritt.

30-minütiges Fachgespräch buchen
Wir antworten innerhalb eines Werktags.