Anmelden
Aus vorhandenem Quellcode wird eine prüffähige Softwaredokumentation
Leistungen · Nachträgliche Dokumentation nach IEC 62304

Fehlende Dokumentation für bereits funktionsfähige Software

Software, die vor den heutigen Verfahren, von einem ausgeschiedenen Lieferanten oder unter Zeitdruck entstanden ist, braucht ihre IEC-62304-Akte vor einem Audit oder einer Einreichung. Die Ingenieure und Regulatory-Spezialisten von Silurus Software beginnen mit einer Gap-Analyse (eine Prüfung, was gegenüber der Norm fehlt), schreiben die fehlenden Dokumente aus dem Code und dem vorhandenen Material und korrigieren die Dokumente, die nicht mehr zur Software passen, für die technische Dokumentation nach EU MDR und die FDA-Einreichung.

30-minütiges Gespräch buchen Schreiben Sie uns
Ausgangslage
IEC-62304-Gap-Analyse
Software
Firmware, Desktopanwendungen, mobile Apps und Cloud-Software
Vorgehen
IEC 62304 · ISO 13485 · ISO 14971
Marktzugang
EU MDR · FDA
Leistungsumfang

Alle Bestandteile der Softwaredokumentation

01

Anforderungen

Wir rekonstruieren die Anforderungen aus dem Code, dem Verhalten und dem Benutzerhandbuch, vervollständigen sie mit Ihren Kollegen in kurzen Sitzungen und prüfen sie gegen die Zweckbestimmung, die Systemanforderungen und die Risikoanalyse.

02

Softwarearchitektur und Detailentwurf

Wir lesen Software-Elemente, Schnittstellen und Units aus dem Quellbaum und dem Build, so tief, wie die Software-Sicherheitsklasse (A, B oder C, je nach Schaden, den ein Softwarefehler verursachen könnte) es verlangt.

03

SOUP-Verzeichnis und SBOM

Komponenten von Drittanbietern werden aus dem Build und den Abhängigkeitsmanifesten identifiziert, Binärdateien von Herstellern per Review, mit Version, bekannten Anomalien und Risikobewertung, und die SBOM (Software Bill of Materials, die Liste aller Softwarekomponenten im Build) wird generiert.

04

Software-Risikoanalyse

Wir dokumentieren die softwarebezogenen Beiträge zur Risikomanagementakte nach ISO 14971. Für jede Maßnahme zur Risikobeherrschung weisen wir die Rückverfolgbarkeit und Verifizierung nach.

05

Tests und Rückverfolgbarkeit

Testprotokolle werden geschrieben und am Gerät oder in der Simulation ausgeführt, und die Rückverfolgbarkeitsmatrix (eine Tabelle, die jede Anforderung mit Design, Tests und Risikobeherrschungsmaßnahmen verknüpft) wird vervollständigt.

Verifizierung und Validierung →
06

Dokumentation zur Cybersicherheit

Wir schreiben das Threat Model (eine strukturierte Analyse, wie das Gerät angegriffen werden könnte), die Sicherheitsanforderungen und ihre Tests nach IEC 81001-5-1.

Cybersicherheit von Medizinprodukten →
07

Dokumentation der Gebrauchstauglichkeit

Wir erstellen die Nutzungsspezifikation und dokumentieren die Bewertungen nach IEC 62366-1. Bei Benutzungsschnittstellen unbekannter Herkunft berücksichtigen wir Anhang C der Norm, sofern er zutrifft. Dabei beziehen wir Ihr klinisches Personal ein. An der summativen Evaluierung beteiligen sich repräsentative Anwender.

08

Unterlagen für die Zulassung

Unsere Regulatory-Spezialisten und FDA-Berater erstellen die softwarebezogenen Unterlagen für die EU MDR und die FDA.

Regulatorische Beratung →
In der Praxis

Typische Aufgaben unserer Kunden

Ausgangslage

Feststellungen der Benannten Stelle bei einem langjährig vermarkteten Produkt

Ein Gerät der Klasse IIb ist seit Jahren unter der alten Richtlinie am Markt. Die Benannte Stelle (die unabhängige Organisation, die ein Produkt nach der EU MDR zertifiziert) hat Lücken in der Softwaredokumentation gefunden, die Software ist eine C++-Desktopanwendung, und die Lücken müssen sich schließen, ohne das Produkt neu zu schreiben.

Unser Vorgehen

Wir beantworten die Befunde einzeln. Die Gap-Analyse ordnet jeden Befund der zugrunde liegenden Aktivität nach IEC 62304 zu, und die fehlenden Anforderungen, die Architektur, die Software Design Specification, die SOUP-Liste (Software unbekannter Herkunft, also Code von Drittanbietern, der im Gerät verwendet wird), die Verifizierung und die Rückverfolgbarkeit werden aus dem vorhandenen Code geschrieben.

Für bereits vermarktete Software, die nicht nach IEC 62304 entwickelt wurde, kann Abschnitt 4.4 aus Änderung 1 gelten. Dieser Abschnitt behandelt Legacy-Software. Wir prüfen die Rückmeldungen aus dem Markt und bewerten die Risiken. Die Gap-Analyse zeigt, welche Aktivitäten zu wiederholen sind. Wir dokumentieren auch die Begründung für die weitere Verwendung. Das Produkt muss dafür nicht neu entwickelt werden. Den Code ändern wir nur, wenn die Analyse Fehler oder unzureichende Maßnahmen zur Risikobeherrschung aufdeckt. Dabei halten wir Ihre Verfahren zur Änderungskontrolle ein.

Ausgangslage

App, Cloud-Backend und Web-Dashboard ohne Softwaredokumentation

Ein System aus iOS-App, Cloud-Backend auf AWS und Web-Dashboard befindet sich im Pilotbetrieb. Vor dem Inverkehrbringen als Medizinprodukt und der weiteren Entwicklung muss die Software nach EU MDR dokumentiert werden.

Unser Vorgehen

Wir betrachten alle drei Bestandteile als Softwarekomponenten eines Systems und bestimmen ihre jeweilige Sicherheitsklasse. Bibliotheken erfassen wir in der SOUP-Liste und in der SBOM. Für verwaltete Cloud-Dienste dokumentieren wir die Konfiguration und bewerten die Risiken. Das Bedrohungsmodell berücksichtigt die App, die API und die Schnittstelle zur Cloud.

Wir arbeiten in Etappen. Zunächst erstellen wir die Nachweise für den aktuellen Produktstand. Anschließend setzen wir die Entwicklung innerhalb desselben Softwarelebenszyklus fort. Neue Funktionen werden dabei von Anfang an dokumentiert.

Ausgangslage

Fertige Firmware ohne ausreichende Dokumentation für die FDA

Die Firmware für ein eingebettetes System ist fertig entwickelt. Für die FDA-Einreichung fehlen Architektur, Detailentwurf, Rückverfolgbarkeit, SOUP-Nachweise, Testspezifikationen, Bedrohungsmodell und SBOM.

Unser Vorgehen

Unsere Entwickler für eingebettete Systeme analysieren den Quellcode. Unsere FDA-Berater bereiten die Nachweise entsprechend den Anforderungen der Premarket-Einreichung und ihrer Dokumentationsstufe auf. Der Auftrag kann sich ausschließlich auf die Dokumentation beschränken. Softwareentwicklung und Testdurchführung sind dann nicht Bestandteil unserer Arbeit.

Ablauf

Von der Gap-Analyse bis zur Freigabe

Schritt 1

Gap-Analyse

Wir gleichen Dokumente, Quellcode und Entwicklungsverfahren mit IEC 62304 und den Anforderungen des angestrebten Marktzugangs ab. Anschließend gewichten wir die festgestellten Lücken.

Schritt 2

Arbeitsplan

Wir legen schriftlich fest, welche Dokumente wir erstellen oder korrigieren. Die Reihenfolge richtet sich nach der Dringlichkeit der Feststellungen.

Schritt 3

Dokumentation erstellen

Anforderungen und Design aus dem Code gelesen und mit Ihren Kollegen in kurzen Sitzungen vervollständigt, Tests geschrieben und von unserem Team oder Ihrem ausgeführt.

Schritt 4

Prüfung und Freigabe

Wir stellen die Rückverfolgbarkeit für den vereinbarten Softwarestand sicher. Die Dokumente werden in Ihrem Qualitätsmanagementsystem geprüft und freigegeben. Danach können Sie sie für die technische Dokumentation und die Einreichung verwenden.

Was Sie erhalten

Softwaredokumentation nach Ihren Vorlagen

D-01

Plan und Klassifizierung

Wir erstellen den Softwareentwicklungs- und Wartungsplan für die anstehenden Arbeiten. Außerdem dokumentieren und begründen wir die Sicherheitsklasse jeder Softwarekomponente.

D-02

Anforderungen und Entwurf

Wir dokumentieren Softwareanforderungen, Architektur und Detailentwurf so, dass sie mit dem vorhandenen Quellcode übereinstimmen.

D-03

SOUP-Verzeichnis und SBOM

Wir erfassen Fremdsoftware mit Versionsangaben, bekannten Anomalien und Risikobewertung. Die SBOM erstellen wir anhand der Build-Dateien.

Beispiel eines SOUP-Verzeichnisses →
D-04

Tests und Rückverfolgbarkeit

Wir erstellen Testprotokolle, Testberichte und eine Rückverfolgbarkeitsmatrix. Sie verbindet Anforderungen, Entwurf, Tests und Maßnahmen zur Risikobeherrschung.

Beispiel einer Rückverfolgbarkeitsmatrix →
EU und USA

Softwaredokumentation für EU und USA

Europäische Union

Technische Dokumentation nach EU MDR

Gemeinsam mit unseren Fachleuten für Regulatory Affairs erstellen wir die Softwareunterlagen für die technische Dokumentation zur CE-Kennzeichnung.

Vereinigte Staaten

FDA-Premarket-Einreichung

Die Softwaredokumentation für ein 510(k) (die FDA-Meldung vor dem Inverkehrbringen für ein Produkt, das einem bereits vermarkteten Produkt ähnelt) oder De Novo, erstellt mit unseren FDA-Beratern.

Technologien und Normen

Unsere Arbeitsgrundlagen

Technologien und Werkzeuge

CC++C#QtPythonSyftGrypeDependency-TrackSonarQubeclang-tidyDHF-NachbesserungSoftware-Anforderungsspezifikation (SRS)Software-Designspezifikation (SDS)TestfallTestprotokollTestberichtDesign- und Entwicklungsakte

Normen, Verordnungen und Verfahren

MDCG 2019-16VEXFDA Section 524BFDA QMSR (21 CFR 820)IEC 62304ISO 13485ISO 14971IEC 62366-1IEC 81001-5-1SOUP-ListeSBOMCycloneDXSPDXRückverfolgbarkeitsmatrixThreat ModelingTechnische Dokumentation nach EU MDRFDA-Guidance zu Premarket Submissions für Device Software FunctionseSTARIEC 62304 Amendment 1, Legacy-SoftwareFDA 510(k)

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 Software für die Medizintechnik. 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)
  • Dun & Bradstreet bewertete unsere Bonität 2025 mit AAA, der höchsten Bonitätsstufe.
  • Forschungspartner der ELTE Eötvös-Loránd-Universität in Budapest
  • Ab 2027 arbeiten wir im EU-Projekt LOGOS (Horizon Europe) als Industriepartner mit vier Universitäten zusammen. Beteiligt sind die Universitäten Bologna, Pisa und Amsterdam sowie die 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.
So arbeiten wir →Qualität und Normen →Beispiele unserer Arbeit →Fallstudien →
Weiterführend

Verwandte Projekte und Seiten.

Kundennamen werden nur genannt, wenn der Kunde zugestimmt hat.

Fallstudie

IEC-62304-Gap-Analyse der Firmware eines sicherheitskritischen Chirurgiegeräts

Zwei Personen prüften Firmware, Dokumente und Prozess eines sicherheitskritischen Chirurgiegeräts in drei Wochen gegen IEC 62304, FDA-Anforderungen und MDR. Die Nachbesserung ging anschließend als Auftrag an Silurus Software.

Fallstudie

Codeüberarbeitung und Dokumentation nach IEC 62304 für ein Laborgerät

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

IEC-62304-Gap-AnalyseZulassungsberatung für EU MDR und FDAModernisierung und Übernahme von AltsystemenVerifizierung und ValidierungKI-Coding-Tools in der regulierten Entwicklung
FAQ

Häufige Fragen

01

Können Sie die Dokumentation anhand des vorhandenen Quellcodes erstellen?

Ja. Wir lesen den Code, den Build und das vorhandene Material und vervollständigen Anforderungen und Risikobegründung mit Ihren Kollegen in kurzen Sitzungen.

02

Wie lange dauert die Dokumentation?

Bei vereinbartem Umfang dauert die Gap-Analyse drei Wochen. Sie zeigt den verbleibenden Aufwand. Anschließend planen wir die Dokumentation und erstellen ein Angebot.

03

Eignet sich das Verfahren auch für Apps und Cloud-Software?

Ja. Wir dokumentieren Firmware, Desktopanwendungen, mobile Apps und Cloud-Backends nach demselben Verfahren. Bibliotheken erfassen wir in der SOUP-Liste und in der SBOM. Für verwaltete Cloud-Dienste dokumentieren wir die Konfiguration und bewerten die Risiken.

04

Müssen wir unser QMS oder unsere Vorlagen ändern?

Nein. Wir verwenden Ihre Vorlagen und halten Ihre Vorgaben zur Dokumentenlenkung ein.

05

Führen Sie die Tests ebenfalls durch?

Ja. Wir testen am Gerät oder in einer Simulation und erstellen die zugehörigen Testberichte.

06

Was geschieht, wenn die Analyse Fehler im Quellcode aufdeckt?

Wir melden die Fehler und bewerten ihre Dringlichkeit. Unsere Ingenieure können sie nach Ihren Verfahren zur Änderungskontrolle beheben.

07

Können wir ausschließlich die Dokumentation beauftragen?

Ja. Wir erstellen die Nachweise anhand des vorhandenen Quellcodes und der verfügbaren Unterlagen. Ihr Team kann die Software weiterentwickeln und die Tests selbst durchführen.

08

Müssen Sie die Software für die Dokumentation neu entwickeln?

Nein. Wir dokumentieren die Software in ihrem aktuellen Zustand. Code ändern wir nur bei festgestellten Fehlern oder unzureichenden Maßnahmen zur Risikobeherrschung. Dabei gelten Ihre Verfahren zur Änderungskontrolle.

09

Welche Unterlagen erstellen Sie für die Software und Cybersicherheit bei der FDA?

Wir erstellen Softwarebeschreibung, softwarebezogene Risikonachweise, Anforderungen, Architektur, Detailentwurf, SOUP- und SBOM-Nachweise sowie Verifizierungsnachweise. Hinzu kommen die Versionshistorie und die Liste ungelöster Anomalien. Bei einem Cyber Device dokumentieren wir außerdem das Bedrohungsmodell und die Bewertung der Cybersicherheitsrisiken. Wir erstellen auch den Plan zum Umgang mit Schwachstellen nach dem Inverkehrbringen. Alle Unterlagen bereiten wir für die eSTAR-Einreichung gemäß der erforderlichen Dokumentationsstufe (Documentation Level) auf.

Sprechen Sie mit uns

Sagen Sie uns, welche Dokumente fehlen

Beschreiben Sie uns Ihre Software, die vorhandenen Unterlagen und den Zielmarkt. Wir nennen Ihnen den ersten Schritt.

30-minütiges Fachgespräch buchen