Auditgarant: Sicher durchs Audit, sichere Produkte, sicher zum Erfolg

Sie befinden sich hier:
SW-Akte: Einführung
authorsymbol
Prof. Dr. Christian Johner
authorsymbol
Qualitätsmanager, Entwickler, Regulatory Affairs, Projektleiter
Beginner
Nicht verfügbar
authorsymbol
veröffentlicht am 16.07.14
Das erste Videotraining in der Reihe zur Dokumentation der Software-Entwicklung beginnt mit einer Einführung in die regulatorische Landschaft: Es stellt Ihnen die relevanten Gesetze in Europa und den USA und die Normen (natürlich die IEC 62304) mit deren jeweiligen Forderungen im Überblick vor. So verschaffen sie sich einen ersten Überblick über die Dokumente, die Sie für diese Akte erstellen müssen. Das Videotraining geht auch auf die Aspekte der Software-Qualitätssicherung ein, so dass Sie die regulatorischen Forderungen damit in Übereinklang bringen können.
Kapitel
Es sind keine Kapitel verfügbar

Begrüßung

Seien Sie willkommen zu unser Serie an Videotrainings zur normenkonformen Entwicklung und Dokumentation medizinischer Software!

Start

In diesem ersten Teil lernen Sie die regulatorischen Anforderungen im europäischen und US-amerikanischen Rechtsraum kennen. Das verschafft Ihnen bereits einen Überblick über die Dokumente, die Sie bei der Entwicklung medizinischer Software erstellen müssen.

Sie erfahren auch etwas über aktuelle Trends und Probleme, die die Behörden veröffentlichen und über den Fokus vieler Auditoren im Bezug auf die Software.

Dieses und die folgenden Videotrainings werden Ihnen in mehrfacher Hinsicht nützlich sein:

  • zuerst helfen Sie Ihnen, Probleme beim Audit zu vermeiden.
  • zum zweiten bekommen Sie Hilfe, um den QM-Overhead zu reduzieren und Ihre Software-Entwicklung effizienter zu gestalten.
  • Und drittens lernen Sie, wie Sie die Anzahl Ihrer Software bezogenen Fehler reduzieren können.

Anstatt sich durch das ständige Bug-Fixing stressen zu lassen, anstatt mit verzögerten Projekten zu kämpfen, finden Sie wieder die Zeit, um kreativ zu sein, um Software zu entwickeln, die das Prädikat innovativ verdient. Und das in einer planbaren Zeit und in planbarer Qualität.

Regulatorische Landschaft

Sie haben sich wahrscheinlich das Videotraining zum gesetzlichen Rahmen bereits angesehen. Daher wissen Sie, dass in Europa, dem Rechtsbereich, den wir uns zuerst vornehmen, die wichtigsten Regularien die Richtlinien sind, insbesondere die Medizinprodukterichtlinie. Diese Richtlinie legt sogenannte grundlegende Anforderungen fest, die jedes Medizinprodukt erfüllen muss.

Die für Software wichtigsten grundlegenden Anforderungen sind die nach Risikomanagement, Gebrauchstauglichkeit und Software-Lebenszyklus. Ein Qualitätsmanagementsystem zu etablieren, ist keine grundlegende Anforderung.

In dieser Trainingsserie ist natürlich der Software-Lebenszyklus von besonderem Interesse.

MDD

Die Medizinprodukterichtlinie enthält diesbezüglich genau einen Satz, nämlich diesen hier.

Die Forderungen sind klar:

  • Die Hersteller müssen für Software Lebenszyklus-Prozesse wie Entwicklungsprozesse einhalten.
  • Sie müssen Risikomanagement betreiben, 
  • und Sie müssen die Software verifizieren und validieren.

Besonders die Forderung nach Lebenszyklus sei hier betont:

Die Einstellung mancher Firmen, dass die Entwicklung mit der ersten Zeile Code starten und mit der letzten Zeile enden würde, ist ein klares No-Go. Auch Testen, Verifizieren und Validieren – sind alleine nicht ausreichend.

62304

Am besten und einfachsten weist man als Hersteller nach, dass man diese Forderungen erfüllt, in dem man sich an eine harmonisierte Norm hält, konkret an die IEC 62304. Diese Norm verlangt von den Herstellern, dass Sie neben anderen Prozessen einen Entwicklungsprozess definieren.

Jeder Entwicklungsprozess muss laut IEC 62304 folgende Aktivitäten umfassen:

  • einen Entwicklungsplan erstellen,
  • Software-Anforderungen bestimmen.
  • Eine Software-Architektur bzw. ein detailliertes Design zu erstellen,
  • die Softwareeinheiten verifizieren,
  • Integrations- und Systemtests durchführen
  • und die Software freigeben.

In den folgenden Trainings werden wir auf diese Aktivitäten und die diesbezüglichen Vorgaben der Norm näher eingehen. Allerdings wird bereits durch diese Liste klar, was dokumentiert werden muss. Jede dieser Aktivitäten sollte in einem oder ggf. mehreren Dokumenten beschrieben sein. D.h. wir sprechen bereits jetzt von neun oder mehr Dokumenten.

FDA

Das Rechtssystem in den USA besteht ebenfalls aus mehreren Ebenen, hier konkret aus drei.

Zuerst gibt es die nationalen Gesetze, insbesondere den „Food, Drug and Cosmetic Act“ FD&C.

Dann folgt das administrative Recht, das in der Verantwortung der FDA liegt. Dieses ist im 21 CFR beschrieben, einem Kapitel des Code of Federal Regulations.

Zusätzlich veröffentlicht die FDA auf der untersten Ebene Empfehlungen und Richtlinien.

21 CFR

Einer der wichtigsten Teile dieses 21 CFR ist der Teil 820, der die Anforderungen an ein Qualitätsmanagementsystem definiert. Man spricht bei diesem Teil 820 auch von QSR, den Quality System Regulations. Für die Software-Entwicklung sind besonders die Unterkapitel C, „Design Controls“, und M, „Records“, also Aufzeichnungen, relevant.

Subpart C

Dieses Unterkapitel C, im Original als Subpart C bezeichnet, bestimmt die Dokumentation, die Sie im Lauf einer Entwicklung erstellen müssen.

Beispielsweise die Design Inputs und Outputs, das Design Review, die Verifizierung und Validierung.

Diese Vorgaben sind sehr generisch, dennoch gehen wir diese in den folgenden Trainings genau durch.

Guidance

Die Guidance Dokumente wie der „Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices” geben genauere Anleitung welche Dokumente Hersteller schreiben und einreichen müssen.

Vergleichbar den Sicherheitsklassen der IEC 62304 kennt die FDA drei „levels of concern“. Abhängig von diesem Level hängen Anzahl und Umfang der einzureichenden Dokumente ab.

Liste an Dokumenten

Die Forderungen der FDA und der IEC 62304, was die zu erstellenden Dokumente angeht, sind sehr vergleichbar, zumindest was die Dokumentation der Software-Entwicklung betrifft. Es gibt kleine Unterschiede, wie man die Inhalte auf die Dokumente aufteilt, aber sonst sind diese zu 90% deckungsgleich.

Beide Regularien fordern die Planung der Softwareentwicklung, einen Entwicklungsprozess, und die Verifikation der Entwicklungsergebnisse.

NBMED

Dass die Regularien nicht nur die Verifizierung und Validierung fordern, ergibt Sinn:

Bereits 2001 hatten die benannten Stellen zurecht festgestellt, dass Software viel zu komplex ist, als dass Testen alleine ausreichend wäre, um Fehler zu finden bzw. zu vermeiden. Daher müsse ein Qualitätssicherungssystem den gesamten Entwicklungsprozess, auch die konstruktiven Phasen, berücksichtigen. Es geht also darum, Fehler so gut wie möglich zu vermeiden und nicht nur so gut wie möglich zu finden.

Qualitätssicherung

Software-Qualitätssicherung ist nämlich bei vielen Firmen noch zu sehr auf das Testen beschränkt. Dabei ist Testen nur ein Teil der analytischen Qualitätssicherung, die wiederum nur der Teil der gesamten Qualitätssicherung ist, der sich des Findens von Fehlern verschreibt. Der andere Teil, die konstruktive Qualitätssicherung, hat zum Ziel, Fehler von Anfang an zu vermeiden.

Dies hat drei Hauptelemente:

Das erste Element zur Fehlervermeidung sind Lebenszyklusprozesse: Der Entwicklungsprozess oder der Wartungsprozess, um zwei zu nennen.

Das zweite Element sind die Methoden oder Verfahren, die im Lauf dieser Prozesse angewendet werden. Beispielsweise Methoden, um Anforderungen zu erheben, Architekturen zu modellieren oder um systematisch zu testen.

Und das dritte Element sind die Werkzeuge, die die Hersteller nutzen, um die Methoden effektiver und effizienter anwenden zu können.

Auf der Metaebene gibt es dann die Aus- und Weiterbildung und Normen, die genau diese drei Elemente, die Prozesse, Methoden bzw. Verfahren und Werkzeuge adressieren.

Auf der analytischen Seite gibt es mehr als nur das Testen: Während Software-Tests nur bei der lauffähigen z.B. kompilierten Software Anwendung finden, fokussieren Reviews auf Dokumente wie Anforderungsspezifikationen oder Quellcode, was auch ein Dokument ist.

Audits prüfen die Effektivität und die Anwendung von Prozessen, eben die Prozesse, die im Rahmen der konstruktiven Qualitätssicherung festgelegt wurden. Normen und Gesetze wie die IEC 62304 oder die der FDA decken alle Elemente dieser Darstellung ab.

Assessment

In der Tat: Wir beobachten starke Veränderungen. Nicht nur wie Software entwickelt wird, sondern auch wie die Auditoren die Software-entwickelnden Firmen prüfen.

Das überrascht auch wenig: Die Wertschöpfung durch Software wächst kontinuierlich. Mehr und mehr Funktionalitäten implementieren die Hersteller in Software. Damit steigt deren Komplexität. Während in der Vergangenheit Software meist nur Teil eines Medizinprodukts war, haben wir es immer mehr mit verbundenen und interagierenden Systemen zu tun, mit Medizingeräten mit embedded Software, die mit klinischen Informationssystemen, stand-alone Software, zusammenarbeiten sollen.

Diese Netzwerke sind auch nicht mehr auf ein Krankenhaus oder eine Institution beschränkt. Wir reden von Ketten von Krankenhäusern, von Krankenhäusern mit Zweigniederlassungen bis hin zu nationalen Gesundheitssystemen und von anderen verteilten, komplexen und schwer zu überwachenden Systemen.

Da überrascht es kaum, dass die Anzahl der Software-bezogenen Probleme geradezu explodiert. In Deutschland hatten wir im Jahr 2010 im Zeitraum von etwa 15 Monaten eine Zunahme um 300%. In den USA sind Softwareprobleme bereits der zweithäufigste Anlass für FDA Recalls. Wir haben manchmal den Eindruck, dass wir die Kontrolle über die eigene Software verloren haben.

Die Gesetzgeber und Behörden machen was Gesetzgeber oder Behörden tun können, um das Problem anzugehen: Sie schreiben neue Gesetze und intensivieren die Überprüfungen. Die Dauer von Audits hat man um bis zu 30% erhöht. Benannte Stellen investieren in die Weiterbildung ihres Personals und stellen immer mehr Informatiker ein. Auch der Fokus verschiebt sich bei den Audits: Es geht nicht mehr nur um technische Probleme, um Bugs, sondern eher um das Organisationsversagen, das unter die Lupe genommen wird.

Firmen müssen verstehen, dass sie ihre Softwareentwicklung nicht mit der ersten Zeile Code beginnen und mit der letzten beenden können und dürfen. Es reicht auch nicht aus, rückwirkend alles für die Auditoren zu dokumentieren. Firmen müssen Prozesskompetenz aufbauen. Nicht nur, um die gesetzlichen und normativen Anforderungen zu erfüllen und Audits zu bestehen, sondern auch, um in kurzer Zeit mit hochwertigen Produkten im Markt erfolgreich zu sein.

Ausblick

In diesem Videotraining konnten Sie sich einen ersten Überblick über die regulatorischen Anforderungen und die Liste an Dokumenten verschaffen, die Sie als Medizinproduktehersteller zusammenstellen müssen.

Sie haben gelernt, dass Sie sowohl analytische als auch konstruktive Qualitätssicherung betreiben müssen.

Um als Firma erfolgreiche und innovative medizinische Software entwickeln zu können, benötigt Ihr Team nicht nur technische Expertise, sondern auch ein Verständnis der Regularien. Es sollte wissen, wie man diese erfüllt, ohne einen Overhead aufzubauen. Es sollte aber auch wissen, wie man Prozesse definiert und lebt und wie man Verfahren und Werkzeuge anwendet.

Genau darum geht es in dieser Serie an Videotrainings: Sie gibt Ihnen eine Schritt für Schritt Anleitung, wie Sie Dokument für Dokument schreiben und prüfen. Mit diesem Wissen wird es Ihnen besser gelingen, statt nervige Software-Fehler zu beheben und sinnlose Dokumente zu verfassen wieder das zu tun, was Sie am meisten mögen:

Mit Freude hochqualitative Software zu entwickeln – in der geplanten Zeit und mit einer vorhersagbaren Qualität. Dass Sie dabei noch Ihre Audits sicher bestehen werden, ist nur ein weiterer angenehmer Nebeneffekt.

Freuen Sie sich also auf die nächsten Trainingseinheiten!

Link
Datei
  • Template: Dokumentenliste
    Dieses Material steht nur autorisierten Nutzern zur Verfügung
Vorausgesetzte Videos
Weiterführende Videos
Ergänzende Videos

Auditgarant: Mitglied werden

Der Auditgarant: Ihre sichere Bank - nicht nur in Audits

Der Auditgarant hilft Ihnen …

  • peinliche Schwierigkeiten im Audit zu minimieren,
  • kosten- und zeitintensive Nacharbeiten zu vermeiden (ein Re-Audit kostet einige 1000 Euro, zusätzlich die internen Ressourcen).
  • beschleunigen Sie die Time to Market für Ihr Produkt, weil Sie unnötigen Projektverzug vermeiden z.B. aufgrund unnötiger Nachbesserungen, aufgrund aufwendigem (retrospektiven) Erstellen der technischen Dokumentation. Wie viele hunderttausend Euro ein Projektverzug bei Ihnen pro Monat kostet, können Sie selbst abschätzen, wenn Sie die Jahresumsätze mit Ihren Produkten durch 12 teilen.
  • machen Sie teure Berater weitgehend überflüssig und sparen Kosten oft im fünfstelligen Bereich.

Der Preis: Ihre Investition

Im Vergleich zu diesen Kosten ist der Auditgarant ein Schnäppchen: 990,-- Euro pro Jahr. Wir sind davon überzeugt: Es ist fast unmöglich, dass sich diese Investition nicht in kürzester Zeit rechnet. Überzeugen Sie sich selbst und bestellen Sie gleich jetzt.

Zufriedenheitsgarantie

Auditgarant bestellen

Was unsere Kunden sagen

Picclient"Die Angebote sind die umfangreichesten Informationen zu dem Thema an einer Stelle - und sehr gut und nützlich für die tägliche Arbeit aufbereitet."

Klaus Müller, Geschäftsführer xmachina GmbH

Picclient"Ich bin wirklich überrascht, wie gut es Ihnen gelungen ist Ihre Motivation und Freude zum Ausdruck zu bringen und dies bei wirklich nicht einfachen Thematiken. Es hat Spaß gemacht, sich die Webtrainings anzuschauen und die Mindmailer zu beantworten. Ich danke Ihnen sehr dafür, dass Sie so mit dem Herzen bei der Sache sind und dies wunderbar weitergeben können. So wird aus einem komplexen und eigentlich trockenen Thema ein hoch interessantes Thema von dem man nicht genug bekommt. Wirklich super!"

Nicole Haas

Picclient" Sehr geehrter Herr Johner,
ich habe während meines gesamten Berufslebens noch nie etwas mit einer technischen Dokumentation - geschweige denn mit der IEC62304 - zu tun gehabt. Mein Chef hat es mir zugetraut und mir Ihre Videos anvertraut. Und was soll ich sagen? Dank Ihnen habe ich meinen Job behalten, denn ich habe es geschafft und arbeite maßgeblich an der technischen Dokumentation mit!
Vielen Dank![...]"

Nina Schubert

Picclient"Ich bin ich von den Inhalten des Audit-Garanten immer mehr überzeugt und [...] erkenne, dass die Templates aus dem Premium-Auditgaranten sehr viel nutzen."

Jonas Schansker, ARGOS Messtechnik