Research & Development
Software as a Medical Device.
Von der Klassifizierung über die IEC 62304-konforme Entwicklung bis zur FDA-Submission: Wir begleiten Ihre SaMD-Projekte von der Architektur bis zur Marktfreigabe.
Warum scheitern SaMD-Projekte an der Zulassung?
Software als Medizinprodukt unterliegt denselben regulatorischen Anforderungen wie Hardware – wird aber oft wie ein IT-Projekt behandelt:
- Fehlende Klassifizierung: MDR Regel 11 und FDA 21 CFR Part 820 werden zu spät im Entwicklungszyklus berücksichtigt. Die Risikoklasse bestimmt den gesamten regulatorischen Pfad – und damit Aufwand, Timeline und Kosten.
- IEC 62304 nicht integriert: Der Software-Lebenszyklus wird nicht von Beginn an nach IEC 62304 strukturiert. Software-Architektur, Modularisierung und Änderungsmanagement fehlen in der Dokumentation.
- KI/ML-Sonderfälle: Adaptive Algorithmen erfordern Predetermined Change Control Plans (PCCP) nach dem FDA AI/ML Framework. Ohne diesen Plan ist eine Marktfreigabe für lernende Systeme ausgeschlossen.
- Cybersecurity als Nachgedanke: FDA Premarket Cybersecurity Guidance (2023) und EU MDCG 2019-16 fordern Threat Modeling und SBOM ab Tag eins – nicht als letzten Prüfschritt.
Ist Ihre Software-Architektur so dokumentiert, dass ein FDA-Reviewer den Safety-Classification-Level jeder Software-Unit nachvollziehen kann?
Unsere SaMD-Leistungen.
Wir bringen regulatorische Präzision in agile Software-Entwicklung – ohne Ihren Entwicklungsprozess auszubremsen.
SaMD-Klassifizierung & Regulatory Strategy
Klassifizierung nach MDR Regel 11, IMDRF SaMD Framework und FDA De Novo / 510(k) / PMA. Wir definieren den effizientesten Zulassungspfad und erstellen die Regulatory Strategy inkl. Predicate-Analyse.
IEC 62304 Software-Lebenszyklus
Aufbau eines IEC 62304-konformen Entwicklungsprozesses: Software Development Plan, Architecture Design, Unit/Integration/System Testing. Nahtlose Integration in agile Frameworks (Scrum, SAFe) mit vollständiger Traceability.
AI/ML Regulatory Framework
Erstellung von Predetermined Change Control Plans (PCCP) nach FDA AI/ML Action Plan. Dokumentation der Algorithm Training & Validation, Bias-Analyse und Continuous Learning Protocols für adaptive Algorithmen.
Cybersecurity & SBOM
Threat Modeling (STRIDE/DREAD), Software Bill of Materials (SBOM) und Vulnerability Disclosure nach FDA Premarket Cybersecurity Guidance und MDCG 2019-16. Penetration Testing und Security Risk Assessment.
Häufige Fragen zu Software as a Medical Device.
Wann gilt Software als Medizinprodukt?
Software gilt als Medizinprodukt (SaMD), wenn sie eigenständig einen medizinischen Zweck erfüllt – z.B. Diagnoseunterstützung, Therapieempfehlung oder Patientenüberwachung. Entscheidend ist die Zweckbestimmung, nicht die Plattform. Eine App auf dem Smartphone kann ein Klasse-IIb-Medizinprodukt sein.
Was ist der Unterschied zwischen SaMD und SiMD?
SaMD (Software as a Medical Device) ist eigenständige Software mit medizinischem Zweck. SiMD (Software in a Medical Device) ist Software, die in ein physisches Medizinprodukt eingebettet ist. Beide unterliegen IEC 62304, aber SaMD hat eigene Klassifizierungsregeln (MDR Regel 11, IMDRF).
Können wir agil entwickeln und trotzdem IEC 62304 konform sein?
Ja. IEC 62304 schreibt keine Wasserfall-Methodik vor. Agile Entwicklung ist vollständig kompatibel, wenn Sprint-Artefakte korrekt auf die geforderten Lebenszyklus-Dokumente gemappt werden: User Stories → Software Requirements, Sprint Reviews → Design Reviews, Definition of Done → Verification.
Was fordert die FDA bei KI/ML-basierten Medizinprodukten?
Die FDA erwartet einen Predetermined Change Control Plan (PCCP), der beschreibt, wie sich der Algorithmus nach Markteinführung verändern darf. Zusätzlich: Good Machine Learning Practice (GMLP), Dokumentation der Trainingsdaten, Bias-Mitigation und Real-World Performance Monitoring.
Verwandte Engineering Themen.
Software, die Behörden überzeugt.
Beschreiben Sie Ihr SaMD-Projekt – unsere Experten zeigen Ihnen den effizientesten Zulassungspfad.