Ein Leitfaden zu IEC 62304 und ISO 13485 für eingebettete Medizingätesoftware

In einem unserer neuesten Artikel zu Die Integration von KI/ML in regulierte Medizinprodukte, In diesem Artikel haben wir erläutert, wie maschinelles Lernen das Spiel in der Medizintechnik verändert. Um in regulierten Märkten ernst genommen zu werden, benötigt Ihre Software eine Struktur. Das bedeutet solide Prozesse, klare Dokumentation und Systeme, die auch dann funktionieren, wenn Ihr Produkt aus dem Labor heraus in die reale Welt geht.

Diesmal beschäftigen wir uns mit der Software für eingebettete medizinische Geräte. Also lassen Sie uns gleich ins Detail gehen: Sauberer Code ist nicht alles (vor allem wenn die Patientensicherheit auf dem Spiel steht!). Ein einziger Fehler oder ein fehlendes Risikomanagement kann schnell zu etwas Ernsthaften werden.

Deshalb sind die IEC 62304 und die ISO 13485 für Embedded-Systeme so wichtig. Die eine legt fest, wie man medizinische Software entwickelt, während die andere die Regeln für das Qualitätsmanagementsystem festlegt. Zusammen bieten sie Ihnen das notwendige Fundament, um jederzeit konform zu bleiben, sicher zu arbeiten und jederzeit für Audits gerüstet zu sein.

Ein kurzer Blick auf das, was wir untersuchen werden:

• Warum IEC 62304 und ISO 13485-Anliegen für Embedded-Medizintechniksoftware
• Was oft schief geht, wenn es kein formeller Entwicklungsprozess
• Wie Risikomanagementt beeinflusst Design, Testen und Dokumentation
• Was arbeitet Einhaltung Es sieht so aus
• Erfahrungsbasierte Schulung Aus eingebetteten Projekten haben wir dabei geholfen, sie zum Leben zu erwecken.

Was passiert, wenn Eingebettete Software Wenn ein medizinisches Gerät fehlschlägt?

Das kann eine fehlende Herzschlagrate oder eine falsche Dosis des Medikaments bedeuten. Deshalb sind integrierte Softwarestandards für medizinische Geräte wie IEC 62304 wichtig.

IEC 62304 Es ist der Standard für die Entwicklung medizinischer Geräte-Software, wobei die Patientensicherheit an erster Stelle steht. Es definiert Ihren Softwareentwicklungsprozess (SDLC), der Teil Ihres Qualitätsmanagementsystems nach ISO 13485 ist. Der Standard legt fest, wie Ihr Entwicklungsprozess ablaufen sollte.

Das ist besonders wichtig für eingebettete Systeme, wo Softwarerisiken oft erst sichtbar werden, wenn etwas kaputt geht. Die IEC 62304 hilft Ihnen, die Dinge vorhersehbar zu gestalten, besonders dann, wenn es entscheidend ist.

Verständnis für Softwarerisiken

Einer der ersten Schritte in IEC 62304 besteht darin, herauszufinden, wie riskant Ihre Software sein könnte, falls etwas schiefgeht. Dieser Prozess wird als Software-Sicherheitsklassifizierung bezeichnet. Er legt den Ton für die notwendige Vollständigkeit Ihres Prozesses fest.

Insgesamt soll dieser Standard nicht das Leben für Sie erschweren, sondern sicherstellen, dass das Gerät bei der Auslieferung sicher ist (sicher nach dem Design, sicher in der Produktion und sicher, selbst wenn es zu Problemen kommt).

Sie können die IEC 62304 befolgen, gute Code schreiben und sie ordnungsgemäß testen. Ohne die entsprechende Einhaltung der ISO 13485 wird Ihre Arbeit jedoch bei einer Prüfung nicht bestehen.

Die IEC 62304 definiert, wie Sie Ihre Software entwickeln und pflegen. Die ISO 13485 ist das Qualitätsmanagementsystem, das diesen Prozess umgibt. Wenn diese beiden Standards nicht übereinstimmen, geraten die Dinge außer Kontrolle (in der Regel zu der schlimmsten Zeit überhaupt).

ISO 13485 ist der internationale Standard für Qualitätsmanagementsysteme für Medizinprodukte. Es beschreibt, wie Sie Design, Lieferanten, Produktion und nach dem Markteintritt betreffende Maßnahmen managen. Obwohl es keine spezifischen Regeln für Software enthält, bietet es den Rahmen, in dem Ihre 62304-konformen Entwicklung stattfinden muss.

Wie es mit eingebettetem Softwarecode verbunden ist

ISO 13485 mag für das Qualitätsmanagementteam eine Herausforderung sein, aber wenn Sie an embeddeden medizinischen Software arbeiten, wirkt sie direkt auf Ihre Arbeit aus.

Sie können erst dann mit der Codeentwicklung beginnen, wenn Ihre Anforderungen gemäß den Anforderungen des QMS ordnungsgemäß dokumentiert und genehmigt sind. Wenn Sie Open-Source- oder Drittanbieterbibliotheken verwenden, gelten diese als Lieferanten und müssen von Ihnen überprüft und dokumentiert werden.

Wenn später eine Beschwerde wegen der Software eingereicht wird, könnte dies zu einer CAPA führen. Sie müssen erklären, was schiefgelaufen ist, wie Sie es behoben haben und wie Sie verhindern, dass es sich wiederholt.

Das alles geschieht außerhalb Ihres IDE, aber es prägt die Art und Weise, wie Ihr Team arbeitet. Deshalb ist die ISO 13485 wichtig. Sie stellt sicher, dass Ihre Software nicht nur funktionsfähig ist, sondern auch nachvollziehbar und bereit für die Anwendung ist. Zertifizierung.

Warum es wichtig ist

Sie können die IEC 62304 befolgen und solide Code schreiben. Aber wenn Ihr Qualitätsmanagement-System für medizinische Geräte dies nicht unterstützt, kann die Prüfung trotzdem scheitern.

Auditorien sind sich bewusst, wie Entscheidungen getroffen und Risiken bewältigt werden. Wenn Ihr QMS dies nicht dokumentiert, besteht ein Mangel.

Diese Ausrichtung ist nicht mehr etwas, was man aus dem Kontext ableiten kann. Starten 2. Februar 2026, das neue Programm der FDA Verordnung über das Qualitätsmanagementsystem (QMSR) er ersetzt offiziell das langjährige QSR (21 CFR Teil 820) das, worauf US-Hersteller seit Jahrzehnten vertrauen.

Was hier wirklich verändert wird, ist die Grundlage. Mit QMSR hat die FDA Berücksichtigt die Norm ISO 13485:2016. Kurz gesagt: Für US-Unternehmen wird die Einhaltung der ISO 13485 nicht mehr optional sein. Wenn Ihr Qualitätsmanagementsystem heute nur unzureichend an die ISO angepasst ist, wird diese Lücke eine Rolle spielen.

Dies verändert auch die Art und Weise, wie Audits ablaufen. Die FDA verlässt sich zunehmend auf die traditionelle Methode. QSIT-Inspektionmodell und die Einführung eines neuen Inspektionsansatzes, der auf der QMSR basiert. Für viele Teams bedeutet das weniger vorhersehbare Checklisten und mehr Fokus darauf, wie das Qualitätsmanagementsystem im Alltag tatsächlich funktioniert.

Für Softwareteams ist der Effekt sofort spürbar: Die Aufzeichnung von Daten wird strenger gestaltet, insbesondere in Bezug auf Beschwerden und Service-Daten. Und etablierte FDA-Prozesse wie DHF, DMR und DHR sind sich dem ISO-Format zuwandern Medizintechnikdatei (MDF).

Der Kernpunkt ist einfach: Ob man sich auf Europa oder die USA konzentriert, Die Entwicklung der IEC 62304 innerhalb eines ISO 13485-konformen Qualitätsmanagementsystems wird schnell zur gemeinsamen Referenznorm..

Sobald Sie das Ziel von IEC 62304 und seine Integration in die ISO 13485 verstanden haben, stellt sich die nächste logische Frage: Wie arbeiten Sie tatsächlich mit diesem Standard? Die Norm beschreibt mehrere Kernprozesse, die jede konforme Software für medizinische Geräte durchlaufen muss. Anstatt diese als trockene Formalitäten zu betrachten, hilft es, jedes Verfahren als Lösung eines praktischen Problems während der Entwicklung zu betrachten. Jeder dieser Prozesse unterliegt den Design- und Entwicklungskontrollen der ISO 13485.

Planung der Softwareentwicklung

Bevor etwas gebaut werden kann, braucht man einen Plan. Wer macht was? Wie ist die Organisation der Arbeit? Welche Sicherheitsstufe gilt?

Hier legen Sie die Erwartungen fest und definieren, welche Dokumente für die Rückverfolgbarkeit erforderlich sind. Bei Klassenebenen B oder C gehören dazu oft Architekturdiagramme, Testpläne und Rückverfolgbarkeitstabellen.
Der Plan ist Teil Ihrer ISO 13485-Dokumentation und zeigt, dass Sie von Anfang an eine Struktur aufgebaut haben.

Softwareanforderungsanalyse

Dieser Schritt verbindet Funktionalität mit Risiko. Jedes Anforderungsprofil muss mit den in ISO 14971 definierten Risikokontrollen übereinstimmen.

Warum? Weil, wenn eine Funktion Risiken vermeidet, muss man dies nachweisen können. Jede Anforderung sollte mit etwas in Ihrer Risikodatei verknüpft sein. Das ist genau das, was Auditoren (und auch Ihr zukünftiges Selbst) erwarten werden. Nach ISO 13485 müssen diese Anforderungen überprüft und validiert werden, wodurch 62304 direkt in die umfassenderen Pflichten des QMS integriert wird.

Softwarearchitekturgestaltung

Jetzt ist der Zeitpunkt, um zu entscheiden, wie alles zusammenpasst. Geschwindigkeit ist wichtig, aber es ist auch wichtig, sicherzustellen, dass das System auch bei einem Fehler funktionieren kann.

Eine gute Architektur trennt kritische Funktionen von nicht-kritischen. Auf diese Weise kann ein Fehler, falls er auftritt, das gesamte System nicht lahmlegen. Für Class-C-Software kann diese Struktur festlegen, wie viel Testen und Überprüfung erforderlich ist.

Software-Detailplanung

Hier skizzieren Sie, wie jede Komponente sich verhalten wird. Sie dokumentieren, wie die Komponente Daten erhält, verarbeitet und zurückgibt.

Agile Teams könnten hier zögern. Aber selbst bei iterativer Entwicklung ist dieses Detailniveau nützlich. Es sorgt dafür, dass alle auf dem gleichen Stand sind. Und wenn Sie die Verifizierung durchlaufen haben, werden Sie froh sein, dass die Grundvoraussetzungen bereits vorhanden sind.

Implementierung und Überprüfung der Softwareeinheit

Jetzt ist es an der Zeit, den Code zu schreiben und sicherzustellen, dass jede Funktion ihre Funktion erfüllt. Die Anzahl der Tests hängt von der Sicherheitsklasse der Software ab.

Bei der Klasse A sind grundlegende Tests oft ausreichend. Bei der Klasse C hingegen ist mehr Sorgfalt erforderlich (z. B. Code-Reviews, Abdeckungstests und manchmal auch statische Analyse). In der Tat, je höher das Risiko, desto tiefer müssen Sie gehen.

Softwareintegration und Systemtests

Sobald die Bauteile getestet sind, werden sie zusammengefügt. In der Tat spielt diese Phase eine Schlüsselrolle bei der Validierung eingebetteter Software für medizinische Geräte.

Die Integrationsprüfung überprüft, wie gut Komponenten zusammenarbeiten. Die Systemprüfung betrachtet die Software als Ganzes. Funktioniert sie wie vorgesehen? Ist sie sicher? Ihre Prüfung sollte beide Aspekte bestätigen und auf die ursprünglichen Anforderungen zurückverfolgen.

Software-Version

Die Veröffentlichung einer Build-Version ist eine formale Entscheidung, die mit Verantwortung einhergeht.

Zu diesem Zeitpunkt sollten Sie die Tests abgeschlossen haben, die Versionsverläufe überwacht und bekannte Probleme dokumentiert haben. Alles, was für die Zertifizierung erforderlich ist, sollte vorhanden sein.

Falls später Probleme auftreten, hilft diese Dokumentation, zu erklären, was bekannt war und wie Entscheidungen getroffen wurden.

Mit der IEC 62304 wird das Risikomanagement Teil des Software-Writing-Prozesses. Es nutzt die Prinzipien der ISO 14971, um Ihnen zu helfen, softwarebedingte Risiken zu erkennen und zu kontrollieren, bevor sie tatsächlichen Patienten zu schaffen bekommen.

Weißt du nicht genau, wie das tatsächlich aussieht? Hier ein Überblick.

Die Erkennung gefährlicher Situationen

Beginnen Sie damit, nach Szenarien zu suchen, in denen die Software außer Kontrolle geraten könnte. Dazu gehören alles von schwerwiegenden Ausfällen bis hin zu subtilen Fehlern, die dennoch zu Schäden führen könnten.

Umsetzung von Risikokontrollmaßnahmen

Wenn die Risiken klar sind, muss man entscheiden, wie man sie im Griff behält. Einige Kontrollen sind in die Software integriert, andere basieren auf Hardware oder den Anweisungen des Benutzers.

Die Wirksamkeit der Risikokontrollen überprüfen

Steuerungssysteme zählen nur dann, wenn sie funktionieren. Sie müssen sicherstellen, dass jede Funktion wie vorgesehen funktioniert. Je nach Risiko kann dies Tests, Simulationen oder formale Überprüfungen beinhalten.

Dokumentation und Rückverfolgbarkeit

Sie müssen den Zusammenhang zwischen den einzelnen Risiken, deren Management und der Überprüfung der Wirksamkeit der Maßnahmen aufzeigen. Diese Rückverfolgbarkeit hilft Ihrem Team, seine Ziele zu verfolgen und Auditarbeiten zu vereinfachen.

Einige Probleme bei der regulatorischen Einhaltung der Software für medizinische Geräte treten häufiger auf als andere. Insbesondere bei IEC 62304. In den meisten Fällen lassen sie sich auf die Art und Weise zurückführen, wie das Risiko gemäß ISO 14971 verwaltet wird – in der Regel dann, wenn die Sicherheitsklasse der Software zu spät oder nur auf Papier festgelegt wird.

1. Eine der häufigsten Fehler ist Verzögerung der Sicherheitsklassifizierung von Software. Teams beginnen oft mit der Entwicklung, ohne die Sicherheitsklasse zu definieren. Das Problem ist, dass man nun alle Daten wieder einholen muss, die mit der ausgewählten Klasse übereinstimmen. Und wenn es sich um Klasse B oder C handelt, fehlen wahrscheinlich wichtige Rückverfolgbarkeitselemente oder die Testtiefe.
2. Ein weiteres häufiges Problem ist die Abkopplung zwischen Architektur und Code. Diagramme mögen sauber aussehen, doch das Repository erzählt oft eine andere Geschichte. Während Module sich verändern und Schnittstellen sich weiterentwickeln, kann sich das Design auf Papier schnell nicht mehr mit der tatsächlichen Implementierung synchronisieren. Wenn diese Kluft wächst, entsteht eine Reibung bei Überprüfungen und es entstehen unnötige Komplikationen bei Audits.
3. Ein weiteres Muster, das wir oft beobachten, ist Dokumentation, die nur für die Prüfung erstellt wird. Auf dem Papier mag alles komplett aussehen. Wenn das Team diese Dokumente aber nicht tatsächlich täglich nutzt, wird der Abstand zwischen Entwicklung und Compliance schnell größer.
4. Es gibt auch das Unvereinbarkeit zwischen Prozess und Praxis. Ihr QMS kann zwar einen sauberen, konformen Workflow beschreiben. Aber Ihre eigentlichen Tools (z. B. Confluence, Jira, Git) erzählen vielleicht eine ganz andere Geschichte. Wenn diese nicht übereinstimmen, ist die Rückverfolgbarkeit beeinträchtigt. Prüfer bemerken das sehr schnell, da es sehr offensichtlich ist, wenn die Dokumente eine andere Geschichte erzählen als die eigentlichen Commit-Dateien von Jira, Git und anderen Tools.

Diese Probleme sind häufig. Sie können jedoch auch vermieden werden, wenn Sie die Einhaltung der IEC 62304 in Ihren tatsächlichen Arbeitsablauf einbauen.

Das Problem ist: Sie brauchen von Anfang an keinen perfekten Prozess. Aber wenn Sie mit Software für medizinische Geräte arbeiten, ist es sinnvoll, frühzeitig einige wichtige Dinge richtig zu machen. Unsere Compliance-Experten haben einige Entscheidungen zusammengestellt, die Ihnen ernsthafte Verzögerungen (sei es während der Audits oder nach der Freigabe) ersparen können.

Integrieren Sie das QMS frühzeitig in Ihre Prozesse

Ihr Software-Team und Ihr Qualitätsmanagement sollten nicht in getrennten Welten existieren. Wenn Ihr QMS in einem Word-Ordner gespeichert ist und Ihr eigentlicher Entwicklungsprozess in Jira oder Confluence abläuft, besteht ein Kommunikationsdefizit.

Im Idealfall soll der Softwarelebenszyklus in Ihrem QMS so definiert sein, dass er der tatsächlichen Arbeit des Teams entspricht. Wenn Sie beispielsweise Sprints, CI/CD oder Testautomatisierung verwenden, sollten diese in Ihrem Qualitätsmanagementsystem berücksichtigt werden. Mit anderen Worten: Ihr IEC 62304-konformes Softwarelebenszyklus sollte in Ihrem QMS vorhanden sein. innerhalb Ihr Qualitätsmanagementsystem nach ISO 13485 (Nicht draußen!). In der Praxis bedeutet das oft, dass Sie den Lebenszyklus nach IEC 62304 direkt in die Tools einpflegen, die Ihr Team bereits verwendet (z. B. Jira, Confluence, Git), und sicherstellen, dass Ihre ISO 13485-Prozesse diese Tools tatsächlich berücksichtigen.

Agile Methoden richtig anwenden

Die IEC 62304 verbietet Agile nicht, erwartet jedoch Struktur.

Das bedeutet, dass Sie zeigen müssen, wie die Arbeit geplant, durchgeführt und verifiziert wurde. Wenn Ihr Backlog keinen Zusammenhang zu Ihrem Risiko- oder Anforderungsmanagementmodell aufweist, ist das ein alarmer Anhaltspunkt. Aber wenn Ihre Benutzerstories oder Aufgaben mit Testfällen oder Risikokontrollen verknüpft sind, sind Sie gut unterwegs.

Halten Sie für alle Phasen des Softwarelebenszyklus ordnungsgemäße Dokumentation bereit

Einige Teams dokumentieren nur für die Prüfung. Das Ergebnis ist, dass Sie Dokumente haben, die niemand liest und die oft nicht mit dem tatsächlichen Code übereinstimmen.

Nützliche Dokumentation funktioniert anders. Sie dokumentiert, was tatsächlich gebaut wird. Das bedeutet, dass Designdokumente das reale System widerspiegeln, Testpläne mit dem Produkt wachsen und Anforderungen bereits vor Beginn der Entwicklung erstellt werden. Wenn das Team auf die Dokumentation vertraut, bleibt sie stets aktuell, einfach weil es sie benötigt.

Machen Sie regelmäßiges Training und Audit-Präparationsmaßnahmen zu einer Gewohnheit.

Audits sollten keine Überraschung sein. Wenn Ihr Team nach IEC 62304 und ISO 13485 arbeitet, sollte der Audit nur bestätigen, was bereits vorhanden ist.

Halten Sie die Dinge einfach, aber konsistent. Interne Kontrollen und gelegentliche Mock-Audits helfen Ihnen, Lücken zu erkennen, bevor sie zu Problemen werden. Ebenso wichtig ist es, sicherzustellen, dass die Schulungsprotokolle vollständig sind. Wenn jemand dem Team beitritt, geben Sie ihm eine 20-minütige Einführung in die Standards.

Ein unserer Kunden, ein europäisches Start-up, das eine integrierte Medizin-Appliance entwickelt, hatte die Priorisierung des Rapid Prototyping gegenüber Compliance und Prozessdisziplin vorgenommen. Ihr tragbares Gerät funktionierte und sammelte Daten und übermittelte diese an eine lokale Benutzeroberfläche. Aber sie erfüllten weder die IEC 62304-Anforderungen für die Einhaltung von Embedded-Software noch die Anforderungen an zertifizierte Software nach ISO 13485.

Sie haben erkannt, dass diese Herangehensweise in der Medizintechnik nicht akzeptabel wäre, nicht mit eingebettetem Software, das reale Patienten beeinträchtigt.

Das Problem:

Das Problem begann mit einem Mangel an Struktur. Es gab keine festgelegte Sicherheitsklasse, die Architektur stimmte nicht mit dem Code überein und niemand konnte mit Sicherheit erklären, wie das Risiko verwaltet wurde. Außerdem schien die Dokumentation auf den ersten Blick in Ordnung zu sein, aber sie spiegelte den tatsächlichen Entwicklungsprozess nicht wider. Das, was das Team tagtäglich tat, ähnelte nichts dem, was das Qualitätsmanagementsystem beanspruchte.

Was wir getan haben:

• Hielp dem Team, die Software-Sicherheitsklasse frühzeitig zu definieren und die Begründung zu dokumentieren.
• Die Systemarchitektur wurde überarbeitet, um sie an die tatsächliche Struktur im Repo anzupassen.
• Erstellen Sie einen leichten Dokumentationsworkflow innerhalb ihrer vorhandenen Tools (Jira + Confluence).
• Ich habe das Entwicklungsteam einbezogen, damit er die Anwendung von ISO 13485 und IEC 62304 auf seine Embedded-Software verstehen konnte.
• Automatischer Nachverfolgbarkeitsumbau zwischen Benutzerstories, Codecommits und Tests hinzugefügt.

Was der Kunde erreicht hat:

• Sie haben ihre erste ISO 13485-Prüfung ohne wesentliche Auffälligkeiten bestanden.
• Reduzieren Sie die Einführungzeit für neue Ingenieure ab 40% Jahren.
• Mit der Software und der Dokumentation wurde der MVP-Start erfolgreich abgeschlossen, die vollständig den Anforderungen der IEC 62304-Klasse B entsprechen.
• Sie haben ihren ersten Piloten bei einer Krankenhausgruppe eingesetzt.

Wir haben uns angesehen, warum IEC 62304 und ISO 13485 bei der Software für eingebettete medizinische Geräte unerlässlich sind. Wie wir gesehen haben, reicht ein sauberer Code allein nicht aus; ohne die richtige Struktur (risikobasierte Entwicklung, Nachverfolgbarkeit, Dokumentation und Ausrichtung des QMS) Sie sind während Audits und im realen Einsatz ausgesetzt.

Wenn Ihnen das bekannt vorkommt oder Sie diese Herausforderungen gänzlich vermeiden möchten, kann Yalantis Ihnen von unseren Top-Experten Unterstützung bieten. Wir helfen Medtech-Unternehmen dabei, ihre Entwicklungsprozesse an die IEC 62304 anzupassen, sie in Qualitätsmanagementsysteme gemäß ISO 13485 zu integrieren und ihre eingebettete Software für den Markt bereit zu stellen.