Embedded-Systeme in der Medizintechnik folgen anderen Regeln als in der Consumer-Elektronik oder der Industrieautomation. Der Entwicklungsprozess ist nicht nur technisch anspruchsvoller, er ist regulatorisch bedingt komplex. Wer ein Hardwareprodukt in diesem Bereich entwickeln will, steht vor einer Kombination aus strengen Normen, sicherheitskritischer Softwarearchitektur und langen Zertifizierungszyklen, die Timelines und Budgets fundamental beeinflussen. Fehler in der Planung kosten hier nicht nur Zeit, sie können die Markteinführung um Monate verzögern oder eine vollständige Redesign-Runde erzwingen.
Dieser Artikel richtet sich an Teams, die ein medizinisches Gerät mit eingebetteter Software entwickeln oder outsourcen wollen. Die folgenden Abschnitte behandeln die regulatorischen Rahmenbedingungen, sicherheitskritische Architekturentscheidungen, EMV-Anforderungen, drahtlose Konnektivität und die häufigsten Fehler, die erfahrene Teams trotzdem machen.
Regulatorische Anforderungen, die den Entwicklungsprozess prägen
Medizinprodukte in der EU unterliegen der MDR 2017/745, in den USA dem FDA 21 CFR Part 820 bzw. der neueren QSR. Beide Frameworks verlangen einen dokumentierten, rückverfolgbaren Entwicklungsprozess, der nicht nachträglich aufgebaut werden kann. Wer die technische Dokumentation erst am Ende des Projekts zusammenstellt, scheitert an der Zertifizierung, nicht an der Technik.
Die IEC 62304 definiert den Software-Lebenszyklus für Medizinprodukte und klassifiziert Software in drei Sicherheitsklassen (A, B, C). Klasse C, bei der ein Softwarefehler zu ernstem Schaden führen kann, verlangt vollständige Unit-Tests, Traceability vom Requirement bis zum Testfall und eine formale Risikoanalyse nach ISO 14971. Der Aufwand für Klasse-C-Software ist gegenüber einem vergleichbaren Industrie-Embedded-Projekt typischerweise zwei- bis dreimal höher. Teams, die diesen Mehraufwand im initialen Projektplan nicht einkalkulieren, geraten spätestens beim Pre-Submission-Meeting mit der Benannten Stelle unter Druck.
Ein häufig unterschätzter Punkt: Die Klassifizierung des Geräts bestimmt den regulatorischen Pfad, nicht die Komplexität der Hardware. Ein einfaches BLE-Pflaster, das Vitaldaten überträgt, kann als Klasse IIa oder IIb eingestuft werden und damit ein vollständiges klinisches Bewertungsverfahren auslösen. Diese Klassifizierung sollte in der Konzeptphase, nicht nach dem ersten Prototyp, festgelegt werden.
Sicherheitskritische Softwarearchitektur in eingebetteten Systemen
Die Wahl des RTOS ist bei medizinischen Embedded-Systemen keine Geschmacksfrage. FreeRTOS ist weit verbreitet und gut dokumentiert, aber für IEC 62304 Klasse C fehlt eine formale Zertifizierung. Zephyr RTOS bietet eine aktivere Open-Source-Community und wachsende Unterstützung für medizinische Anwendungen, ist aber in der Zertifizierungsdokumentation noch weniger standardisiert. Kommerzielle RTOS-Lösungen wie INTEGRITY oder ThreadX (jetzt Azure RTOS) kommen mit vorhandenen Safety-Zertifikaten, kosten aber je nach Lizenzmodell zwischen 5.000 und 50.000 Euro pro Projekt.
Watchdog-Mechanismen und Fehlerbehandlung
Ein häufiger Fehler: Teams implementieren einen Hardware-Watchdog, behandeln aber nicht den Fall, dass der Watchdog durch einen hängenden Task im normalen Betrieb regelmäßig getriggert wird, obwohl das System in einem degradierten Zustand ist. Der Watchdog löst nicht aus, das Gerät scheint zu laufen, liefert aber fehlerhafte Messwerte. In einem Monitoring-Gerät für Intensivpatienten ist das ein sicherheitskritischer Zustand, der in der Risikoanalyse explizit adressiert sein muss.
Memory-Protection-Units (MPU) auf ARM-Cortex-M-Prozessoren sind in medizinischen Anwendungen kein optionales Feature. Ohne MPU kann ein fehlerhafter Pointer in einer nicht-sicherheitskritischen Task den sicherheitskritischen Stack korrumpieren. Die MPU-Konfiguration muss zum Zeitpunkt des Architekturentwurfs feststehen, nicht im Debugging nachgezogen werden.
Hardwaredesign unter medizinischen EMV- und Sicherheitsnormen
Medizinische Geräte müssen die IEC 60601-1-2 erfüllen, die EMV-Anforderungen für die Heimumgebung und klinische Umgebungen definiert. Die Grenzwerte für Störaussendung und Störfestigkeit sind strenger als die CE-Grundanforderungen nach CISPR 32. Wer ein Design für CE entwickelt und erst am Ende auf 60601-1-2 testet, riskiert einen Testfehler, der ein komplettes PCB-Redesign erzwingt.
Konkret: Hochfrequente Schaltregler auf dem PCB sind die häufigste Ursache für EMV-Testfehler bei medizinischen Geräten. Ein Boost-Converter bei 2 MHz kann harmonische Störungen bis in den GHz-Bereich erzeugen, die die Empfangsempfindlichkeit eines integrierten BLE-Moduls um 10 bis 15 dBm verschlechtern. Das ist kein theoretisches Risiko, sondern ein reproduzierbares Problem, das durch frühzeitige Pre-Compliance-Tests in der Entwicklungsphase erkannt werden kann, typischerweise für 2.000 bis 5.000 Euro, verglichen mit 20.000 bis 40.000 Euro für eine vollständige Testkampagne nach dem finalen Design.
Die IEC 60601-1 (Grundnorm) verlangt zusätzlich eine Risikobewertung elektrischer Sicherheitsaspekte, inklusive Kriechstrecken, Luft- und Isolationsabstände. Bei batteriebetriebenen Geräten ohne Netzanschluss sind die Anforderungen weniger restriktiv, aber nicht irrelevant. Ein 3,7-V-LiPo mit externem USB-Ladeport fällt je nach Ladeelektronik unter andere Schutzklassenanforderungen als ein rein batteriebetriebenes Gerät ohne externe Verbindung. Schaltplanentwurf und Simulation sollten diese Anforderungen von Beginn an berücksichtigen, nicht als nachgelagerten Prüfschritt.
Drahtlose Konnektivität in Medizinprodukten sicher integrieren
BLE ist die dominante Funktechnologie für körpernahe medizinische Geräte, aber die Integration in ein zertifizierungspflichtiges Produkt ist nicht trivial. Vorhandene FCC/CE-zertifizierte Module wie Nordic nRF52840 oder u-blox NINA-B4 reduzieren den Zertifizierungsaufwand erheblich, entbinden aber nicht von der Pflicht, die Funkleistung im finalen Gehäuse zu validieren. Metallgehäuse oder leitfähige Beschichtungen können die Antenneneffizienz um 6 bis 12 dB reduzieren, was die Reichweite und Verbindungsstabilität unter realen Nutzungsbedingungen stark beeinträchtigt.
Cybersecurity als regulatorische Anforderung
Seit 2021 verlangt die FDA für vernetzte Medizinprodukte eine explizite Cybersecurity-Dokumentation als Teil des 510(k)- oder PMA-Submissions. In der EU gilt seit 2024 der Cyber Resilience Act als zusätzliche Anforderung neben der MDR. Das bedeutet konkret: OTA-Update-Mechanismen müssen kryptografisch abgesichert sein, Kommunikationskanäle verschlüsselt, und der Bootloader muss Secure Boot unterstützen.
Ein Fehler, den Teams bei der Auswahl von Konnektivitätsmodulen machen: Sie wählen ein Modul primär nach Preis und Verfügbarkeit, ohne zu prüfen, ob der Hersteller langfristigen Firmware-Support und Sicherheitsupdates garantiert. Bei einem Gerät mit einer geplanten Marktlebensdauer von 7 bis 10 Jahren ist ein Modul, dessen Hersteller in 3 Jahren keine Security-Patches mehr liefert, ein regulatorisches Risiko, das die gesamte Produktlinie betreffen kann.
Typische Fallstricke bei der Medizintechnik-Entwicklung
Der häufigste und teuerste Fehler ist das Verschieben der regulatorischen Planung auf die zweite Projekthälfte. Teams, die mit einem funktionierenden Prototyp in die Zertifizierungsphase einsteigen, ohne vorher eine Design History File aufgebaut zu haben, müssen retrospektiv dokumentieren, was nicht dokumentiert wurde. Das kostet 3 bis 6 Monate und macht Teile der Entwicklungsarbeit nicht rückverfolgbar.
Ein zweiter Fallstrick ist die Unterschätzung der Usability-Anforderungen nach IEC 62366. Für Klasse-IIa-Geräte und höher ist eine formale Usability-Evaluierung mit repräsentativen Nutzern Pflicht. Das ist kein UX-Workshop, sondern ein dokumentierter Prozess mit definierten Nutzungsszenarien, Risikoanalyse und Summative Evaluation. Teams, die diesen Prozess nicht in den Entwicklungszeitplan integrieren, verzögern die technische Dokumentation.
Ein dritter, weniger offensichtlicher Fallstrick betrifft die Komponentenauswahl. Medizintechnik-Projekte haben typischerweise Produktlebenszyklen von 7 bis 15 Jahren. Ein Mikrocontroller, der heute verfügbar ist, kann in 5 Jahren obsolet sein. Ohne eine formale Obsoleszenzstrategie und Alternativkomponenten in der Stückliste riskiert man, in der Serienproduktion auf nicht verfügbare Bauteile zu stoßen, was ein erneutes Design-Verification-Testing auslösen kann.
Den richtigen Entwicklungspartner für Medizinprodukte wählen
Die Auswahl eines Embedded-Entwicklungspartners für medizinische Geräte unterscheidet sich grundlegend von der Beauftragung eines allgemeinen Elektronikentwicklung Dienstleisters. Der Partner muss nicht nur technisch kompetent sein, er muss den regulatorischen Prozess kennen und in seiner eigenen Arbeitsweise abbilden können.
Konkrete Prüfpunkte bei der Partnerauswahl:
- Hat der Partner nachweislich Produkte durch MDR- oder FDA-Zertifizierung geführt, oder beschreibt er nur Kenntnisse der Normen?
- Arbeitet das Team mit einem formalen Design-Control-Prozess, der IEC 62304-konform ist, oder wird Dokumentation nachgelagert erstellt?
- Kann der Partner Pre-Compliance-EMV-Tests in der Entwicklungsphase koordinieren oder hat er Zugang zu entsprechenden Testlaboren?
- Wie geht der Partner mit Komponentenobsoleszenz und langfristiger Stücklisten-Pflege um?
- Gibt es Erfahrung mit der spezifischen Geräteklasse, also nicht nur allgemeine Medizintechnik-Erfahrung, sondern Kenntnis der spezifischen Normen für die geplante Anwendung?
Teams, die Hardwareentwicklung outsourcen, sollten außerdem prüfen, ob der Partner in der Lage ist, die technische Dokumentation so aufzubauen, dass sie intern weitergeführt werden kann. Abhängigkeit von einem einzigen externen Partner für die gesamte Dokumentationspflege ist ein operatives Risiko, das sich spätestens bei einer FDA-Inspektion oder einem Post-Market-Surveillance-Bericht materialisiert.
Wie Oxeltech bei der Embedded-Entwicklung für Medizintechnik unterstützt
Wir entwickeln Embedded-Systeme und Hardware für medizinische Anwendungen, mit einem Prozess, der regulatorische Anforderungen von Beginn an einschließt. Unser Ansatz deckt den gesamten Entwicklungszyklus ab, vom ersten Konzept bis zur Serienreife:
- Hardware-Design und Simulation unter Berücksichtigung von IEC 60601-1 und IEC 60601-1-2, inklusive Pre-Compliance-EMV-Planung bereits im Schaltplanentwurf
- Firmware-Entwicklung nach IEC 62304, mit Traceability von Requirements bis zu Testfällen und Unterstützung bei der Klassifizierung der Softwaresicherheitsklasse
- Drahtlose Konnektivität für BLE, Wi-Fi, NB-IoT und weitere Protokolle, mit Fokus auf Cybersecurity-Anforderungen nach FDA Guidance und Cyber Resilience Act
- Zertifizierungsbegleitung für CE nach MDR und FDA-Submissions, inklusive Aufbau der technischen Dokumentation und Design History File
- Prototypenentwicklung und Fehlersuche bis zur Serienproduktionsreife, mit Obsoleszenzstrategie und langfristiger Stücklisten-Pflege
Wir haben über 20 Hardwareprodukte durch den gesamten Zyklus von der Idee bis zur Markteinführung begleitet. Wenn Sie ein medizinisches Gerät entwickeln und einen Partner suchen, der den regulatorischen Prozess kennt und technisch sauber umsetzt, sprechen Sie uns an. Nehmen Sie Kontakt auf und beschreiben Sie Ihr Projekt. Wir melden uns innerhalb von 24 Stunden.
Ähnliche Artikel
- IoT Entwicklung beauftragen: Die richtigen Fragen im ersten Meeting
- Kann man ein Wearable ohne proprietäre Chips kosteneffizient entwickeln?
- Wann sollte ein Unternehmen einen externen Hardwareentwickler beauftragen?
- Wie funktioniert die Firmware-Entwicklung für IoT-Geräte?
- Was ist der Unterschied zwischen einem Wearable für Menschen und für Tiere?
