Wie Sie wissen, bereit mir eins Freude: Firmen fit fürs QM-Audit zu machen. Und so begleite ich speziell Hersteller medizinischer Software bei der Vorbereitung und während der Audits. Dass dabei einiges an Unterstützungsbedarf besteht, wurde mir die letzten beiden Wochen wieder klar: Der QM-Wahn lebt, beispielsweise

• formuliert QM Entwicklungsprozesse, die überhaupt nicht umsetzbar sind. Beispielsweise weil die Validierung zu einem Zeitpunkt erfolgen soll, zu der es das Produkt noch gar nicht ganz gibt.
• sehen die Entwickler in einem Audit erstmalig Dokumente, die sie angeblich selbst ausgefüllt haben.
• ist die Produktspezifikation so unpräzise, dass eine Entwicklung danach unmöglich ist. Das Produkt gibt es aber schon.
• besteht die Produktvalidierung laut QM-Handbuch aus einem Dokument, auf dem 18 Personen unterschreiben müssen. Unterschreiben, dass alle Dokumente das sind!?!

So etwas tut mir leid. Denn eines ist offensichtlich: QM und Entwicklung leben in zwei unterschiedlichen Universen. Zum Nachteil beider: Die QM verfasst nutzlose Dokumente, die der Auditor anschließend vernichtend beurteilt. Die Entwickler schreiben genauso nutzlose Dokumente – retrospektiv und damit ohne irgendeinen Nutzen davon zu haben. Im Gegenteil, sie hassen es und verlieren nur Zeit.

Es schmerzt mich regelrecht, diesen Missstand zu beobachten. Aber es bereitet mir Freude, ihn zu beheben. Wenn Sie in einer ähnlichen Situation sind, wie die o.g. Firmen, empfehle ich Ihnen das Folgende:

• Beziehen Sie die Entwickler bei der Erstellung des QM-Handbuchs bzw. des Entwicklungsplans mit ein. Meistens wissen die ziemlich genau, welche Informationen sie brauchen und wie sie Produkte zu testen haben. Der QM-Beauftragte stellt nur sicher, dass diese Pläne ISO 13485 und IEC 62304 konform sind.
• Hören Sie sich meine Praxistipps in den webbased Trainings an. Kostenlos dank vierwöchiger Probemitgliedschaft.
• Konsultieren Sie mein FAQ oder fragen Sie mich. Ebenfalls kostenlos.

Aber leben Sie nicht in Paralleluniversen.

Ihr Christian Johner

Als Physiker und langjähriger Lead-Auditor für die ISO 13485 hilft uns Alexander Thern, für unsere Kunden schlanke QM-Systeme nicht nur für die (Software-) Entwicklung, sondern auch für die Produktion und den Einkauf (um nur einige Aspekte zu nennen) zu erstellen.

Manchmal kommt der Nachwuchs doch genau dann, wenn man ihn sich wünscht und braucht .

PS: Ein Foto gibt’s hier

Ich wünsche Ihnen viel Spaß und viele neue Erkenntnisse,
Christian Johner

PS: Mit diesem webbased Training feiern wir ein Jubiläum: Es ist das 50.! Den Mitgliedern des Institutsclubs stehen alle diese Trainings zur Verfügung. Beantragen Sie doch ganz unkompliziert und unverbindlich eine kostenlose Probemitgliedschaft!

Dieses webbased Training ist meines Erachtens das einzige, erste und kompakteste, das es meines Wissens gibt. Und kostenlos ist es auch! Interessiert, dann schauen Sie am nächsten Montag hier vorbei.

Und wenn Sie noch mehr Tipps haben möchten, wie Sie Ihr Audit sicher bestehen, dann können Sie mich kostenlos fragen oder mich bei meinem Seminar zu Medizinischer Software am 24./25. Juni besuchen. Das ist übrigens die letzte Chance bis zum Frühjahr 2011.

Also bis sehr bald, herzliche Grüße
Ihr Christian Johner

• es Ihnen Spaß bereitet, sich damit zu beschäftigen,
• Sie sie unmittelbar für die eigene  Arbeit nutzbar machen können.

Mein neustes Werk ist online – die zweite Folge zur ISO 13485. Schauen Sie doch einfach mal im Institutsclub vorbei. Und dank der vierwöchigen Probemitgliedschaft sogar unverbindlich und kostenlos. Das ist doch ein Deal, oder?

Viel Spaß beim “Qualitätssichern”, Ihr Christian Johner

Immer wieder stoße ich auf (sogar kleine) Firmen, die am eigenen QM-System zu ersticken drohen. Den Inhalt dieser Dokumente kennt bestenfalls der QM-Beauftragte. Über Jahre haben sich so viele nutzlose Anforderungen und sinnlose Textpassagen angesammelt, dass die Ordner bestenfalls noch dazu taugen, den Auditor zu erschlagen – wenn vielleicht auch nur im wörtlichen Sinn.

Ich hasse nutzlose QM-Systeme. Und ich bedaure Entwickler, die damit gequält werden. Daher möchte ich dazu beitragen, diese QM-Systeme und Handbücher drastisch schrumpfen zu lassen und radikal zu entschlacken. Im Institutsclub habe ich eine Serie zur ISO 13485 begonnen, in der ich nicht nur erkläre, was diese Norm wirklich verlangt, sondern auch, wie man sie elegant und zum wirklichen Nutzen aller, der Entwickler, des QMB und der Patienten, umsetzen kann.

Sind Sie daran interessiert, in einer Serie kurzweiliger und unterhaltsamer webbased Trainings zu lernen, wie das geht? Und das sogar kostenlos? Dann melden Sie sich doch als Probemitglied im Institutsclub an. Das ist kostenlos und völlig unverbindlich. Sie müssen sich nach den vier Probewochen nicht einmal wieder abmelden. Fair oder? Und falls Sie länger dabei bleiben möchten, bietet sich die Vollmitgliedschaft an.

Also, bis bald im Club, Ihr Christian Johner

Wie bereits geschrieben versteht man unter Validierung die „Bewertung, ob ein Produkt den Anforderungen an Zweckbestimmung genügt“ (IEC 60601-1) bzw. die „Bestätigung […], dass die Anforderungen für einen spezifischen beabsichtigten Gebrauch oder eine spezifische beabsichtigte Anwendung erfüllt worden sind“ (ISO 13485/ISO9001). D.h. die Validierung setzt eine klar definierte Zweckbestimmung und valide Nutzungsanforderungen voraus. Daran scheitert es meistens, jedoch nicht bei meinem Kunden.

Sein Gedanke war eigentlich gut, im Feld zu prüfen, ob die Zweckbestimmung und Nutzungsanforderungen erfüllt sind. Schließlich fordert die IEC 62366 sogar, dass man „echte“ Benutzer involviert. Die Anwendung aber unkontrolliert in einem Feldtest zu prüfen, entspricht einer Inverkehrbringung. Das ist strafbar (bis zu 5 Jahre Gefängnis!).

Der richtige Ansatz wäre gewesen, diese Prüfung entweder in einer simulierten Umgebung wie einem Usability Lab oder in einer streng abgegrenzten klinischen Prüfung durchzuführen. An die klinischen Prüfungen sind aber einige Auflagen erfüllt. Gerade für Software bedarf es derer aber häufig nicht. Aus diesem Grund empfehle ich das Usability Lab. Wer einmal Hersteller beobachtet hat, wie sie betroffen, ungläubig und fassungslos die Benutzer mit Ihrer Software arbeiten sehen, wird eines nicht mehr vermuten: Dass ein Usability Lab nicht geeignet sei, Nutzungsprobleme zu identifizieren. Schneller und preisgünstiger erfährt man nicht, was viele bei einer Validierung eigentlich gar nicht wissen wollen: Die nackte und oft brutale Wahrheit über ihr Produkt.

Herzliche Grüße, Christian Johner