Entwicklung medizinischer Geräte: Die 6 Phasen vom Konzept bis zum Markt

Vor nicht allzu langer Zeit haben wir die Unternehmen im Gesundheitswesen untersucht, die weltweit führend sind in der Innovation. In fast jedem Profil stand eine ähnliche Erkenntnis fest: Die regulatorische Bereitschaft spielt eine ebenso wichtige Rolle wie das technische Fachwissen. In diesem Leitfaden geht es jedoch einen Schritt weiter und untersucht den Prozess, der diese beiden Aspekte zusammenbringt.
Die Entwicklung medizinischer Geräte ist der regulierte Engineeringprozess, der eine klinische Notwendigkeit in ein unter einem Qualitätsmanagement-System wie ISO 13485 zugelassenes Produkt umwandelt. Dieser Prozess umfasst die Konzeption und Machbarkeit, die Konstruktionskontrollen, das Prototyping, die Überprüfung und Validierung, die Zulassungsunterlagen sowie die Nachverfolgung nach der Markteinführung.

Das Folgende umfasst alle sechs Phasen sowie die Software, Hardware, die Konnektivität und die Einhaltung regulatorischer Anforderungen. Die Daten sind auch aktuell, was gerade wichtig ist: Die QMSR der FDA trat im Februar 2026 in Kraft, und die EU-MDR-Verlängerungsfristen sind so nah, dass man sie gut planen kann.

Die Entwicklung medizinischer Geräte ist die Ingenieurdisziplin, bei der eine klinische Notwendigkeit in ein zugelassenes Produkt umgewandelt wird, das innerhalb eines kontrollierten Qualitätsmanagementsystems hergestellt wird. Die Medizintechnikbranche bezeichnet diese Tätigkeit auch als Medizinprodukte-Design und -Entwicklung.

Was einen Prozess der Produktentwicklung für Medizinprodukte von einem normalen Prozess unterscheidet, ist die Nachverfolgbarkeit. Jede Designentscheidung muss auf eine Vorgabe zurückgeführt werden und von objektiven Belegen begleitet werden, dass die Vorgabe erfüllt wurde.

Diese einzige Einschränkung verändert alles. Ihre Architektur, Ihre Sprint-Frequenz, Ihre Lieferantenwahl und Ihre Teststrategie müssen sich an diese anpassen.

Was die Medizintechnikbranche als Medizinprodukt betrachtet, ist breiter gefasst als die meisten Teams erwarten. Eine Smartphone-App, die die Insulinmenge berechnet, ist ein Medizinprodukt. Gleiches gilt für eine Cloud-Service-Lösung, die eine Herzrhythmusstörung anhand von Daten aus tragbaren Geräten erkennt. FDA-Liste der KI-fähigen Medizinprodukte Bei der Aktualisierung im März 2026 wurden 1.400 Genehmigungen erteilt, Nur im Jahr 2025 wurden 331 Fälle aufgeklärt und die Mehrheit in der Radiologie.

Welche Klassifizierungsgruppen gelten für Medizinprodukte?

Die US-amerikanische Behörde für Lebensmittelsicherheit und Arzneimittel (FDA) sortiert Geräte nach Risikoklassen ein und Ihre Klassifizierung bestimmt fast alles über Ihre Zeitplanung und Ihr Budget.

• Klasse I (niedriger Risiko). Verbande, Untersuchungshandschuhe und manuelle Instrumente. Allgemeine Kontrollen gelten, und die meisten sind von der Vorabprüfungspflicht ausgenommen.
• Klasse II (mittlerer Risikograd). Infusionspumpen, Patientensensoren, die meisten angeschlossenen Geräte sowie die Mehrheit der SaMD. Sonderkontrollen gelten zusätzlich zu den allgemeinen Kontrollen, in der Regel über eine 510(k)-Zulassung. Viele Überwachungs- und therapeutische Geräte sind Klasse II, die Klassifizierung richtet sich jedoch nach der jeweiligen Geräteart und muss gemäß den geltenden Vorschriften, dem Produktcode, der vorgesehenen Verwendung und den technologischen Eigenschaften bestätigt werden.
• Klasse III (hoher Risikotyp). Geräte, die das Leben unterstützen oder aufrechterhalten, wie z. B. implantierbare Defibrillatoren. Diese benötigen eine vor dem Markteintritt (PMA) genehmigte Zulassung, die auf klinischen Daten basiert.

Überqueren Sie den Atlantik, und die Skala ändert sich. In der EU gelten unter der Medizinprodukteverordnung die Klassen I, IIa, IIb und III. Software erreicht oft eine höhere Klasse als die von den Teams vorhergesagte. Regel 11 der EU-MDR-Anhang VIII verschiebt viel diagnostische und therapeutische Software in die Klassen IIa oder darüber hinaus, was eine Notifizierungsstelle in das Projekt einbezieht.

SaMD oder eingebettete Software: Welche entwickeln Sie?

Software als Medizinprodukt (SaMD) ist Software, die für medizinische Zwecke entwickelt wurde und ihre Funktion selbstständig ausführt, ohne Teil einer Hardware-Einheit zu sein. Software in einem Medizinprodukt (SiMD), die in der Regel als eingebettete Firmware bezeichnet wird, wird innerhalb des Geräts ausgeführt und steuert die Hardware.

Diese Unterscheidung verändert Ihr Risikoprofil. In eingebettete Firmware sind oft Hardware-Verriegelungen als Risikokontrollen integriert; eine mechanische Druckentlastungsvorrichtung kann daher die Sicherheitsfunktion übernehmen, die sonst allein durch die Software erfüllt würde. Selbständige Software verfügt selten über diese Luxusfunktion, was ihre Sicherheitsklasse nach oben treibt.

Die meisten modernen Produkte bieten beides. Ein kontinuierlicher Blutzuckermessgerät verfügt über eine Sensor-Firmware, eine mobile App, eine Cloud-Backend-Plattform und ein klinisches Portal. Allesamt unterliegen diese Komponenten den gleichen Designanforderungen wie die Hardware.

Der Lebenszyklus der Entwicklung medizinischer Geräte umfasst sechs Entwicklungsphasen: Konzeption und Machbarkeit, Planungs- und Konstruktionskontrollen, Prototyping, Überprüfung und Validierung, Zulassungsantrag sowie die Übertragung auf die Produktion mit Nachverfolgung nach Markteinführung. Einige Teams bezeichnen dies als den Prozess für die Entwicklung neuer Produkte in der Medizinbranche. Diese Aktivitäten überschneiden sich in der Praxis häufig miteinander. Organisationen können Phasen-Schleusen, agile Schritten oder andere Lebenszyklusmodelle verwenden, vorausgesetzt, dass die Designkontrollen, das Risikomanagement, die Rückverfolgbarkeit, die Überprüfungen und die erforderlichen Nachweise eingehalten werden.

Hier ist der Zyklus der Produktentwicklung für medizinische Geräte als Ablauf, den Sie planen können:

1. Konzept und Machbarkeit. Definieren Sie die klinische Notwendigkeit und die beabsichtigte Anwendung. Beweisen Sie die risikoreichen technischen Annahmen.
2. Planungs- und Designkontrollen. Verwandeln Sie diese Bedürfnisse in Designinputs. Öffnen Sie die Design- und Entwicklungsdatei. Legen Sie den regulatorischen Pfad fest.
3. Prototyping. Stellen Sie immer repräsentativeres Hardware- und Software-Equipment her. Durchführen Sie formative Usability-Studien.
4. Verifizierung und Validierung. Dokumentieren Sie, dass das Design den Eingaben entspricht, und beweisen Sie anschließend, dass das Gerät auch bei echten Nutzern funktioniert.
5. Regulierungsantrag. Füllen Sie in den USA eine 510(k), De Novo oder PMA-Anmeldung aus. Verfolgen Sie die CE-Kennzeichnung durch eine notifizierte Stelle in der EU.
6. Überführung in die Fertigungsabteilung und die Überwachung nach der Markteinführung. Schritt 1: Pilotversuch, dann kommerzielle Produktion. Überwachung der Feldperformance und deren Weitergabe.

Was geschieht während des Konzepts- und Machbarkeitsanalyses?

Die Konzeption und Machbarkeit sind der Punkt, an dem die beabsichtigte Nutzung definiert und die Annahmen aufgehoben werden, die später das Projekt ruinieren könnten. Die Konzeption von Medizinprodukten ist der günstigste Schritt, an dem man Fehler machen kann, und die Teams knacken diese Fehler am häufigsten. Eine Phasenweise Entwicklungsmethode gibt es, um diesen Fehler kostengünstig zu vermeiden.

Deshalb hängt die Entwicklung von Medizinprodukten von zwei Fragen ab: Was ist die angestrebte Anwendung, und welche technischen Unbekannten könnten die ganze Sache unmöglich machen? Die zweite Frage erfordert echter Ingenieurwissen. Wenn Ihr Gerät auf optischen Sensoren in der Haut basiert, bauen Sie eine Probenaufbauvorrichtung und messen Sie die Signalqualität an echten Probanden, bevor jemand CAD-Dateien öffnet.

Die erste Frage erfordert noch mehr Sorgfalt, denn Ihre Erklärung zur vorgesehenen Verwendung ist die tragende Aussage des Projekts. Zusammen mit Ihren Ansprüchen und den technologischen Eigenschaften des Geräts bestimmt sie Ihre wahrscheinlichere Einstufung und die regulatorischen Anforderungen. Sie legt außerdem die Grenzen für die Angaben, die Sie auf der Etikettierung machen können. Teams, die die Erklärung unzusammenhängend früh verfassen, überschreiben später ihre Designvorlagen.

Planungs- und Designkontrollen: das Design- und Entwicklungsdateien

Designkontrollen sind der dokumentierte Designprozess, der die Nutzerbedürfnisse mit den Designeingaben und -ausgaben sowie den Beweismitteln, die diese belegen, verbindet. Sie bilden die Grundlage des Projekts und werden nun in der ISO 13485-Abschlußbestimmung 7.3 sowohl für die US- als auch für die EU-Ziele behandelt.

Es funktioniert folgendermaßen:

• Benötigungen des Benutzers. Was der Arzt oder die Patientin in ihrer Sprache benötigt.
• Design-Inputs. Ingenieurtechnische Anforderungen, die auf den Bedürfnissen der Benutzer und den regulatorischen Anforderungen basieren. Testbar, eindeutig und vollständig.
• Entwürfe als Ergebnisse. Zeichnungen, Schaltpläne, Quellcode, Designanforderungen und alles andere, was das Gerät definiert.
• Design-Verifizierung. Beweise dafür, dass die Leistungen die Inputs entsprechen.
• Design-Validierung. Beweis dafür, dass die fertige Vorrichtung in der vorgesehenen Umgebung für ihre Nutzer funktioniert.

Die Design- und Entwicklungsdatei ist die zusammengeführte Aufzeichnung dieser Verlaufsdatenbank und Ihre Audittrail für jede getroffene Designentscheidung. Klausel 7.3.10 verwendet diesen Namen, und die QMSR hat die ältere Design-Historie-Datei (DHF) aufgehoben, obwohl Sie sie in der Praxis noch immer hören werden.

Hierbei handelt es sich um Muster, die bei Projekten scheitern. Das Team behandelt dies als Dokumentation, die es erst nach Abschluss der Konstruktion zusammenstellen kann. Dann breitet sich eine Designänderung über achtzehn Monate unaufgezeichneter Entscheidungen aus, und jemand muss ein Viertel der Zeit damit verbringen, die Gründe aus Slack-Nachrichten und alten Pull-Requests neu zu erarbeiten.

Die Nachrüstung dieser Strecke kostet immer mehr als die Errichtung selbst. Setzen Sie in der ersten Woche ein Requirements-Management-Tool ein und verknüpfen Sie alle Anforderungen mit ihren Testfällen und deren Risikokontrolle.

Wie funktioniert das Prototypieren medizinischer Geräte in der Praxis?

Die Entwicklung von Prototypen für medizinische Geräte geht durch Phasen mit zunehmender Fäligkeit: von frühen Designkonzepten und einer Proof-of-Concept-Rigg bis hin zu realitätsnahen Modellen und designgestützten Pilotanlagen. Jede Phase beantwortet eine spezifischere Frage.

• Protokoll der Konzeption. Funktioniert überhaupt der Kerneingriff? Breadboards, Dev-Kits, kurzlebiger Code.
• Alpha. Integrierte Funktion auf benutzerdefinierten Hardware. Erste PCB-Fertigung, erste reale Gehäuseanfertigung, Firmware übernimmt die Arbeit.
• Beta. Materialien zur Produktentwicklung, repräsentativ genug für formative Usability-Studien.
• Pilotbau. Designfertig und auf der Produktionslinie gebaut: Die ersten marktreifen Prototyp-Einheiten werden zur Testvorlage verwendet.

Der Designfreeze ist der Meilenstein, der für den Zeitplan am wichtigsten ist. Nach dem Freeze kostet jede Änderung eine erneute Überprüfung und möglicherweise eine neue Einreichung. Vor dem Freeze sind Änderungen kostengünstig.

Also, wann fangen Sie an zu planen? Zu früh und Sie festlegen die Probleme, die der erste Prototyp nie aufgedeckt hat. Zu spät und die Designentwicklung untergräbt die bereits geleisteten Arbeit. Wir planen die Hardware vor der Software, weil Kostenkurve für Hardware-Iterationen Die Erhöhungen werden schneller durchgeführt, als dies mit der Software möglich ist, sobald die notwendigen Werkzeuge bereitgestellt sind.

Verifizierung und Validierung: die V-Modell-Anforderungen korrekt lesen

Die Verifikation stellt die Frage, ob Sie das Gerät gemäß den Spezifikationen gebaut haben. Die Validierung stellt die Frage, ob Sie das richtige Gerät für die Nutzer gebaut haben. Ingenieure verwenden beide Begriffe locker. Regulierungsbehörden verwenden sie präzise.

Das V-Modell visualisiert die Beziehung. Die Anforderungen zerfallen nach unten auf der linken Seite, von den Systemanforderungen über die Subsystem-Entwicklung bis hin zur Einheitliche Implementierung. Die Testabläufe steigen wieder auf die rechte Seite empor, wobei jedes Niveau dem gegenüberliegenden Zerfallsniveau entspricht. Die Designvalidierung beantwortet die Nutzerbedürfnisse an der Spitze.

Man hört oft behaupten, das V-Modell sei ein Fallstudienmodell, was aber falsch ist. Das V-Modell beschreibt die Beziehungen, die Ihre Beweismittel enthalten müssen, ohne jedoch die Reihenfolge der einzelnen Schritte zu beschreiben.

Was in dieser Phase tatsächlich passiert:

• Prüfung des Benches. Grundlegende Sicherheit und wesentliche Leistungsmerkmale gemäß IEC 60601, Umweltprüfung, elektromagnetische Verträglichkeit und Biokompatibilität für alle mit Patienten in Kontakt kommenden Geräte.
• Software-Überprüfung. Einheitliche Auslegung, Integration und anschließend Systemtests unter Berücksichtigung der Softwareanforderungen gemäß IEC 62304.
• Summative Usability-Validierung. Repräsentative Benutzer in einer repräsentativen Umgebung gemäß IEC 62366.
• Klinische Untersuchung. Nach der EU-Richtlinie MDR muss jedes Gerät eine Kennzeichnungseinrichtung besitzen. Ob dies auch für klinische Studien gilt, hängt von den bereits vorliegenen Daten ab. In den USA ist die Pflicht auf die Einreichung des Antrags sowie auf die Kennzeichnungseinrichtung selbst beschränkt.

Von diesen vier Punkten ist die Prüfung der elektrischen Sicherheit und der EMV derjenige, bei dem die Termine überschritten werden. Die Warteschlangen in akkreditierten Laboren dauern Wochen oder Monate, und ein Fehler führt oft zu einer Neuentwicklung und einem erneuten Verlassen der Warteschlange. Buchen Sie Ihre Termine so früh wie möglich.

Regulatorische Zulassungsvorschrift: 510(k), De Novo oder PMA?

Ihr Zulassungsverfahren hängt von Ihrer Geräteklasse sowie davon ab, ob es ein legal vermarktetes Vorprodukt gibt. Drei Wege gelten für fast alle Anträge in den USA.

510(k)-Prüfverfahren vor der Markteinführung Gilt für die meisten Geräte der Klasse II. Sie stellen eine erhebliche Ähnlichkeit zu einem bereits auf dem Markt erhältlichen Produkt nach. Im Rahmen des MDUFA V-Zusammenschlussvertrags hat die FDA das Ziel, innerhalb von 90 FDA-Tagen eine Entscheidung über 95% die Zulassungen der Kategorie 510(k) zu treffen. Die Kalenderzeit ist länger, da die FDA-Termine jegliche Zeiträume ausschließen, in denen die Einreichung aufgrund Ihrer Antwort stillsteht.

De-Novo-Klassifizierung Gilt, wenn Ihr Gerät ein niedriges oder mittleres Risiko aufweist und keine Vorlage verfügbar ist. Falls dies gewährt wird, erstellt die Behörde eine neue Klassifizierung mit speziellen Kontrollen, wodurch Sie für alle Personen, die Sie folgen, die Vorlage darstellen.

Vorverkaufsgenehmigung (PMA) Gilt für Klasse III. Sie beweisen die Sicherheit und Wirksamkeit des Geräts anhand Ihrer eigenen klinischen Daten, anstatt auf eine vorangegangene Studie zu setzen – daher trägt dies bei weitem die größte Menge an Beweismitteln und Gebühren.

In der EU erstellt der Hersteller die technische Dokumentation und folgt dem anwendbaren Konformitätsbewertungsverfahren. Für Geräte der Klassen IIa, IIb und III sowie für bestimmte Geräte der Klasse I, einschließlich steriler, messender und wiederverwendbarer chirurgischer Instrumente, ist die Beteiligung der Notifizierungsstelle erforderlich. Überprüfung durch die Notifizierungsstelle Allgemein berichtet bei 13 bis 18 Monaten, Die Kapazität variiert je nach Fahrzeugtyp und Gerät. Es handelt sich oft um den größten festen Block in einer EU-Zeitleiste.

Überführung in die Fertigung und Nachverfolgung nach Markteinführung

Der Designtransfer führt die Designergebnisse in validierte Produktionsspezifikationen um, und hier übernimmt die Fertigung von Medizinprodukten die Verantwortung. Die Nachverfolgung nach Markteinführung ist die kontinuierliche Erhebung von Felddaten, die wiederum in das Risikomanagement und das Design einfließen.

Der Designtransfer erfordert mehr Engineeringarbeit als der Name vermuten lässt. Sie validieren Produktionsprozesse für medizinische Geräte, qualifizieren Vertragspartner für die Fertigung, schreiben Inspektionskriterien und beweisen, dass die Linie Ihr Gerät wiederholt produzieren kann.

Probleme in der Fertigungsfähigkeit, die Sie während der Konstruktion verschoben haben, treten hier auf – die Spezifikationen der Linie können tatsächlich nicht erfüllt werden. Die Prozessvalidierung für alles, was nicht vollständig überprüft werden kann, wie beispielsweise Sterilisation oder eine versiegelte Schweißnaht, ist ein eigenständiges Projekt.

Anschließend wird das Gerät ausgeliefert. Die Abwicklung von Beschwerden, die Korrekturmaßnahmen und die Präventivmaßnahmen (CAPA), die Meldung von unerwünschten Ereignissen und die regelmäßigen Sicherheitsberichte gemäß der EU-Richtlinie MDR werden von Beginn an kontinuierlich durchgeführt.

Nehmen Sie dies aus einem simplen Grund ernst: Die Rückrufaktionen bei Medizinprodukten erreichten im Jahr 2024 ein Vierjahreshoch mit 1.059 US-Veranstaltungen, ein Anstieg von 8,6 Prozent gegenüber 2023. Class I erreichte ihr höchstes Niveau seit 15 Jahren. Die Geräteausfälle wurden zum ersten Mal seit über fünf Jahren die Hauptursache. Ihre Feedback-Funktion ist es, das Problem zu erkennen, bevor es zu einer Zahl wird.

Die Softwareentwicklung für medizinische Geräte folgt der IEC 62304, dem internationalen Standard für Softwarelebenszyklusprozesse in diesem Sektor. Sie erfordert, dass Software nach ihrer möglichen Schädigung klassifiziert wird, und dass anschließend eine angemessene Sorgfalt bei Architektur, detaillierter Planung, Tests und Instandhaltung angewendet wird.

Die Norm legt nicht fest, wie man Code schreibt. Sie legt fest, welche Prozesse existieren müssen und welche Beweismittel beibehalten werden müssen. Die technische Entscheidung liegt weiterhin bei Ihnen.

Was sind die Software-Sicherheitsklassen nach IEC 62304?

Es definiert drei Sicherheitsklassen für Software anhand der Schwere der Schäden, die ein Softwarefehler verursachen könnte. Klasse A bedeutet, dass keine Verletzungen möglich sind. Klasse B bedeutet, dass nicht-schwere Verletzungen möglich sind. Klasse C bedeutet, dass Tod oder schwere Verletzungen möglich sind.

Ihre Klassifizierung belastet Ihre Dokumentation. Klassifizierung A überspringt detaillierte Konstruktions- und Einheitsanforderungen. Klassifizierung C erfordert architektonisches Design, detaillierte Konstruktion bis auf die Einheitsstufe sowie Überprüfung auf allen Ebenen.

Bei unzureichendem Wissen über die Sicherheit von Software ist es wichtig, die Sicherheit der Software zu bewerten. Zwei Punkte fallen bei diesem Thema falsch aus. Die IEC 62304 ordnet dem Software-System zunächst eine Sicherheitsklasse zu. Bei der Zerlegung der Architektur können Softwareelementen eine andere Klasse zugewiesen werden, deren geeignete Begründung und effektive Trennung sie unterstützen. Bis eine Sicherheitsklasse für die Software festgelegt ist, gelten die Anforderungen der Klasse C.

Die Softwarearchitektur ist hier Ihr wichtigstes Instrument. Die Isolierung des sicherheitskritischen Teils in einen kleinen Class-C-Eintrag ermöglicht es, den Rest des Systems tiefer zu positionieren. Die Dokumentationskosten sind erheblich geringer, und der Sicherheitsaspekt ist umso stärker, da Die Segregation der eingebetteten medizinischen Software gemäß IEC 62304 und ISO 13485 Er übernimmt die architektonische Disziplin bereits beim ersten Sprint.

Was ändert sich in der IEC 62304-Ausgabe 2?

Die Ausgabe 2 ersetzt die drei Sicherheitsklassen durch zwei Softwareprozess-Stufen und erweitert den Anwendungsbereich der Norm von medizinischen Gerätensoftware auf Gesundheitssoftware. Darüber hinaus wird eine normative Klausel zur KI-Planung hinzugefügt und die allgemeinen QMS-Klauseln werden in die ISO 13485 integriert. Level I ersetzt etwa Klasse A. Level II vereint Klasse B und Klasse C in eine hohe Stufe.

Seien Sie vorsichtig mit der Zeitachse, da sie immer wieder verschoben wurde. Ausgabe 2 ist noch ein Entwurf.

In früheren Kommentaren wurde auf eine Veröffentlichung im Jahr 2026 hingewiesen. Die Arbeitsgruppe hatte dann rund 1.500 Kommentare zur Prüfung des ersten Ausschussentwurfs und verteilt nun einen zweiten Entwurf. Status-Tracker des Johner Institute Die endgültige Entwurfsphase wird frühestens 2028 stattfinden, im Gegensatz zur Prognose der IEC, die Ende 2028 veröffentlicht werden soll. Andere Kommentatoren erwarten weiterhin 2027.

Was das für Sie bedeutet: EN 62304:2006+A1:2015 bleibt in der EU die harmonisierte Version, und die formale Anerkennung einer neuen Ausgabe verläuft typischerweise zwei bis drei Jahre nach der Veröffentlichung. Entwerfen Sie heute gegen Edition 1. Wenn Ihre Software derzeit Klasse B hat, modellieren Sie die spätere Zusammenführung in die Level II bereits jetzt, da Ihre Anforderungen an die Dichte der Prüfung zunehmen.

Kann man in einem regulierten Softwareprojekt agilen arbeiten?

Ja. Die agile Softwareentwicklung für medizinische Geräte ist kompatibel mit IEC 62304, das prozessunabhängig ist. AAMI TIR45 wurde speziell entwickelt, um agile Praktiken an die Anforderungen des Standards anzugleichen. Was agile Ihnen nicht bietet, ist eine Ausnahme von der Dokumentationspflicht.

Was funktioniert in der Praxis:

• Ergänzungen definieren als vollständig dokumentiert. Eine Story ist abgeschlossen, wenn die Anforderungen, der Code, die Tests, die Verlaufsverknüpfungen und die Risikobewertung aktualisiert wurden. Nicht, wenn der Code zusammengefügt wird.
• Behalten Sie das Design-Freeze-Konzept beibehalten. Agile innerhalb einer Phase, zwischen den Phasen eingegrenzt.
• Automatisieren Sie die Rückverfolgbarkeit. Anforderungstool ist mit dem Issue-Tracker verknüpft, dessen Ergebnisse dem CI-Bericht entnommen werden. Manuelle Trace-Matrixen verfallen innerhalb weniger Wochen.
• Behandle die Risikobewertung als lebendiges Werkzeug. Jeder Schritt überprüft, ob neue Gefahren entstanden sind.

Die ehrliche Spannung: Agile optimiert sich, um auf Veränderungen zu reagieren, während Designkontrollen sich optimieren, um Veränderungen zu steuern. Sie lösen dies, indem Sie schnell handeln, bevor es zu Designstopp kommt, und bewusst erst nach dem Stopp.

Warum Cybersicherheit jetzt Ihre Freigabe blockieren kann

Die Dokumentation im Bereich Cybersicherheit ist ein Kriterium für die Zulassung auf dem Markt. Nach Artikel 524B des FD&C Act müssen Cyber-Geräte im Rahmen der Vorabmeldung eine maschinenlesbare Software-Materialbeschreibung (SBOM) sowie einen Plan zur Behebung von Sicherheitslücken nach dem Markteintritt vorlegen.

Die Einzelheiten finden sich in der Anleitung. Die FDA veröffentlichte am 3. Februar 2026 eine aktualisierte endgültige Version, Cybersecurity in Medizinprodukten: Überlegungen zu Qualitätsmanagementsystemen und Inhalt der Unterlagen vor Markteinführung, Die Überarbeitung ersetzt die Version vom Juni 2025. Die Überschreibung auf „Qualitätsmanagement-System“ veranschaulicht den Übergang zu QMSR im Folgenden.

Was Sie der Behörde schulden:

• Ein sicheres Produktentwicklungskonzept, das in Ihren bestehenden Designprozess integriert ist
• Ein Threat-Modell plus Sicherheitsarchitektur
• Ein maschinenlesbares SBOM, das kommerzielle, Open-Source- und handelsübliche Komponenten umfasst, mit Metadaten zu Version und Supportstatus
• Ein dokumentiertes Verfahren zur Überwachung und Aktualisierung von Sicherheitslücken nach der Markteinführung
• Beweismittel für Sicherheitstests, einschließlich Penetrationstests und Fuzzing

Verpassen Sie dies, wird die Gebühr sofort fällig. Ein unzureichender SBOM allein kann die Entscheidung „Ablehnen“ auslösen, eine Richtlinie, die die FDA seit dem 1. Oktober 2023 bei Cyber-Geräten angewendet hat.

Die Überprüfung ist angesichts der installierten Basis nicht überraschend. Die Analyse von Cynerio für 2022 In rund 10 Millionen Geräten in mehr als 300 Krankenhäusern wurden 53% angeschlossene medizinische und IoT-Geräte mit einer bekannten kritischen Sicherheitslücke gefunden. Diese Zahl beschreibt Krankenhausflotten und nicht die Anzahl der Geräte, die ausgeliefert wurden. Da sie jedoch bereits älter ist, gilt sie als Indikator für die Gesamtzahl.

KI und maschinelles Lernen in einem regulierten Gerät

Geräte mit KI folgen denselben Regeln wie alle anderen Geräte – mit einer Besonderheit, die die Kosten beeinflusst: Ein vorgegebener Änderungskontrollplan (PCCP) ermöglicht Ihnen, bestimmte Modifikationen des Modells vorab zu autorisieren, sodass Sie diese ohne erneute Übermittlung einsetzen können.

Ein PCCP nennt die genauen zulässigen Änderungen sowie das Protokoll, das regelt, wie jede dieser Änderungen implementiert und validiert wird, sowie eine Folgenabschätzung, die zeigt, dass das Gerät innerhalb dieser Grenzen weiterhin sicher ist. Die FDA hat seine endgültige Fassung veröffentlicht. Empfehlungen für die Marktforschungsunterlagen für PCCPs Die Abdeckung der Funktionen der Software für KI-fähige Geräte soll im August 2025 abgeschlossen sein. Alles, was außerhalb des Plans liegt, muss weiterhin eingereicht werden.

Schreiben Sie Ihre eigene entsprechend der Ingenieurskompetenz. Die Verbesserung der Genauigkeit ist keine Modifizierung der Beschreibung. Die Wiederholung der Trainingsprozedur mit zusätzlichen Daten aus derselben Population erfolgt unter der Voraussetzung, dass die Empfindlichkeit bei einem festgelegten Testset bei oder über 0,90 liegt.

In Europa gilt KI in einem unter die MDR-Verordnung fallenden Gerät standardmäßig als hochrisiko-KI gemäß der AI Act, und die Bewertung wird in die bestehende MDR-Überprüfung Ihrer Notifizierungsstelle einbezogen.

Die Frist wurde kürzlich verlängert, und sie gilt nun als gesetzliches Regelwerk. Verordnung (EU) 2026/1744, Mit dem „Digitalen Omnibus zur KI“ trat am 27. Juli 2026 eine Verordnung in Kraft, die die Höchstgrenze für die Risikogruppe „KI“ für Produkte, die in Anhang I aufgeführt sind, einschließlich medizinischer Geräte, auf 2. August 2028 verlängert.

Unter beiden Regimen verläuft die technische Arbeit identisch. Die Integration von KI und ML in eine regulierte Medizin-Applikation Betrifft die Datenmodellverwaltung, die Versionskontrolle des Modells, die Validierung, die nach der Weiterbildung erhalten bleibt, sowie einen Rückrufpfad, den Sie nachweisen können.

Die Entwicklung von Medizinprodukten für das Internet der Dinge bedeutet, dass gleichzeitig vier verschiedene technische Bereiche bearbeitet werden: Elektronik und mechanische Hardware, eingebettete Firmware, Konnektivität und Cloud-Software. Das Schwierigste ist die Koordination. Änderungen in einem Bereich haben Auswirkungen auf die anderen Bereiche und auf Ihre Risikodateien.

Dies ist der Teil des Lebenszyklus, an dem regulatorische Berater und Designagenturen mitwirken. Hier entsteht auch die meiste Zeitüberschreitung.

Was beinhaltet die Hardware-Überwachung?

Die Hardware-Laufzeit umfasst die Erfassung von Schaltungszeichnungen, die Layoutplanung von Leiterplatten, die Beschaffung von Bauteilen, die elektromechanische Konstruktion und die anschließende Gehäuse- und Umweltprüfung. Jede dieser Schritte erfordert eine lange Vorlaufzeit und ist in Folge gegenseitig abhängig.

• Die PCB-Spinnvorgänge dauern jeweils mehrere Wochen. Zwei bis vier Spinnen sind für ein erstes Gerät normal, und jeder Zyklus bedeutet Herstellung, Montage, Inbetriebnahme und dann Debugging.
• Die Beschaffung von Komponenten beschränkt Ihre Designmöglichkeiten. Alles Wesentliche müssen aus Drittanbietern bezogen werden. Ein Einzelteil mit einer Lieferzeit von 40 Wochen kann ein Programm zum Stillstand bringen.
• Werkzeugfertigung für Gehäuse verlangt Zeit und Geld. Spritzgusswerkzeug ist teuer und schwer zu ändern, weshalb die Hardware-Freeze-Phase vor der Software-Freeze-Phase erfolgt.
• Die Auswahl der Sensoren ist eine systembezogene Entscheidung. Die Signalqualität, die Stromaufnahme, die Kalibrierdrift und die Biokompatibilität interagieren miteinander. Die Auswahl von Sensoren für ein medizinisches Gerät ist eine Architekturentscheidung.

Yalantis betreibt genau aus diesem Grund in Warschau ein internes Forschungs- und Entwicklungslabor. Die Iteration der Hardware im selben Gebäude wie das Firmware-Team reduziert die Debug-Schleife.

Warum die Wahl der Firmware-Sprache wichtiger ist als früher

Die eingebettete Firmware trägt die Verantwortung für kritische Sicherheitsaspekte, was die Sicherheit der Speicherinhalte zu einem technischen Problem macht, anstatt einer stilistischen Präferenz. Überlaufende Puffer, Use-After-Free-Angriffe, Datenflusssituationen und Stackskorruption sind genau die Fehlermuster, die die zuvor aufgeführten Software-Aufforderungen zur Folge haben.

Rust eliminiert die meisten davon bereits beim Kompilieren, während es das deterministische, keine-allocator-Verhalten beibehält, das die eingeschränkten eingebetteten Ziele erfordern. Der Kompromiss ist real: Die Qualifizierung der Toolchain und die Vertrautheit des Teams kosten sowohl im Vorfeld etwas, und die Reife der Bibliothek variiert je nach Ziel. Ob Rust verdient seinen Platz in der medizinischen Firmware Es kommt darauf an, wie sehr Ihr Sicherheitsfall auf der Korrektheit der Speicherinformationen beruht.

Wie gestaltet man die Bluetooth-Verbindung für ein medizinisches Gerät?

Bluetooth Low Energy (BLE) ist aufgrund seines Leistungsprofils die Standard-Verbindung für tragbare und mobile Geräte. Die Entwicklung medizinischer Geräte mit Bluetooth Low Energy beginnt mit der Annahme, dass die Funkverbindung unzuverlässig ist. Daher muss die Datenintegrität bei einem Abfall der Verbindung erhalten bleiben.

Wo die BLE-Medizintechnik-Projekte scheitern:

• Die Konnektivität soll stets verfügbar sein. Das ist nicht der Fall. Das Gerät muss lokal zwischenspeichern und die Verbindung wiederherstellen, sobald sie wiederhergestellt ist. Das Datenverlust bei einer Trennung stellt eine Frage der Patientensicherheit dar.
• Das Unterbewerten der Kombination und Integration von UX-Elementen. Evaluierendes Usability-Testing belohnt verwirrende Kombinationen nicht gut.
• Das Verpassen der Sicherheitsanalyse auf der Linkebene. Pairing-Modus, Schlüsselverwaltung, Schlüsselspeicherung und Man-in-the-Middle-Resistenz gehören alle zu Ihrem Bedrohungsmodell.
• Das Zusammenleben wird ignoriert. In Krankenhausumgebungen ist die Frequenz 2,4 GHz überfüllt. Test unter realistischen RF-Bedingungen.
• Das Verpassen des OTA-Updatepfads. Abschnitt 524B legt eine Verpflichtung fest, dass Sie die Patches installieren können. Ein Gerät, das nicht sicher aktualisiert werden kann, birgt eine unkontrollierte Sicherheitslücke.

Der Updatepfad ist jener, den die meisten Teams unterschätzen. Die überflüssige Übertragung von Sicherheitskritischen Updates ist ein eigenständiges Designproblem. Man benötigt signierte Images, atomaren Apply, verifizierte Rollback und eine Antwort darauf, was geschieht, wenn die Stromversorgung während des Schreibvorgangs ausfällt. Dies sind: Allgemeine Probleme der Architektur von angeschlossenen Geräten die eine dimension der Patienten-Sicherheit erlangen, sobald ein Arzt auf die Ergebnisse angewiesen ist.

Von dem Gerät zum Cloud-Speicher

Die Cloud-Ebene erbt regulatorische Verantwortlichkeiten, wann immer sie eine medizinische Funktion ausführt. Wenn Ihr Backend den Algorithmus ausführt, der die klinischen Ergebnisse generiert, ist Ihr Backend Teil des Geräts.

Teams erkennen die Folgen erst spät. Ihr Bereitstellungszyklus unterliegt dem Änderungscontrolling. Ihre Infrastruktur steht in Ihrem Risikomanagement im Mittelpunkt. Interoperabilität durch HL7 und FHIR wird stattdessen bereits im Entwurf berücksichtigt – anstatt als Nachwirkung einer Integration. Wo Sie die Grenze ziehen Grenze zwischen Hardware des Geräts und Cloud-Softwaree bestimmt, wie viel Ihrer Backend-Inhalte in den regulierten Rahmen fällt.

ISO 14971 ist der internationale Standard für das Risikomanagement bei der Entwicklung medizinischer Geräte. Er sieht einen kontinuierlichen Zyklus vor, bei dem die mit den medizinischen Geräten verbundenen Risiken identifiziert, geschätzt und bewertet werden, Kontrollen implementiert und die Wirksamkeit dieser Kontrollen überprüft wird – dies über den gesamten Entwicklungszyklus hinweg.

Nehmen Sie das Wort „kontinuierlich“ wörtlich. Risikomanagement ist kein Dokument, das Sie für den Prüfer erstellen. Es ist der Mechanismus, der Ihre Architektur, Ihre Testprioritäten, Ihre Software-Sicherheitsklasse und Ihr Human-Factors-Protokoll bestimmt.

Die ISO 14971-Schleife:

1. Risikomanagementplan. Der Umfang, die Verantwortlichkeiten, die Prüfer und die Annahmekriterien werden Ihnen vor der Bewertung dieser Punkte angezeigt.
2. Hazard-Identifizierung. Was kann schiefgehen – von Hardwarefehlern über Benutzerfehler bis hin zu Sicherheitsverletzungen.
3. Risikoabschätzung. Schwerigkeit und Wahrscheinlichkeit der Auftritt bei jeder Gefahrensituation.
4. Risikokontrolle. In strenger Reihenfolge der Priorität: Erst das Gefährdungspotenzial ausschließen, dann Schutzmaßnahmen ergreifen und schließlich auf Kennzeichnung vertrauen.
5. Bewertung des Restrisikos. Was nach den Kontrollen übrig bleibt, sowohl einzeln als auch insgesamt.
6. Nachbearbeitungstätigkeiten. Die Felddaten werden zurückgesendet und können jeden zuvor geschlossenen Schritt wieder öffnen.

Diese Reihenfolge der Vorrange im vierten Schritt ist eine strenge Vorgabe. Man kann eine Gefahr nicht mit einer Warnhinweis-Etikett vermeiden, wenn eine Designänderung sie hätte beseitigen können.

Das muss nicht immer sofort perfekt sein. Niemand kann die erste Hazard-Analyse richtig machen, und das ist zu erwarten. Was zählt, ist, ob sie ein lebendiges Artefakt bleibt, das bei jeder Designänderung noch einmal überprüft wird, oder ob sie zu einer Tabellenkalkulation wird, die niemand seit dem Start der Entwicklung mehr geöffnet hat.

Menschliche Faktoren und Usability Engineering (IEC 62366)

Die IEC 62366 ist die Norm für die Anwendung der Human-Factors-Engineering-Methodik bei Medizinprodukten. Sie existiert, weil Bedienfehler bei Patienten eine Häufigkeit aufweisen, die mit der Fehlfunktion der Komponenten vergleichbar ist, und sie behandelt die Schnittstellenkonstruktion als Risikokontrolle.

Diese Risikokontrolle gliedert sich in zwei Studien. Die Formulierungsstudien werden während der Konzeption durchgeführt und prägen das Interface. Die abschließende Studie prüft, ob ausgebildete Benutzer kritische Aufgaben sicher ausführen können, und dies geschieht auf Grundlage des fertigen Designs. Versäumnis in dieser Hinsicht zu spät führt zu einer enormen Kostenbelastung, da eine Korrektur eine Neukonzeption, dann erneutes Testen und dann eine weitere abschließende Runde bedeutet.

Zwei Rahmenwerke bestimmen die Qualität bei den meisten Herstellern von Medizinprodukten. ISO 13485:2016 ist der internationale Qualitätsmanagementsystem-Standard für Medizinprodukte und gilt nun auch in den USA gemäß der QMSR-Verordnung.

Die QMSR änderte das Bild der USA im Februar 2026

Die FDA Verordnung über das Qualitätsmanagementsystem (QMSR) ist am 2. Februar 2026 in Kraft getreten und ersetzt die ehemalige Qualitätsmanagement-Verordnung (QSR) und enthält die ISO 13485:2016 in ihrer Referenz in 21 CFR Teil 820.

In der Praxis bedeutet dies, dass die Einhaltung der ISO 13485 nun eine regulatorische Vorgabe der US-Regulierungsbehörden ist, wobei spezielle für die jeweilige Behörde festgelegte Ergänzungen in den Abschnitten 820 Unterabschnitte A und B enthalten sind. Die Designkontrollen finden in Klausel 7.3 statt, anstatt in der alten 21 CFR 820.30. Die Behörde hat außerdem die Quality System Inspection Technique (QSIT) abgeschafft und stattdessen ein aktualisiertes Kontrollprogramm eingeführt.

Wenn Ihre QMS-Dokumentation weiterhin die Kennzeichnung 820.30 für die Designkontrollen verwendet, ist diese veraltet. Das ist wichtiger als die Aufforderung zur Aktualisierung der Daten. Analyseschluss der ECA Academy Von den Mitteilungen über die Warnungen zu Geräten im Geschäftsjahr 2025 wurden 38 von 44 beigefügt, was im Vergleich zum Vorjahr 27 war.

EU-MDR und die noch bevorstehenden Übergangsfristen

Die EU-Richtlinie MDR 2017/745 gilt seit Mai 2021 für neue Geräte, wobei verlängerte Fristen für ältere Geräte gelten, die ältere MDD-Zertifikate besitzen. Diese Fristen stehen nun kurz bevor.

Die Datumsangaben sind nach Klasse aufgeteilt. Geräte der Klasse III und implantierbare Geräte der Klasse IIb können bis zum 31. Dezember 2027 auf dem Markt bleiben. Andere Geräte der Klasse IIb sowie Geräte der Klassen IIa und IIIs/Im haben bis zum 31. Dezember 2028 Zeit. Beide sind davon abhängig, dass bestimmte Voraussetzungen vor 2024 erfüllt wurden, darunter ein MDR-konformes Qualitätsmanagementsystem und eine eingereichte Anmeldung beim Notifizierungsamt.

Das gegenüber der Überprüfung durch die Notifizierungsstelle zu setzen, die 13 bis 18 Monate dauert, macht die Rechnung für alle unschön, die eine Umstellung bis 2027 planen.

Die Entwicklungsdauer für medizinische Geräte reicht von drei bis sieben Jahren von der Konzeption bis zur Markteinführung, und die Kosten für die Entwicklung medizinischer Geräte variieren in den verschiedenen Kategorien um eine Größenordnung.

Der Benchmark, den alle zitieren, stammt von einem Studie von Stanford im Jahr 2010 unter 204 Unternehmen der Medizintechnikbranche. Das ergab für ein 510(k)-Gerät einen durchschnittlichen Kostenaufwand von rund $31 Millionen und für ein Class III PMA-Gerät rund $94 Millionen.

Verhalten Sie sich mit diesen Zahlen vorsichtig. Die Studie stammt aus dem Jahr 2010 und wurde von Branchenverbänden gesponsert. Die FDA bestritt damals die Methodik. Außerdem wird in der Studie das gesamte Unternehmenskapital gemessen, statt nur einen Ingenieurbetrag.

Die Zahlen, die Sie heute überprüfen können, beziehen sich auf die Gebühren. Eine Standard-PMA kostet im Jahr 2026 einen Nutzerbeitrag von $579.272, während eine 510(k)-Anmeldung $26.067 kostet – bevor Sie für einen einzigen Test oder eine einzelne Patientin/Patienten bezahlt haben. Die Gebühren werden alle 1. Oktober neu festgelegt.

Was tatsächlich die Zeitspanne für die Entwicklung Ihrer Medizinprodukte bestimmt:

• Geräteklasse und Pfad. Ein 510(k)-Verfahren mit sauberem Prädikat ist ein anderes Projekt als ein De Novo-Projekt.
• Klinische Evidenz. Ein entscheidender klinischer Versuch verlängert die Dauer der Behandlung um Jahre und ist in der Regel die größte Einzelkostenpost.
• Hardwarekomplexität. Jede Änderung bei der PCB-Fertigung oder beim Werkzeugbau ist Zeit, die man nicht verkürzen kann.
• Außenläden. Die Kapazität der Notifizierungsstelle und des Testlabors ist nicht Ihrer Kontrolle unterstellt.
• Software-Sicherheitsklasse. Die Überprüfungskosten in der Klasse C sind wesentlich höher als in der Klasse B.
• Neues Design aufgrund spät entdeckter Probleme. Der einzige Fahrer, den Sie tatsächlich beeinflussen können.

In diesem letzten Fall kommt die Ingenieurskompetenz zum Tragen. Ein abschließender Fehler nach dem Designfreeze, ein fehlerhafter Anforderungenstrang bei der Vorbereitung der Einreichung, ein EMC-Fehler, der eine Neugestaltung der Platine erfordert: Jeder dieser Fehler kostet ein Viertel oder mehr, und jeder wäre vermeidbar, wenn man die Arbeit frühzeitig rigoros angehen würde.

Frontloading bedeutet nicht, übertrieben zu sein. Verbringen Sie echtes Geld in die Machbarkeit, stimmen Sie über eine Vorab-Einreichung mit der Agentur ab, bevor Sie sich auf einen Testplan festlegen, bauen Sie bereits von Anfang an die Traceability mit Tools auf und buchen Sie frühzeitig externe Zeitfenster. Durchführen Sie kontinuierlich Formationsstudien, damit die abschließende Studie nicht überrascht, sondern vielmehr bestätigt, was erreicht wurde.

Die Phasen bleiben konstant. Die Beweislast und der technologische Schwerpunkt ändern sich je nach Gerätetyp erheblich.

Wie sich der gleiche Prozess je nach Gerätformat ändert

Herzgeräte. Die Entwicklung von Herzgeräten umfasst ein breites Spektrum. EKG-Monitore und Holter-Recorder fallen in der Regel in die Klasse II gemäß der 510(k)-Verordnung, während implantierbare Therapien in die Klasse III und eine entscheidende klinische Prüfung führen können. Implantierbare Geräte stellen darüber hinaus zusätzliche Leistungs- und Biokompatibilitätsanforderungen dar. Die Softwareklasse richtet sich nach der Gefahranalyse jedes einzelnen Produkts, sodass die Trennung die meisten Komponenten auf eine niedrigere Stufe beschränkt, wobei nur der Therapiepfad in der Klasse C geführt wird.

Tragebare Monitore. Die Entwicklung tragbarer medizinischer Geräte fällt typischerweise in die Klasse II. Der Schwerpunkt der Entwicklungsarbeit liegt auf der Sensor-Signalqualität und der Energieverwaltung, wobei die Zuverlässigkeit von BLE in etwa gleichrangig ist. Die Validierung von Algorithmen in verschiedenen Populationen stellt die klinische Evidenz dar.

Diagnosesoftware und SaMD. Klasse II in den USA, oft IIa oder höher in der EU gemäß Regel 11. Es sind keine Hardwarerisikokontrollen verfügbar, daher ist die Sicherheitsklasse der Software hoch. Die Repräsentativität der Datensätze wird zur zentralen Beweissicherungslage.

Atmungs-Geräte. Die IEC 60601-Elektrosicherheitsanforderungen sowie die Alarmanforderungen gemäß IEC 60601-1-8 stellen ein Problem der Mensch-Maschine-Interaktion dar. Die Alarmkonstruktion ist sowohl ein Problem der menschlichen Faktoren als auch ein Risikoproblem zugleich und ist unnachgiebig.

Die Markteinführung einer Medizinprodukteanlage erfordert eine präzise Planung, was fast jede andere Art von Ingenieursleistung übertrifft. Die Teams, die termingerecht ihre Produkte auf den Markt brachten, investierten realen Geld in die Machbarkeit und öffneten ihre Konstruktions- und Entwicklungsdateien bereits in der ersten Woche. Sie behielten außerdem ihre Risikodokumentation von Beginn bis zum Abschluss des Projekts aufrecht.

Der schwierigste Teil besteht selten in einer einzelnen Phase. Es geht darum, Hardware, Firmware, Konnektivität, Cloud-Software und die Einhaltung regulatorischer Anforderungen so zu koordinieren, dass alle fünf Komponenten gleichzeitig funktionieren. Dieser Koordinierungsproblem ist der Grund, warum die Aufteilung der Arbeit auf eine Designagentur, einen Firmware-Anbieter, einen regulatorischen Berater und ein Cloud-Team tendenziell mehr Kosten verursacht als eine vollständige Zusammenarbeit zwischen einem Team.

Wenn Sie ein Geräteprogramm planen und Ihre Roadmap, Zeitpläne oder Architektur unter Druck testen möchten, freuen sich unsere Ingenieure für medizinische Geräte sehr über ein Gespräch dazu. Bringen Sie Ihre schwierigste offene Frage mit.