Zertifizierungen für Embedded Software in der Medizintechnik

Zertifizierungen für Embedded Software in der Medizintechnik sind für viele Entwicklerinnen und Entwickler zunächst ein abstraktes Thema – bis das erste Produkt in Richtung klinischer Einsatz, Zulassung oder Serienfertigung geht. Dann wird schnell klar: In der Medizintechnik zählt nicht nur, dass die Software „funktioniert“, sondern dass sie nachweisbar sicher ist, Risiken systematisch beherrscht werden und alle Entwicklungsentscheidungen nachvollziehbar dokumentiert sind. Embedded Software steckt dabei in sehr unterschiedlichen Produkten: von Wearables und Diagnostikgeräten über Infusionspumpen bis zu bildgebenden Systemen oder vernetzten Implantat-Umgebungen. Je nach Produktklasse, Einsatzumgebung und Schnittstellen steigen die Anforderungen deutlich. Der Begriff „Zertifizierung“ wird im Alltag häufig verwendet, obwohl es juristisch und normativ oft um eine Mischung aus Qualitätsmanagement, Konformitätsbewertung, Normenerfüllung und Audits geht. Dieser Artikel zeigt, welche Standards, Regelwerke und Nachweise in Europa und international typischerweise relevant sind, wie sie zusammenhängen und wie Sie als Embedded-Entwickler Ihr Projekt so aufstellen, dass spätere Audits nicht zum Chaos werden.

Hinweis: Die folgenden Informationen dienen der allgemeinen Orientierung und ersetzen keine Rechts- oder Zulassungsberatung. Regulatorische Anforderungen hängen vom Gerätetyp, der Risikoklasse, dem Markt (EU, USA, international) und der konkreten Auslegung durch Benannte Stellen bzw. Behörden ab.

Was bedeutet „Zertifizierung“ bei Embedded Software überhaupt?

In der Medizintechnik gibt es selten eine einzelne „Software-Zertifizierung“, die man einmal besteht und danach ist alles erledigt. Stattdessen entsteht Konformität aus mehreren Bausteinen:

• Regulatorischer Rahmen: Gesetze und Vorgaben (z. B. EU MDR, FDA-Regeln), die definieren, wie ein Medizinprodukt in Verkehr gebracht werden darf.
• Qualitätsmanagementsystem (QMS): Prozesse, Verantwortlichkeiten und Nachweise, die zeigen, dass Entwicklung und Produktion kontrolliert ablaufen.
• Normen und Standards: anerkannte „Best Practices“, die häufig als Stand der Technik herangezogen werden.
• Konformitätsbewertung und Audit: Prüfung durch Benannte Stellen (EU) oder Inspektionen/Reviews (USA), bei denen Dokumente, Prozesse und Ergebnisse bewertet werden.

Für Embedded-Teams ist entscheidend: Nicht nur der Code zählt, sondern der vollständige Entwicklungsnachweis – inklusive Anforderungen, Architektur, Tests, Risikokontrollen, Cybersecurity, Änderungen und Release-Management.

EU-Perspektive: MDR, Software-Lebenszyklus und technische Dokumentation

In der EU bildet die Medizinprodukteverordnung (MDR) den Kern. Embedded Software fällt typischerweise als Bestandteil eines Medizinprodukts unter die MDR – oder als eigenständige Software (SaMD), wenn sie medizinische Zwecke erfüllt. Für Teams bedeutet das: Sie benötigen eine technische Dokumentation, die Sicherheits- und Leistungsanforderungen belegt, und Sie müssen ein QMS betreiben, das die Entwicklung kontrolliert.

Als Einstieg in den Rechtsrahmen eignet sich der offizielle EU-Text der MDR: EUR-Lex (EU-Rechtsakte, inklusive MDR).

Risikoklassen und ihre Auswirkungen

Je höher die Risikoklasse, desto strenger sind Anforderungen an Nachweise, Prüfungen und externe Bewertungen. Für Embedded Software wirkt sich das vor allem auf Testtiefe, Traceability, Risikomanagement und die formale Strenge der Dokumentation aus. In der Praxis steigt mit der Klasse typischerweise:

• der Umfang an geforderten Verifikations- und Validierungsnachweisen,
• die Tiefe der Risikoanalyse und die Strenge der Risikokontrollen,
• die Bedeutung eines formal sauberen Change- und Konfigurationsmanagements,
• die Erwartung an robuste Cybersecurity- und Update-Prozesse.

IEC 62304: Der Standard für den Software-Lebenszyklus

Wenn es um Embedded Software in Medizinprodukten geht, ist IEC 62304 einer der zentralen Standards. Er beschreibt, wie der Software-Lebenszyklus strukturiert werden soll – von der Planung über Anforderungen, Architektur und Implementierung bis zu Verifikation, Wartung und Problemmanagement. Wichtig: IEC 62304 fordert nicht „eine bestimmte Methode“, sondern nachvollziehbare, kontrollierte Prozesse mit klaren Ergebnissen und Dokumenten.

Software-Sicherheitsklassen (A, B, C)

IEC 62304 arbeitet mit Software-Sicherheitsklassen, die sich danach richten, welches potenzielle Schadensausmaß durch Softwarefehler entstehen kann. Diese Einstufung beeinflusst unter anderem:

• wie streng Architektur- und Detaildesign dokumentiert werden,
• welche Tests zwingend sind (z. B. auf Unit- oder Integrationsebene),
• wie eng Traceability zwischen Anforderungen, Risiken und Testfällen sein muss,
• wie systematisch Änderungen bewertet und freigegeben werden.

Traceability als Kernprinzip

Für viele Teams ist Traceability der größte Kulturwechsel: Jede relevante Anforderung muss bis in Tests und Ergebnisse rückverfolgbar sein. Umgekehrt muss jeder Test einen Zweck haben, der aus Anforderungen oder Risikokontrollen ableitbar ist. Ohne Tooling ist das fehleranfällig; mit gutem Requirements- und Test-Management wird es beherrschbar.

ISO 14971: Risikomanagement als roter Faden

ISO 14971 beschreibt, wie Risiken über den gesamten Produktlebenszyklus identifiziert, bewertet, kontrolliert und überwacht werden. Für Embedded Software bedeutet das: Risiken entstehen nicht nur durch Hardwaredefekte, sondern auch durch Timing-Probleme, Fehlinterpretation von Sensordaten, Kommunikationsabbrüche, Speicherfehler, UI-Missverständnisse, Cyberangriffe oder fehlerhafte Updates.

Typische Software-Risiken im Embedded-Kontext

• Fehlfunktionen durch Ressourcenengpässe: Stack-Overflow, Heap-Fragmentierung, Watchdog-Resets.
• Timing- und Concurrency-Probleme: Race Conditions, Prioritätsinversion, Deadlocks.
• Fehlerhafte Sensorfusion: falsche Filterparameter, Drift, Kalibrierfehler.
• Kommunikationsausfälle: unvollständige Datenpakete, Protokoll-Fehler, Störungen.
• Security-Schwachstellen: unsichere Keys, fehlende Authentifizierung, ungeschützte Debug-Interfaces.

Ein hilfreicher Ansatz ist, Risiko-Controls als konkrete Software- und Systemanforderungen zu formulieren (z. B. Plausibilitätsprüfungen, Safe-State-Mechanismen, sichere Boot-Ketten), und diese wiederum mit Tests zu belegen.

ISO 13485: Qualitätsmanagementsystem als Basis für Audits

ISO 13485 ist eine der wichtigsten QM-Normen in der Medizintechnik. Sie definiert, wie ein Unternehmen Prozesse aufbauen muss, um Medizinprodukte konsistent und regelkonform zu entwickeln und herzustellen. Für Embedded Software ist ISO 13485 deshalb so relevant, weil Audits häufig weniger „den Code“ prüfen, sondern die Prozessbeherrschung: Wer genehmigt Anforderungen? Wie werden Änderungen freigegeben? Wie wird dokumentiert, getestet, reviewt und released?

Was Auditoren bei Softwareprozessen häufig sehen wollen

• Rollen und Verantwortlichkeiten: klare Zuständigkeiten (Entwicklung, QA, Regulatory, Security).
• Dokumentlenkung: Versionierung, Freigaben, kontrollierte Vorlagen.
• Änderungsmanagement: Impact-Analyse, Risiko-Review, Regressionstests, Release-Freigabe.
• Lieferantenmanagement: Bewertung und Kontrolle externer Softwarekomponenten und Dienstleister.
• CAPA und Problemmanagement: systematischer Umgang mit Fehlern und Feldrückmeldungen.

Als Orientierung zur Normenwelt bietet die ISO-Seite eine Übersicht (auch wenn viele Inhalte kostenpflichtig sind): ISO (Internationale Normungsorganisation).

IEC 60601: Wenn Embedded Software in elektrischen Medizingeräten steckt

Für viele klassische Medizingeräte ist die IEC-60601-Familie relevant, insbesondere wenn elektrische Sicherheit und elektromagnetische Verträglichkeit (EMV) eine Rolle spielen. Auch wenn 60601 nicht „nur Software“ ist, beeinflusst sie Embedded-Entwicklung massiv: EMV-Störungen können Fehlmessungen verursachen, Reset-Schleifen auslösen oder Kommunikationswege stören. Daraus ergeben sich Anforderungen an Hardware-Design, Firmware-Robustheit und Tests.

EMV und robuste Firmware

In praktischen Projekten führt das häufig zu Softwaremaßnahmen wie:

• Fehlererkennung und -behandlung bei Kommunikationsprotokollen,
• Brownout-Detection und kontrollierte Restart-Strategien,
• Filterung und Plausibilitätsprüfungen bei Sensordaten,
• Watchdog-Konzepten, die nicht nur „resetten“, sondern Safe-States aktivieren.

Hintergrund zur IEC und ihren Standards finden Sie bei der internationalen Normungsorganisation: IEC (International Electrotechnical Commission).

IEC 62366-1: Usability Engineering und sichere Bedienung

Viele sicherheitskritische Vorfälle entstehen nicht durch „klassische Bugs“, sondern durch Bedienfehler, missverständliche Anzeigen oder unklare Alarme. IEC 62366-1 fokussiert auf Usability Engineering für Medizinprodukte. Für Embedded Software mit Display, Tasten, Touch oder Alarmsignalen ist das besonders wichtig, weil UI-Logik, Alarmprioritäten und Nutzerführung nachweisbar sicher gestaltet werden müssen.

Typische Embedded-Themen in der Usability-Dokumentation

• Alarmmanagement (Ton, Anzeige, Priorisierung, Quittierung),
• Fehlermeldungen und Recovery-Anleitungen am Gerät,
• Vermeidung gefährlicher Zustände durch UI-Design (z. B. Bestätigungsdialoge),
• Human-Factors-Risiken als Teil des Risikomanagements.

Cybersecurity und vernetzte Medizinprodukte: IEC 81001-5-1, FDA und internationale Leitlinien

Vernetzung ist heute Standard: WLAN, Bluetooth, Mobilfunk, Cloud-Anbindungen, Fernwartung, OTA-Updates. Damit wachsen Sicherheitsanforderungen stark. In Audits und Zulassungen werden zunehmend Fragen gestellt wie: Wie werden Updates signiert? Wie werden Schlüssel geschützt? Wie wird ein kompromittiertes Gerät erkannt? Welche Schwachstellenprozesse existieren? Für Embedded Teams bedeutet das: Security ist kein Add-on, sondern Teil des Entwicklungsnachweises.

Praktische Nachweise, die häufig erwartet werden

• Secure Boot und signierte Updates: kryptografisch geprüfte Firmware, Schutz vor Downgrade.
• Key-Management: sichere Speicherung, Rotation, Produktionsprozesse, Zugriffskontrolle.
• Threat Modeling: systematische Bedrohungsanalyse (z. B. über STRIDE-ähnliche Methoden).
• SBOM: Software Bill of Materials, um Abhängigkeiten und CVEs zu managen.
• Vulnerability Management: Prozesse für Meldungen, Bewertung, Patches und Kommunikation.

Für den US-Markt sind Informationen der FDA eine zentrale Quelle: FDA Medical Devices. Internationale Orientierung bietet außerdem das IMDRF: IMDRF (International Medical Device Regulators Forum).

Validierung, Verifikation und Teststrategie: Was „auditfest“ bedeutet

In regulierten Projekten reicht „wir haben getestet“ nicht aus. Entscheidend ist eine nachvollziehbare Teststrategie: Was wird warum getestet, mit welchen Methoden, nach welchen Akzeptanzkriterien, und mit welchen Ergebnissen? Besonders bei Embedded Software kommt hinzu, dass Tests auf unterschiedlichen Ebenen stattfinden müssen – vom Modul bis zum Gesamtsystem.

Testebenen, die in der Praxis relevant sind

• Unit-Tests: Logikmodule, Algorithmen, Treiber-Wrapper, Grenzwerte, Fehlerpfade.
• Integrationstests: Zusammenspiel von Treibern, RTOS, Middleware, Kommunikation.
• Systemtests: End-to-End-Funktionen am Zielgerät, inkl. Fehlerfällen und Safe-State.
• Verifikation von Risk Controls: Nachweis, dass Risikomaßnahmen wirksam sind.
• Regressionstests: Pflicht bei Änderungen, besonders bei Sicherheits- und Updatefunktionen.

Für Embedded Teams ist es hilfreich, früh festzulegen, welche Teile auf Hardware-in-the-Loop, Simulatoren, Emulation oder echte Geräte angewiesen sind, und wie Testdaten und Messaufbauten dokumentiert werden.

Konfigurations- und Änderungsmanagement: Ohne saubere Releases keine Konformität

Ein häufiger Engpass in Audits ist nicht die fehlende Technik, sondern fehlende Kontrolle über Versionen und Änderungen. „Welche Firmware lief in Testserie 3?“ oder „Welche Compiler-Optionen waren aktiv?“ sind Fragen, die im Alltag leicht untergehen – im Audit aber kritisch sind. Konfigurationsmanagement umfasst nicht nur Git, sondern auch Build-Reproduzierbarkeit, Toolchain-Kontrolle, Artefaktablage, Freigaben und Rückverfolgbarkeit.

Typische Bausteine eines robusten Release-Prozesses

• eindeutige Versionierung von Firmware, Bootloader, Konfigurationen und Hardware-Revisionen,
• reproduzierbare Builds (Build-Server, definierte Toolchain, gelockte Abhängigkeiten),
• formale Freigaben (QA/Regulatory) und dokumentierte Release Notes,
• Rückverfolgbarkeit von Anforderungen zu Testresultaten des Releases,
• Kontrolle über Debug-Features (JTAG/SWD, Logs, Test-Menüs) in Produktionsimages.

Third-Party-Software, Open Source und Lieferanten: Lizenz und Qualität gleichzeitig beherrschen

Embedded Projekte verwenden häufig externe Komponenten: RTOS, TCP/IP-Stacks, Kryptobibliotheken, Bluetooth-Stacks, Sensor-Firmware, Cloud-SDKs. In der Medizintechnik müssen Sie diese Komponenten doppelt im Blick behalten: technisch (Qualität, Updates, Sicherheitslücken) und rechtlich (Lizenzen, Nutzungsrechte, Verpflichtungen). Außerdem sind Lieferanten Teil des Qualitätsmanagements.

Was in der Praxis oft verlangt wird

• Lieferantenbewertung: Kriterien, Auswahl, Überwachung, ggf. Auditrechte.
• Nachweise zur Eignung: Dokumentation, Change Logs, Sicherheitsupdates, Supportzusagen.
• Lizenz-Compliance: Einhaltung von Bedingungen, Dokumentation der verwendeten Komponenten.
• SBOM und Patch-Prozess: transparente Abhängigkeiten und definierte Reaktion auf CVEs.

Wie Sie als Embedded-Entwickler das Thema pragmatisch angehen

Zertifizierungsanforderungen wirken schnell überwältigend. Gleichzeitig lässt sich vieles entdramatisieren, wenn Sie von Beginn an strukturiert arbeiten und typische Audit-Fragen antizipieren. Ein pragmatischer Einstieg ist, die Projektarbeit um wenige, aber konsequent gepflegte Artefakte zu organisieren.

Praxis-Checkliste für den Projektstart

• Scope klären: Ist es Medizinprodukt? Welche Märkte? Welche Risikoklasse? Welche Intended Use?
• Normen-Set definieren: z. B. IEC 62304, ISO 14971, ISO 13485, ggf. IEC 60601, IEC 62366-1, Security-Leitlinien.
• Traceability-Struktur festlegen: Anforderungen ↔ Risiken ↔ Tests ↔ Ergebnisse.
• Teststrategie früh planen: Ebenen, Tools, Messaufbauten, Abdeckung, Regression.
• Build- und Releaseprozess etablieren: reproduzierbar, versioniert, freigegeben.
• Security by Design: Secure Boot, signierte Updates, Key-Management, Threat Modeling.
• Dokumentvorlagen nutzen: spart Zeit und erhöht Konsistenz im Team.

Outbound-Links: Verlässliche Einstiegspunkte für Standards und Regulierung

• EUR-Lex (EU-Rechtsakte, inklusive MDR)
• ISO (Normenübersichten, u. a. ISO 13485 und ISO 14971)
• IEC (Normenübersichten, u. a. IEC 62304, IEC 60601, IEC 62366)
• FDA Medical Devices (US-Regelwerk und Leitfäden)
• IMDRF (internationale Leitlinien und Harmonisierung)

IoT-PCB-Design, Mikrocontroller-Programmierung & Firmware-Entwicklung

PCB Design • Arduino • Embedded Systems • Firmware

Ich biete professionelle Entwicklung von IoT-Hardware, einschließlich PCB-Design, Arduino- und Mikrocontroller-Programmierung sowie Firmware-Entwicklung. Die Lösungen werden zuverlässig, effizient und anwendungsorientiert umgesetzt – von der Konzeptphase bis zum funktionsfähigen Prototyp.

Diese Dienstleistung richtet sich an Unternehmen, Start-ups, Entwickler und Produktteams, die maßgeschneiderte Embedded- und IoT-Lösungen benötigen. Finden Sie mich auf Fiverr.

Leistungsumfang:

• IoT-PCB-Design & Schaltplanerstellung

• Leiterplattenlayout (mehrlagig, produktionstauglich)

• Arduino- & Mikrocontroller-Programmierung (z. B. ESP32, STM32, ATmega)

• Firmware-Entwicklung für Embedded Systems

• Sensor- & Aktor-Integration

• Kommunikation: Wi-Fi, Bluetooth, MQTT, I²C, SPI, UART

• Optimierung für Leistung, Stabilität & Energieeffizienz

Lieferumfang:

• Schaltpläne & PCB-Layouts

• Gerber- & Produktionsdaten

• Quellcode & Firmware

• Dokumentation & Support zur Integration

Arbeitsweise:Strukturiert • Zuverlässig • Hardware-nah • Produktorientiert

CTA:
Planen Sie ein IoT- oder Embedded-System-Projekt?
Kontaktieren Sie mich gerne für eine technische Abstimmung oder ein unverbindliches Angebot. Finden Sie mich auf Fiverr.