Wer ein Medizinprodukt mit elektronischen Komponenten entwickelt, kommt an ISO 13485 nicht vorbei. Die Norm definiert die Anforderungen an ein Qualitätsmanagementsystem für Hersteller von Medizinprodukten und ist in vielen Märkten Voraussetzung für die Zulassung. Für Teams, die Hardware für Medizintechnik entwickeln, bedeutet das: Die Norm beeinflusst nicht nur den Zertifizierungsprozess am Ende, sondern jeden einzelnen Schritt der Elektronikentwicklung. Wer das erst spät erkennt, zahlt doppelt.
Dieser Artikel richtet sich an Produktmanager, CTOs und Entwicklungsteams, die ein Medtech-Hardwareprodukt zur Serienreife bringen wollen und verstehen müssen, wie ISO 13485 ihre Arbeit konkret beeinflusst.
Was ISO 13485 von anderen Qualitätsnormen unterscheidet
ISO 13485 ist keine Erweiterung von ISO 9001, auch wenn strukturelle Ähnlichkeiten bestehen. Der entscheidende Unterschied liegt im Risikoansatz: Während ISO 9001 auf kontinuierliche Verbesserung abzielt, fordert ISO 13485 die konsequente Risikobeherrschung über den gesamten Produktlebenszyklus. Die Norm ist explizit darauf ausgelegt, regulatorische Anforderungen für Medizinprodukte zu erfüllen, nicht die allgemeine Prozessqualität zu steigern.
Konkret bedeutet das für die Elektronikentwicklung: Jede Design-Entscheidung muss rückverfolgbar dokumentiert sein. Design-Input, Design-Output, Verifikation, Validierung und Design-Transfer sind formale Phasen mit definierten Freigabepunkten. Ein undokumentierter Bauteilwechsel, der in anderen Branchen als Routinevorgang gilt, kann im Medtech-Kontext eine vollständige Neubewertung des Designs auslösen. Die Norm fordert außerdem eine explizite Risikoanalyse nach ISO 14971, die direkt mit der Elektronikentwicklung verknüpft ist.
Für Teams, die IoT-Geräte oder Embedded Systems bisher außerhalb des Medtech-Umfelds entwickelt haben, ist der Sprung erheblich. Die Dokumentationspflicht betrifft nicht nur das Endprodukt, sondern den gesamten Entwicklungsprozess: Anforderungsmanagement, Testprotokolle, Lieferantenbewertungen und Änderungsmanagement müssen von Beginn an strukturiert aufgesetzt werden.
Konkrete Auswirkungen auf den Hardware-Entwicklungsprozess
ISO 13485 verändert, wie Hardware-Entwicklung operativ abläuft. Der Design Control Process schreibt vor, dass Design-Inputs (funktionale, leistungsbezogene und sicherheitsrelevante Anforderungen) vor Beginn der Entwicklung vollständig definiert und freigegeben sein müssen. Wer mit einem unvollständigen Lastenheft startet, erzeugt Nacharbeit, die im Medtech-Kontext nicht nur Zeit kostet, sondern den regulatorischen Nachweis gefährdet.
Bauteilauswahl und Lieferantenqualifizierung
Jeder Lieferant von sicherheitsrelevanten Komponenten muss bewertet und freigegeben sein. Das betrifft nicht nur Bauteile, sondern auch Fertigungsdienstleister und Softwarekomponenten. Bei einem typischen IoT-Medizinprodukt mit BLE-Konnektivität und einem ARM-Cortex-basierten Mikrocontroller bedeutet das: Der Modulhersteller, der PCB-Bestücker und der Anbieter des RTOS müssen in das Lieferantenmanagement eingebunden werden. Der Zeitaufwand dafür wird regelmäßig unterschätzt, besonders bei einer erstmaligen Zertifizierung.
Änderungsmanagement als kritischer Prozess
Jede Änderung an Hardware oder Firmware nach der Design-Freeze-Phase erfordert einen formalen Change-Control-Prozess. Das schließt eine erneute Risikobewertung ein, wenn die Änderung sicherheitsrelevante Funktionen betrifft. Ein Bauteilwechsel wegen Lieferengpass, der ohne diesen Prozess durchgeführt wird, kann die gesamte Zulassung gefährden. Teams, die agile Entwicklungsmethoden gewohnt sind, müssen hier explizit umdenken.
Typische Fehler bei der ISO-13485-konformen Entwicklung
Der häufigste Fehler ist ein zu später Start mit der Dokumentation. Teams entwickeln Hardware iterativ, halten Entscheidungen nicht fest und versuchen am Ende, die Dokumentation rückwirkend zu erstellen. Auditoren erkennen das. Fehlende Rückverfolgbarkeit zwischen Design-Inputs, Verifikationstests und den tatsächlich gebauten Prototypen ist ein häufiger Befund bei Zertifizierungsaudits und kann zu erheblichen Verzögerungen führen, typischerweise vier bis acht Wochen zusätzlich pro Auditdurchlauf.
Ein weiterer kritischer Punkt ist die Unterschätzung der Software-Klassifizierung. Firmware in einem Medizinprodukt fällt unter IEC 62304, die Sicherheitsklassen für medizinische Software definiert. Klasse B oder C erfordert deutlich umfangreichere Dokumentation und Testabdeckung, als viele Teams einplanen. Wer die Firmware-Architektur ohne Blick auf die IEC-62304-Anforderungen aufsetzt, muss unter Umständen die gesamte Softwarearchitektur überarbeiten. Das kostet bei einem mittleren Embedded-System-Projekt realistisch zwei bis vier Monate.
Ein häufig übersehenes Problem betrifft EMV und Biokompatibilität. EMC-Tests nach IEC 60601-1-2 für Medizingeräte sind strenger als CE-Anforderungen für Consumer Electronics. Wer das PCB-Layout nicht von Anfang an mit diesen Anforderungen im Blick entwirft, riskiert teure Überarbeitungen nach dem ersten EMV-Vortest. Besonders bei Wearables mit BLE-Funk und kleinen Formfaktoren ist das ein reales Risiko.
Zertifizierung vorbereiten: Worauf Entwicklungspartner achten sollten
Ein externer Entwicklungspartner für Elektronikentwicklung im Medtech-Kontext muss selbst ISO-13485-konform arbeiten oder zumindest nachweislich in der Lage sein, die erforderliche Dokumentation zu liefern. Das ist keine Formalität: Wenn ein Dienstleister keine Design History File aufbauen kann, fehlt dem Hersteller die Grundlage für die Zulassung. Bei der Auswahl eines Partners für IoT-Produktentwicklung im Medtech-Bereich sollte dieser Punkt vor der Beauftragung explizit geklärt werden.
Folgende Aspekte sollten bei der Vorbereitung auf die Zertifizierung von Beginn an adressiert sein:
- Design History File (DHF): Vollständige Dokumentation aller Entwicklungsphasen, Entscheidungen und Freigaben. Muss parallel zur Entwicklung aufgebaut werden, nicht nachträglich.
- Risikoanalyse nach ISO 14971: Muss mit der Elektronikentwicklung synchronisiert sein. Neue Risiken durch Hardware-Entscheidungen (z.B. Auswahl eines bestimmten Sensormoduls) müssen zeitnah bewertet werden.
- Verifikations- und Validierungsplan: Tests müssen anhand dokumentierter Design-Inputs bewertet werden. Ein Testprotokoll ohne Rückverfolgung zum Anforderungsdokument ist für den Auditor wertlos.
- Lieferantendokumentation: Qualifikationsnachweise, Datenblätter und Konformitätserklärungen für alle sicherheitsrelevanten Komponenten müssen archiviert sein.
- Software-Dokumentation nach IEC 62304: Softwareklassifizierung, Architektur, Unit-Tests und Anomaliemanagement müssen der Klasse entsprechend dokumentiert sein.
Der Zeitrahmen für eine erstmalige ISO-13485-Zertifizierung liegt realistisch bei zwölf bis achtzehn Monaten, wenn Qualitätsmanagementsystem und Produktentwicklung parallel aufgebaut werden. Wer das QMS erst nach Abschluss der Hardware-Entwicklung aufzusetzen versucht, verlängert diesen Zeitraum erheblich.
Wie Oxeltech bei der Medtech-Elektronikentwicklung unterstützt
Wir begleiten Medtech-Projekte von der ersten Hardware-Spezifikation bis zur Serienreife und verstehen die regulatorischen Anforderungen, die ISO-13485-konforme Entwicklung an jeden Prozessschritt stellt. Unsere Leistungen im Medtech-Kontext umfassen:
- Hardware-Design und PCB-Layout unter Berücksichtigung von IEC 60601-1-2 und EMC-Anforderungen
- Firmware-Entwicklung auf ARM-Cortex-Plattformen (STM32, NXP) mit Dokumentation nach IEC 62304
- Aufbau und Begleitun der Design History File parallel zur Entwicklung
- Integration drahtloser Kommunikation (BLE, NB-IoT, LTE-M) mit Blick auf Zertifizierungsrisiken
- Unterstützung bei Lieferantenqualifizierung und Vorbereitung auf Zertifizierungsaudits
Wir haben bereits über 20 Hardwareprodukte durch den gesamten Entwicklungs- und Zertifizierungsprozess begleitet. Wenn ein Medtech-Hardwareprojekt konkret wird und ein erfahrener Entwicklungspartner gesucht wird, der regulatorische Anforderungen von Anfang an mitdenkt, ist der nächste Schritt ein direktes Gespräch. Jetzt Kontakt aufnehmen und das Projekt gemeinsam einschätzen.
Ähnliche Artikel
- Wie funktioniert Herzfrequenz-Monitoring in einem Wearable-Gerät?
- Was ist der Unterschied zwischen Gesundheitsmonitoring und Fitness-Monitoring?
- Was ist Embedded-Softwareentwicklung?
- Wie integriert man GPS-Tracking energieeffizient in ein Wearable?
- Was kostet es, ein Wearable Gerät entwickeln zu lassen?
