Foto: Google Gemini · AI-generated
Die IEC 62304 regelt seit 2006 den Lebenszyklus von Medizingerätesoftware. Ihre zweite Ausgabe ist die größte Überarbeitung seitdem — und sie ist derzeit ein Komiteeentwurf, keine veröffentlichte Norm.
Diese Unterscheidung ist wichtig. Beginnen wir deshalb dort und nicht am Ende.
Was feststeht — und was nicht
Nicht fest: das Datum. Die veröffentlichten Prognosen widersprechen sich. Manche nennen eine Veröffentlichung Mitte bis Ende 2026, andere Anfang bis Mitte 2027. Wer Ihnen ein festes Datum nennt, rät.
Nicht fest: ab wann sie Sie bindet. Veröffentlichung ist nicht Übernahme. Die formale regulatorische Anerkennung — FDA-Anerkennung, EU-Harmonisierung — folgt typischerweise zwei bis drei Jahre später. An Ihren heutigen Pflichten ändert sich dadurch nichts.
Weitgehend fest: der Inhalt. Der Entwurfstext ist stabil, und die Richtung ist klar genug, um damit zu planen. Genau das ist die sinnvolle Haltung: planen, nicht hektisch werden.
Die vier Änderungen, auf die es ankommt
1. Aus drei Sicherheitsklassen werden zwei Prozessstufen. Die Klassen A, B und C werden durch zwei Stufen ersetzt. Stufe I entspricht im Wesentlichen der bisherigen Klasse A; Stufe II fasst B und C zusammen.
Das ist die Änderung mit der größten praktischen Wirkung — und sie lässt sich leicht falsch lesen. Weniger Kategorien klingt nach Vereinfachung. Für Software, die heute als Klasse B eingestuft ist, verschwindet damit aber die leichtere Mittelstufe. Arbeit, die bisher unterhalb der Strenge von Klasse C lag, rückt auf dieselbe Prozessstufe. Wenn Ihr Produkt heute Klasse B ist, lesen Sie diesen Absatz zweimal.
2. Der Anwendungsbereich weitet sich von Gerätesoftware auf Gesundheitssoftware. Ausgabe 2 geht über streng regulierte Medizingerätesoftware hinaus in Richtung der breiteren Kategorie Gesundheitssoftware und richtet sich an der IEC 82304-1 aus. Klinische und Gesundheitsanwendungen, die heute keine Gerätedefinition erfüllen, können in den Geltungsbereich fallen.
3. KI und maschinelles Lernen bekommen einen eigenen Lebenszyklus. Der Entwurf führt Regelungen für die KI-/ML-Entwicklung ein, einschließlich eines definierten Entwicklungslebenszyklus dafür. Wer klinische Software um KI-Funktionen erweitert, findet damit erstmals eine direkte Aussage der Norm statt einer Analogie.
4. “Schaden” wird im Sinne der ISO 14971 erweitert. Der Begriff umfasst nun auch Sach- und Umweltschäden, nicht nur Schaden an Patienten und Anwendern. Eine kleine Formulierungsänderung, die still erweitert, was Ihre Risikoanalyse berücksichtigen muss.
Was sich schon vor der Veröffentlichung lohnt
Die ehrliche Antwort ist größtenteils unspektakulär — und größtenteils etwas, das Sie ohnehin wollen würden.
- Klassifizierung erneut prüfen. Wenn etwas in Ihrem Bestand Klasse B ist, spielen Sie durch, was die Strenge von Stufe II dafür bedeuten würde. Das ist der größte mögliche Kostenblock, und er ist heute schon erkennbar.
- Prüfen, was in den Geltungsbereich rutscht. Begleit-Apps, Portale und klinische Werkzeuge, die heute außerhalb der Gerätegrenze liegen, bleiben es womöglich nicht. Erfassen Sie sie.
- Den KI-Lebenszyklus aufschreiben. Wenn klinische Software KI nutzt: dokumentieren Sie, wie Modelle trainiert, validiert, versioniert und überwacht werden. Das brauchen Sie unabhängig davon, welche Norm es verlangt.
- Das QM-System noch nicht umbauen. Der Text ist stabil, aber nicht final. Dokumentation gegen einen Entwurf umzustrukturieren, ist Arbeit, die Sie womöglich zweimal machen.
Der unbequeme, nützliche Teil
Lesen Sie die vier Änderungen noch einmal und achten Sie auf eines: Keine davon verlangt etwas, das ein sorgfältiges Team nicht ohnehin wollen würde. Nachvollziehbare Klassifizierung. Wissen, welche Software im Geltungsbereich liegt. Dokumentierte KI-Validierung. Eine Risikoanalyse, die reale Folgen berücksichtigt.
Das deckt sich mit unserer Erfahrung aus regulierten Projekten. MedLabel erzwingt die Pflichtfelder je Etikettentyp, sodass ein nicht konformes UDI-Etikett gar nicht erst entstehen kann. MedERP führt Charge, Los und Seriennummer in jeder Transaktion statt in einem nachgelagerten Bericht. MedCatalog läuft seit fast einem Jahrzehnt in Produktion — lang genug, dass mehrere regulatorische Verschiebungen hindurchgegangen sind. In allen drei Fällen waren die Praktiken, die das regulatorische Leben erleichtert haben, zuerst Praktiken, die die Software besser gemacht haben.
Die praktische Lesart von Ausgabe 2 lautet deshalb nicht “2027 kommt eine neue Last”. Sie lautet: Der Abstand zwischen guter und konformer Entwicklung wird kleiner, und die Mittelstufe, in der man weniger tun konnte, fällt weg. Teams, die ohnehin sorgfältig bauen, werden den Übergang klein finden. Teams, die Klasse B genutzt haben, um Strenge zu vermeiden, nicht.
Wir sind ein Softwarepartner, keine Regulatory-Beratung — die Compliance-Entscheidung liegt bei Ihrer Benannten Stelle und Ihrem Qualitätsmanagement. Was wir tun können: Medizintechnik-Software so bauen, dass sie diesen Übergang übersteht, mit QA und Testing als Teil der Lieferung statt als Anhang am Ende.
Wenn Sie gerade durchspielen, was Ausgabe 2 für ein Produkt in Ihrem Bestand bedeutet: Wir denken das gern mit Ihnen durch.