News für Medizinproduktehersteller

Fachartikel des Johner Instituts

Fast arbeitstäglich finden Sie als Medizinproduktehersteller neue Fachartikel zu Themen wie Risi-
komanagement
und ISO 14971, IEC 62304-konformer Software-Entwicklung, Requirements- und
Usability-Engineering
(IEC 62366), Regulatory Affairs s sowie QM-Systeme


Freitag, 10. Oktober 2014 | Prof. Dr. Christian Johner

IEC 62366 Anhang K: Was Sie dazu wissen sollten

Die IEC 62366 wird gerade kräftig überarbeitet. Mittelfristig folgt eine zweite Ausgabe, die IEC 62366-1. Bereits kurzfristig wird Sie um den Anhang K ergänzt. Das Ziel besteht darin, Medizinprodukteherstellern eine Erleichterung bei der Konformitätsbewertung mit Bezug auf die Gebrauchstauglichkeit anzubieten.

An wen sich die Ergänzung der IEC 62366 wendet

Diese Ergänzung der IEC 62366 wendet sich an

  • Hersteller von Legacy Produkten (an denen ggf. auch Änderungen an der Benutzerschnittstelle (UI) vorgenommen werden) und an
  • Hersteller von Medizinprodukten, die UI-Komponenten enthalten, für die es keine IEC 62366-konformen Aufzeichnungen gibt.

Man spricht von UOUP, Usability of Unknown Provenance, analog den SOUPs für die Software.

Die Ergänzung der IEC 62366:2007 durch den Anhang K integriert die IEC 62366-1:2015 iim Anhang C.

Wo Sie mehr (nicht nur) zu diesem Anhang K erfahren

  • Video: Noch mehr zu diesem Anhang verrät Ihnen das Video.
  • Artikel zu UOUP: Ein weiterer Beitrag geht darauf ein, wie der Begriff UOUP definiert ist und von welchen Erleichterungen Hersteller profitieren.
  • Seminar: Wenn Sie lernen möchten, wie man gebrauchstaugliche und damit sichere Medizinprodukte entwickelt und gesetzeskonform (IEC 62366, FDA), schnell und ohne QM-Overhead dokumentiert, dann besuchen Sie das Seminar „Usability, Requirements & IEC 62366“ oder sehen Sie sich die Videos im Auditgarant, die demnächst für kurze Zeit wieder verfügbar sein werden. Unser Newsletter informiert Sie, wenn es wieder soweit ist.

 


Sonntag, 5. Oktober 2014 | Prof. Dr. Christian Johner

MPG Zertifizierung: Weshalb der Begriff schon falsch ist

„Bieten Sie auch MPG-Zertifizierungen an?“ oder „können Sie uns bei der CE-Zertifizierung helfen?“ lauten viele Anfragen, die uns meist kleine und mittlere Firmen stellen, die erstmalig ein Medizinprodukt in Verkehr bringen möchten.

Manchmal sprechen die Firmen auch von „MPG-Prüfungen“ oder „MPG-Zulassungen“. Der Gedanke, der allen diesen (falschen) Formulierungen zugrunde liegt, besteht in der Vorstellung, dass man als Hersteller ein Medizinprodukt entwickelt und es dann von einem TÜV zertifizieren oder zulassen würde. Genauso wie man als Hersteller von Zügen eine Zulassung vom Eisenbahnbundesamt benötigt oder als KFZ-Halter einen TÜV-Stempel.

TÜV-Plakette

Dass es weder eine „MPG Zertifzierung“ noch eine „MPG Zulassung“ noch eine „CE Zertifzierung“ oder ähnliches gibt, sondern die Hersteller selbst die Konformität erklären, können diese Firmen kaum glauben. Schließlich kann man sich ja auch nicht selbst die TÜV-Plakette selbst verleihen. Genau das ist aber das Prinzip der meisten Konformitätsbewertungsverfahren, insbesondere denen nach Anhang II. Beitrag lesen


Freitag, 16. Mai 2014 | Prof. Dr. Christian Johner

Zweikanaligkeit bei Medizinprodukten: Wann welche Maßnahmen greifen [Update]

Die Kamingespräche sind fester Bestandteil unser Masterstudiengänge. Wir nutzen sie, um Themen zu diskutieren und Dinge zu erfahren, die nicht Bestandteil der Curricula sind.

Ein Vortragender bei den Kamingesprächen ist Jochen Metzger, der Leiter der Business Unit Medizintechnik der Firma embeX. Sie ist ein Entwicklungsdienstleister, der sich auf sicherheitskritische Systeme spezialisiert hat.

Ein- und zweikanalige Architekturen

Für viele Hersteller von Medizinprodukten führt der Begriff sicherheitskritisch reflexartig zur Aussage, dass eine zweikanalige Architektur notwendig sei. Zweikanalige Architekturen zeichnen sich durch redundante Komponenten in der Kette Sensor-Logik-Aktor aus. Was vielen aber nicht klar ist, dass zweikanalige Architekturen nicht notwendigerweise besser und sicherer als einkanalige sind. Wie das geschehen kann, erfahren Sie ab Q2 2014 im Auditgarant.

zweikanalige-Architektur-Medizinprodukte
Beitrag lesen


Freitag, 14. März 2014 | Prof. Dr. Christian Johner

Ursachenkette ~ Schadens gemäß ISO 14971

Die ISO 14971 definiert Schäden als

„Physische Verletzung oder Schädigung der menschlichen Gesundheit oder Schädigung von Gütern oder der Umwelt“.

Die Schäden gemäß ISO 14971 sind üblicherweise Beeinträchtigungen der Körperstruktur (z.B. Schnitt) oder Körperfunktion (z.B. Bewegungsfähigkeit, Sehfähigkeit, Fähigkeit, Blut zu reinigen). Wir müssen die Schäden kennen, die durch unsere Medizinprodukte entstehen können, um die Risiken beurteilen zu können. Denn Risiken definiert die ISO 14971 als

„Kombination der Wahrscheinlichkeit des Auftretens eines Schadens und des Schweregrads dieses Schadens“.

Und genau hier stößt man auf eine Schwierigkeit: Es gibt nicht nur einen Schaden, sondern eine ganze Ursachenkette, bei dem jedes einzelne Glied einen Schaden im Sinne der Definition bedeutet. Z.B.:

Ein Schaden gemäß ISO-14971 zergliedert sich meist in eine Ursachenkette

 

Jedes Element dieser Ursachenkette genügt der Definition der ISO 14971, denn jedes stellt eine physische Verletzung oder Schädigung der Gesundheit dar. Aber jedes Element wird mit einer anderen Wahrscheinlichkeit auftreten und damit ein anderes Risiko im Sinn der ISO 14971 darstellen.

Die meisten Hersteller betrachten die Ursachenkette nicht so genau. Entsprechend unvollständig und inkorrekt schätzen sie die Risiken ab. Diese Ursachenketten sind meist auch komplex und nicht linear wie das Bild oben vermuten lässt. Diese macht folgende Abbildung klar:

ISO 14971: Ein "initialer" Schaden kann mehrere finale Schäden verursachen.

[Update: In diesem Bild sollte es statt Herzinfarkt besser „Hypovolämischer Schock“ heißen]

Wenn Sie eine Risikoanalyse durchführen, speziell diesen letzten Teil der Ursachenkette untersuchen wollen, benötigen Sie eine Ärztin oder einen Arzt. Das geht nicht anders. Und Sie benötigen einen Risikomanager, der die Ergebnisse dieser Ärztin oder dieses Arztes in der Risikomanagement-Akte konsistent und konform der Forderungen der ISO 14971 dokumentiert.

Lassen Sie mich wissen, wenn Sie dabei Unterstützung wünschen: Schreiben Sie mir (christian@johner-institut.de) oder nutzen Sie unser Kontaktformular.


Dienstag, 11. März 2014 | Prof. Dr. Christian Johner

Medizintechnik: Was das Projektmanagement können muss

Projektmanager benötigt und hat fast jedes Unternehmen. Auch die Hersteller von Medizinprodukten und klinischen Informationssystemen. Doch was unterscheidet das Projektmanagement in der Medizintechnik von anderen Branchen? Was muss ein Projektmanager in der Medizintechnik  zusätzlich können?

Beitrag lesen


Montag, 29. Juli 2013 | Prof. Dr. Christian Johner

Protokoll und Protocol

Wenn Sie Ihr FDA-Auditor nach einem „Test Protocol“ fragt, sollten Sie ihm nicht die Testprotokolle zeigen. Denn Protocols sind Vorschriften, wie etwas zu machen ist, also eher Testspezifikationen. Das, was Sie unter Testprotokoll verstehen, würde der FDA-Auditor als Test Records oder Test Results bezeichnen.

Dass Sie letztlich – nicht nur bei FDA-Audits – beides vorlegen können sollten, wissen Sie. Dass Sie die Testergebnisse reproduzieren können müssen, sicher auch. Und dafür benötigen Sie die Protokolle und Protocols.

PS: Im Institutsclub finden Sie Tipps zum Schreiben von Testspezifikationen und Finden von Testfällen.

Software Testprotokoll

Montag, 29. Oktober 2012 | Prof. Dr. Christian Johner

ISO 14971:2012 Annex ZA: Die neue Norm zum Risikomanagement

ISO 14971:2012 (Anhang ZA): Die wichtigsten Änderungen der Norm

Quasi über Nacht, nämlich vom 31.08.2012 zum 01.09.2012 wurde die ISO 14971:2012 ohne Übergangsfrist als harmonisierte Norm für das Risikomanagement für Medizinprodukte veröffentlicht. Dieser Artikel stellt Ihnen diese Änderungen vor.

ISO 14971:2012: Mit den Änderungen gibt es keine prinzipiell akzeptablen Risiken mehr.

Mit den Änderungen durch die ISO 14971:2012 gibt es keine prinzipiell akzeptablen Risiken mehr.

Eine der wesentlichen Neuerungen der Norm ISO 14971 im Jahr 2012 (ISO 14971:2012) besteht in der Anforderung, dass generell alle Risiken so weit wie möglich zu minimieren sind, es also keine per se akzeptablen Risiken gibt. Die Klarstellungen und Ergänzungen im informativen(!) Anhang ZA empfinde ich teilweise als Neudeutung des bisher Geschriebenen. Gehen wir die einzelnen Teilkapitel dieses Anhangs durch:

  1. Kapitel: Während es bisher „generell“ vernachlässigbare Risiken gab, sind diese jetzt auf einmal verschwunden. Jedes einzelne(!) Risiko ist zu bewerten. Das bedeutet, dass es keine Risikoakzeptanzmatrix aus akzeptablen, ALARP und nicht akzeptablen Risiken (also „grün, gelb und rot“) mehr geben kann, sondern nur noch gelbe und rote Risiken gibt. Das ist wirklich etwas Neues.
  2. Kapitel: Es existiert insbesondere keine Schwelle mehr, unterhalb derer ein Hersteller nichts tun müsste, um Risiken zu minimieren. Es existiert jetzt nur noch eine Schwelle, unterhalb derer die bereits reduzierten Risiken akzeptiert werden können. Das ist ein Unterschied!
  3. Kapitel: Weiter verlangt die Norm, dass Risiken nicht mehr nur „as low as reasonable practical“ reduziert werden dürfen, sondern „as low as reasonable possible“ reduziert werden müssen. Der Unterschied besteht in ökonomischen Überlegungen, die in der zweiten Version keine Rolle mehr spielen dürfen.
  4. Kapitel: Im alten Verständnis der ISO 14971 war die Gesamt-Risiko-Nutzenbewertung eigentlich nur dann erforderlich, wenn nicht alle Risiken im grünen Bereich lagen. Diese Gesamtbewertung, die alle Risiken umfasst, ist spätestens jetzt mit der ISO 14971:2012 immer Pflicht.
  5. Kapitel: Die „alte 14971“ hatte man so verstehen können, dass man zwischen den Maßnahmen „inhärente Sicherheit“, „Schutzmaßnahme“ und „Information“ wählen könne, so lange man in dieser Reihenfolge versucht, die Maßnahmen umzusetzen. Nun wird klargestellt, dass alle Maßnahmen – so möglich – kumulativ anzuwenden sind.
    Weshalb eine inhärent sichere Maßnahme aber weiterer Maßnahmen bedarf, erschließt sich mir nicht. Darauf zu verzichten, zuerst inhärente Maßnahmen anzustreben, war hingegen schon immer im Widerspruch zur Norm.
  6. Kapitel: Dieses Kapitel schließt direkt an das eben Gesagte an und wiederholt, dass die MDD von „inherently safe design and construction“ spricht. Das eigentliche Problem, nämlich die fehlende Definition der inhärenten Sicherheit, wird aber weiter nicht behoben.
  7. Kapitel: Die Informationen an den Nutzer dürfen nicht länger als risikominimierende Maßnahmen verstanden werden. Das halte ich erneut für missverständlich. Natürlich verschwindet ein Risiko nicht dadurch, dass man einen Nutzer generell über das Risiko informiert. Wenn jedoch, um ein Beispiel zu nennen, ein Medizinprodukt bei der Eingabe eines Medikaments den Benutzer fragt, „Sind Sie sicher, dass Sie Herrn XY ein Penicillin trotz dessen Penicillin-Allergie verschreiben wollen?“, dann ist das durchaus eine Maßnahme, die geeignet ist, das Risiko durch das Produkt zu reduzieren, hier ein falsches Medikament damit zu verschreiben. Die Reduktion des Risikos ergibt sich aus der Reduktion der Wahrscheinlichkeit.

Der Auditgarant zeigt Ihnen über 15 Videotrainings Schritt für Schritt, wie Sie eine schlanke ISO 14971:2012 konforme Risikomanagementakte erstellen.

Videotrainings ansehen

Wie es zur ISO 14971:2012 kam

Forderung der Medizinprodukte-Richtlinie

Harmonisierte Normen dienen dazu, Herstellern konkrete Hinweise zu geben, wie sie Forderungen der Richtlinien einhalten. Erfüllen die Hersteller die Normen, vermutet man, dass sie auch die Forderungen der Richtlinien erfüllen.

Das wichtigste Anliegen – vielleicht sogar das einzig relevante – besteht darin, dass Medizinprodukte über ein akzeptables Risiko-/Nutzenverhältnis verfügen müssen. D.h. dass die Produkte den Patienten wirklich helfen und gleichzeitig die Nebenwirkungen so weit wie möglich reduziert werden müssen.

Die Probleme mit der (alten) ISO 14971

Der ALARP-Bereich im Risikomanagement ist definiert als der Bereich, bei dem Risiken  „as low as reasonable practical“ (ALARP) reduziert werden müssen.Doch dieses „so weit wie möglich“ versteht die ISO 14971 ein wenig anders als die MDD – zumindest formuliert sie nicht ganz klar. Jedes Risiko gilt es „so weit wie möglich“ zu minimieren und nicht einige nur „as low as reasonable practical“. Was heißt schon „practical“? So weit, bis man keine Lust mehr hatte? So weit, bis man das Gerät neu designen müsste? So weit, bis keine Zeit und kein Geld mehr da sind?

Diese Praktikabilität hat in der Praxis viel mit ökonomischen Überlegungen zu tun. Und die haben im Risikomanagement nichts verloren. Eine Konsequenz könnte darin bestehen, diesen ALARP-Bereich einfach abzuschaffen. Eine andere darin, für jedes ALARP-Risiko zu begründen, weshalb eine Reduzierung nicht sinnvoll möglich ist. Also eher ein „as low as reasonable possible„. So handhabe ich das bei meinem Kunden schon die ganze Zeit, für die Klarheit bin ich aber dankbar.

Änderung der ISO 14971:2012 Welche Alternativen zur Verfügung standen

Doch was macht man, wenn sich herausstellt, dass eine Norm nicht mehr geeignet ist, diese Vermutung aufrechtzuerhalten? Beispielsweise, weil sie die Forderungen der Richtlinien unvollständig oder gar falsch adressiert? Man hat mehrere Möglichkeiten:

  1. Man deharmonisiert die Norm.
  2. Man ändert die Norm.
  3. Man interpretiert das bisher Geschriebene neu.

Für kurze Zeit wurde offensichtlich diskutiert, die ISO 14971 zu deharmonisieren(!). Nun hat man sich für die dritte Variante entschieden und einen Anhang zu ergänzen. Den Autoren der ISO 14971 gehen die Buchstaben für die Anhänge aus – wir sind jetzt bei ZA angekommen. An Ideen mangelt es Ihnen jedenfalls nicht. Denn das, was die 2012er Ausgabe von ihren Vorgängern unterscheidet, hat es in sich.

Sollten Sie Fragen zur praktischen Umsetzung der ISO 14971:2012 und den Neuerungen haben, dann nutzen Sie die kostenlose Auditsprechstunde.

Kostenlose Auditsprechstunde nutzen


Mittwoch, 26. September 2012 | Prof. Dr. Christian Johner

Meaningful Use

Dass Barack Obama sich für das Gesundheitswesen, insbesondere einen besseren Versicherungsschutz stark macht, wissen die meisten. Dass er Milliarden investiert hat, um die Healthcare IT zu fördern, hingeben wenige. Sein sogenannter HITECH Act sieht einen mehrstufigen Ansatz vor.

Meaningful UseQuelle

In vielen Bereichen sind uns die USA beim Einsatz von Healthcare IT hinterher. Dieser Plan wirkt entsprechend ambitiös. Vergleichen Sie mal Ihre Systeme:

  • Gibt es in Ihren Systemen Daten, die Ihre Patienten direkt beisteuern oder gar selbst eingeben?
  • Wie vollständig können Sie Daten mit anderen Krankenhäusern austauschen? Ich meine damit nicht den Datenaustausch via PDF oder gar Papier?
  • Bieten Sie Werkzeuge an, die den Patienten helfen, Termine selbst zu buchen, Informationen zu ihrer Krankheit oder Behandlung abzurufen?
  • Basieren die Entscheidungen des Bundesgesundheitsministeriums oder des GBAs auf umfangreichen und standardisierten Versorgungsdaten? Werden überhaupt Entscheidung, die die Patientenversorgung betreffen, auf Basis solchen Daten getroffen?

Ich fürchte, dass Sie einige Male mit „Nein“ antworten mussten. Ja, wir sind leider auch noch ein Healthcare-IT-Entwicklungsland…


Samstag, 27. August 2011 | Prof. Dr. Christian Johner

Ich heiße Christian Johner

Eine kurze Einführung in die Regeln korrekter Anschreiben

Vielleicht bin ich empfindlich. Oder bin ich nur empfindlich geworden, weil es kaum jemanden gibt, der mich korrekt anschreibt?

Es scheint gar nicht so einfach zu sein. Wie schreibt man mich in einer E-Mail oder in einem Brief korrekt an? Welche der folgenden Varianten der Anrede sind korrekt?

  1. Sehr geehrter Herr Prof. Dr. Johner
  2. Sehr geehrter Herr Dr. Johner
  3. Sehr geehrter Herr Professor Johner
  4. Sehr geehrter Herr Professor Dr. Johner
  5. Sehr geehrter Herr Johner
  6. Lieber Herr Johner
  7. Guten Tag Herr Johner
  8. Lieber Christian
  9. Hallo Herr Johner

Meine Frage zielt nicht darauf ab, wie ich angesprochen werden möchte. Ich frage vielmehr, welche Anrede korrekt ist! Beitrag lesen


Donnerstag, 3. März 2011 | Prof. Dr. Christian Johner

Erstfehlersicherheit bei Software

„Wie schreibt man erstfehlersichere Software?“ lautet die Frage, die mir eine Teilnehmerin meines Seminars medizinische Software stellt. Eine exzellente Frage, die ich nicht in einem Satz beantworte möchte: Beitrag lesen