ISO 13485: Ein QMS für agile Software-Teams

Was ISO 13485 von einem Software-Team verlangt

ISO 13485:2016 ist die Norm für Qualitätsmanagementsysteme von Medizinprodukte-Herstellern. Für ein Software-Team bedeutet sie vor allem eines: Sie müssen zeigen können, dass Ihr Produkt nach festgelegten Prozessen entsteht, dass diese Prozesse wirken und dass Sie aus Fehlern systematisch lernen. Die Norm verlangt kein bestimmtes Vorgehensmodell und keine bestimmten Werkzeuge.

Für Software-Teams sind vor allem diese Kapitel relevant:

• 4.2 Dokumentationsanforderungen: Lenkung von Dokumenten und Aufzeichnungen, Medizinprodukteakte.
• 4.1.6 Validierung von Software im QMS: Werkzeuge, die im Qualitätsmanagement eingesetzt werden, müssen risikobasiert validiert werden.
• 6.2 Personal: Kompetenz, Schulung und deren Nachweis.
• 7.3 Entwicklung: Planung, Eingaben, Ergebnisse, Bewertung, Verifizierung, Validierung, Übertragung, Änderungen und Entwicklungsakte.
• 7.4 Beschaffung: Bewertung und Steuerung von Lieferanten.
• 8.2.4 Internes Audit und 8.5 Verbesserung mit Korrektur- und Vorbeugungsmassnahmen.

Den Software-Lebenszyklus selbst beschreibt die IEC 62304, die ein QMS voraussetzt. Wie die beiden Normen im Entwicklungsalltag zusammenspielen, zeigt der Artikel IEC 62304 in der Praxis. Auch die US-Behörde FDA hat ihre Qualitätsanforderungen mit der QMSR an ISO 13485 angelehnt, was die Norm für international tätige Hersteller noch wichtiger macht.

Ein QMS, das zur Teamgrösse passt

Die Norm gilt für ein Startup mit fünf Personen ebenso wie für einen Konzern. Sie lässt aber Spielraum, wie detailliert Prozesse beschrieben werden. Ein kleines Team kommt oft mit einer überschaubaren Zahl an Verfahrensanweisungen aus, solange alle Anforderungen der Norm abgedeckt sind. Ausschlüsse von Kapiteln, etwa zur Sterilisation, sind möglich, wenn sie begründet werden. Für Software-Hersteller betrifft das typischerweise Themen der physischen Produktion.

Dokumentenlenkung ohne Papierberg

Die Norm verlangt, dass Dokumente vor der Freigabe geprüft, bei Änderungen erneut freigegeben, eindeutig versioniert und am Einsatzort in gültiger Fassung verfügbar sind. Veraltete Versionen dürfen nicht versehentlich verwendet werden.

Für ein Software-Team ist Git dafür oft das bessere Werkzeug als ein Dokumentenordner:

• Versionierung: Jede Änderung ist mit Autor, Zeitpunkt und Inhalt nachvollziehbar.
• Prüfung und Freigabe: Ein Pull Request mit Pflicht-Review durch eine berechtigte Person ist eine dokumentierte Prüfung. Geschützte Branches verhindern Änderungen ohne Freigabe.
• Gültige Fassung: Der Hauptzweig bzw. ein Release-Tag definiert, was gilt.
• Aufzeichnungen: Testergebnisse und Build-Protokolle aus der CI/CD-Pipeline werden archiviert und bleiben unverändert.

Damit das im Audit trägt, muss es beschrieben sein. Eine Verfahrensanweisung legt fest, welche Dokumente im Repository liegen, wer freigeben darf, wie Freigaben erkennbar sind und wie lange Aufzeichnungen aufbewahrt werden. Die eingesetzten Plattformen werden nach Kapitel 4.1.6 validiert, in einem Umfang, der ihrem Risiko entspricht.

Design Controls vs. Sprints

Kapitel 7.3 beschreibt die Entwicklung in Phasen: Planung, Eingaben, Ergebnisse, Bewertung, Verifizierung, Validierung und Übertragung. Das liest sich wie ein Wasserfall, ist aber keiner. Die Norm verlangt, dass diese Aktivitäten stattfinden und dokumentiert sind, nicht dass sie strikt nacheinander ablaufen.

In einem agilen Team lässt sich das so abbilden:

• Entwicklungsplanung: ein Entwicklungsplan, der den iterativen Ablauf beschreibt und regelmässig aktualisiert wird.
• Entwicklungseingaben: Anforderungen im Backlog mit eindeutigen Kennungen, verknüpft mit Risiken und Nutzerbedürfnissen.
• Entwicklungsergebnisse: Code, Architekturdokumente und Spezifikationen im Repository.
• Entwicklungsbewertung (Design Review): geplante Reviews an definierten Meilensteinen, zum Beispiel am Ende eines Release-Zyklus, mit Protokoll und Teilnehmenden, die nicht direkt verantwortlich sind.
• Verifizierung: automatisierte Tests, Code-Reviews und Systemtests gegen die Anforderungen.
• Validierung: Nachweis, dass das Produkt die Nutzerbedürfnisse und die Zweckbestimmung erfüllt, etwa durch Usability-Tests und klinische Bewertung.
• Änderungen: Jede Änderung nach einer Freigabe wird bewertet, auch hinsichtlich Risiko und regulatorischer Wirkung.

Der Schlüssel ist, dass Sprints die Nachweise laufend erzeugen und Design Reviews an sinnvollen Punkten den Stand konsolidieren.

Lieferanten und SOUP

Nach Kapitel 7.4 muss der Hersteller Lieferanten nach Kriterien bewerten und auswählen, deren Leistung überwachen und die Anforderungen an das Beschaffte festlegen. Für Software-Teams betrifft das Cloud-Anbieter, externe Entwicklungspartner, Testdienstleister und Werkzeughersteller.

Für einen externen Entwicklungspartner gehört eine schriftliche Qualitätsvereinbarung dazu. Sie regelt, welche Verfahren des Herstellers gelten, wer welche Dokumente erstellt und freigibt, wie Änderungen gemeldet werden, wie mit Problemen und Sicherheitslücken umgegangen wird und welche Rechte der Hersteller für Audits hat. Je höher das Risiko der gelieferten Leistung, desto enger die Steuerung.

Open-Source-Bibliotheken und andere SOUP werden nicht wie klassische Lieferanten auditiert. Sie werden über die Anforderungen der IEC 62304 gesteuert: Identifikation, Zweck, Anforderungen, bekannte Fehler. Die Verbindung zum QMS ist ein definiertes Verfahren für die Aufnahme neuer Abhängigkeiten und deren Überwachung über die Lebensdauer.

Schulung und Kompetenznachweis

Kapitel 6.2 verlangt, dass Mitarbeitende, deren Arbeit die Produktqualität beeinflusst, kompetent sind, und dass dies nachgewiesen wird. Für ein Software-Team heisst das:

• Rollen und Anforderungen an die Kompetenz sind beschrieben.
• Schulungen zu QMS-Prozessen, IEC 62304 und relevanten Verfahrensanweisungen sind dokumentiert, inklusive Wirksamkeitsprüfung.
• Neue Teammitglieder und externe Entwickler werden vor ihrer ersten Arbeit am Produkt eingewiesen.
• Bei Änderungen an Verfahren werden die Betroffenen nachgeschult.

Ein Schulungsnachweis muss nicht aufwendig sein. Eine Liste mit Person, Inhalt, Datum und Bestätigung genügt, wenn sie gepflegt wird.

Interne Audits und CAPA

Interne Audits prüfen in geplanten Abständen, ob das QMS eingehalten wird und wirksam ist. Für Software-Teams lohnt es sich, gezielt die Stellen zu auditieren, an denen Theorie und Praxis auseinanderlaufen: Traceability, SOUP-Liste, Freigaben, Änderungen nach dem Release.

CAPA steht für Corrective and Preventive Action. Werden Abweichungen festgestellt, etwa aus Audits, Kundenrückmeldungen oder Fehleranalysen, wird die Ursache untersucht, eine Massnahme festgelegt und deren Wirksamkeit geprüft. Ein wiederkehrender Fehlertyp in der Software, zum Beispiel falsche Zeitzonen-Behandlung, ist ein typischer Anlass: Die Ursache wird behoben, und ein Test oder eine Review-Regel verhindert die Wiederholung.

Managementbewertung

Die oberste Leitung bewertet das QMS in geplanten Abständen. Eingaben sind unter anderem Audit-Ergebnisse, Rückmeldungen aus dem Markt, Reklamationen, CAPA-Status und Änderungen der regulatorischen Anforderungen. Für ein Software-Unternehmen gehören auch Kennzahlen aus dem Entwicklungsprozess dazu, etwa offene sicherheitsrelevante Fehler oder der Stand der SOUP-Überwachung. Das Ergebnis sind dokumentierte Entscheidungen, nicht nur eine Präsentation.

Wie wir als externer Entwickler in ein Kunden-QMS integriert arbeiten

Softverse hat eine MDR-zertifizierte Medizinprodukte-Plattform mit Backend, Web-App und Mobile App entwickelt und dabei im QMS des Herstellers nach ISO 13485 und IEC 62304 gearbeitet. Aus dieser Erfahrung arbeiten wir in solchen Projekten allgemein so:

• Das QMS des Herstellers gilt. Wir befolgen dessen Verfahrensanweisungen, statt parallele Prozesse aufzubauen.
• Klare Rollen. Wer Anforderungen freigibt, wer Code reviewt, wer Releases freigibt, ist vor Projektstart festgelegt.
• Schulung vorab. Unsere Entwickler werden in die relevanten Verfahren eingewiesen, und das wird dokumentiert.
• Nachweise aus der Arbeit. Pull Requests, Reviews, Testergebnisse und SOUP-Liste entstehen im Entwicklungsalltag und werden so abgelegt, wie das QMS es verlangt.
• Transparenz bei Abweichungen. Probleme melden wir über den definierten Prozess, damit der Hersteller sie bewerten kann.

Die Verantwortung für das QMS und die Konformität bleibt beim Hersteller. Wie ein Projekt bei uns grundsätzlich abläuft, beschreibt die Seite zu unserem Prozess. Mehr zur Arbeit im regulierten Umfeld finden Sie unter MedTech.

Häufige Fehler

• Ein QMS aus der Schublade, das niemand lebt. Auditoren merken schnell, wenn Verfahren und Praxis nicht übereinstimmen.
• Zu viel Papier. Übergrosse Handbücher erhöhen das Risiko von Abweichungen. Weniger, aber gelebte Verfahren sind besser.
• Werkzeuge nicht validiert, obwohl sie Qualitätsnachweise erzeugen.
• Design Reviews als Formalität ohne unabhängige Teilnehmende und ohne Protokoll.
• Externe Entwickler ohne Qualitätsvereinbarung und ohne dokumentierte Schulung.
• CAPA ohne Wirksamkeitsprüfung: Die Massnahme wird umgesetzt, aber nie überprüft.
• Das QMS zu spät aufbauen. Wer zuerst entwickelt und dann dokumentiert, muss Nachweise rekonstruieren, die im Alltag nebenbei entstanden wären.
• Regulatorische Änderungen nicht verfolgen. Neue Leitfäden, Normfassungen oder Anforderungen der benannten Stelle müssen bewertet und in die Verfahren übernommen werden.

Wenn Sie wissen möchten, welche regulatorischen Schritte für Ihr Produkt insgesamt anstehen, hilft die Checkliste Software als Medizinprodukt. Für ein konkretes Vorhaben sprechen Sie mit uns im kostenlosen Erstgespräch.

Dieser Artikel ist eine allgemeine Einführung und ersetzt keine Rechts- oder Regulierungsberatung.