Medizintechnik - im Dickicht der Normen

Keine Frage: Die Medizintechnik ist ein stark regulierter Bereich. In forschenden und entwickelnden Unternehmen kann das Dickicht an Richtlinien, Normen und Verordnungen zu einem permanenten schlechten Gewissen führen. Gerade in Entwicklungsteams hängt das Thema Dokumentation dann wie eine schwarze Wolke über dem Projekt - nicht selten wird die Umsetzung der regulatorischen Anforderungen so lange wie möglich hinaus gezögert, um sie dann ganz zum Schluss mehr schlecht als recht auf Papier zu bringen.Dabei geht es auch ganz anders. Regulatorische Anforderungen sind weder Metaphysik noch Mystik. Wer sie kennt und beherrscht, der wird sie bald so normal und banal finden wie Zähne putzen oder Hände waschen. Es geht am Ende darum, sie in den Entwicklungsprozess so einzuflechten, dass sie permanent eingeübt werden. Dazu muss man sie jedoch erst einmal kennen.Ein guter Überblick über die gängigen Anforderungen ist recht schnell hergestellt. Denn die regulatorischen Anforderungen in der Medizintechnik beziehen sich im Wesentlichen auf vier Bereiche, für die es in Europa jeweils eine maßgebende Norm gibt:

  • Qualitätsmanagement mit der Norm EN ISO 13485.
  • Risikomanagement mit der Norm EN ISO 14971.
  • Lebenszyklus-Prozesse mit der Norm EN 62304.
  • Gebrauchstauglichkeit mit den Normen EN 62366 und EN 60601-1-6.

Jedem dieser Bereiche wird in den kommenden Wochen ein einzelner Beitrag gewidmet sein. Heute geht es um die Entkräftung einiger Vorurteile, die einen normalen Umgang erschweren.

Vorurteil eins: Die Anwendung der oben genannten Normen ist verpflichtend.

Falsch. Hersteller von Medizinprodukten sind allein dazu verpflichtet, die Anforderungen bestimmter Richtlinien zu erfüllen (v.a. die Medizinprodukt-Richtlinie 93/42/EWG). Die dort formulierten Vorgaben sind jedoch so allgemein gehalten, dass sie nicht unmittelbar handlungsweisend sind. Beispielsweise findet sich dort die Forderung, dass "durch Anwendungsfehler bedingte Risiken aufgrund der ergonomischen Merkmale eines Produktes" so weit wie möglich reduziert werden sollen. Wie die Umsetzung geschehen soll und welcher Prozess dafür anzuwenden ist - darüber sagt die Richtlinie nichts. Die europäischen Normen füllen dieses Vakuum und treten als Umsetzungshilfen der Richtlinie an. Mehr noch: Wer die europäischen Normen einhält, der kann davon ausgehen, dass die entsprechenden Anforderungen in der Richtlinie ebenfalls erfüllt sind (im Fachjargon sagt man, die Norm sei mit der Richtlinie "harmonisiert").

Vorurteil zwei: Die Normen für die Medizintechnik sind ganz spezieller Natur.

Nicht überall. Die Norm zum Qualitätsmanagement (EN ISO 13485) ist beispielweise in großen Teilen deckungsleich mit der weit verbreiteten ISO 9001.

Vorurteil drei: Software-Entwicklung ist den gleichen Richtlinien unterworfen wie die Hardware-Entwicklung.

Seit ihrer Überarbeitung im Jahr 2007 findet sich in der Medizinprodukt-Richtlinie die Forderung, dass der Software-Lebenszyklus nach dem Stand der Technik entwickelt werden soll. Die dazu korrespondierende Norm EN 62304 beschäftigt sich nur mit der Software-Entwicklung und beschreibt die einzelnen Phasen von der initialen Produktplanung bis zur Wartung. Spannenderweise legt sie sich nicht auf einen Entwicklungsframework fest, sondern bleibt hier offen. Inkrementelle und evolutionäre Ansätze werden als mögliche Herangehensweisen explizit erwähnt.Literatur:Christian Johner u.a. (2011): Basiswissen Medizinische Software. dpunkt.verlag

bgloger-redakteur
March 31, 2014

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Leadership in the AI Era: Reinventing Human-Centered Leadership
BG

Leadership in the AI Era: Reinventing Human-Centered Leadership

KI hier, KI da – was bedeutet das für mich als Führungskraft?
BG

KI hier, KI da – was bedeutet das für mich als Führungskraft?

Der kybernetische Teamkollege
BG

Der kybernetische Teamkollege

Agile Strategie mit OKRs: Vom Denken ins Tun kommen
BG

Agile Strategie mit OKRs: Vom Denken ins Tun kommen

KI als Teammitglied - Wie Scrum Master von generativer KI profitieren können
BG

KI als Teammitglied - Wie Scrum Master von generativer KI profitieren können

Die Bildungskrise und warum einfache Antworten nicht reichen – auch Scrum4Schools ist da nur ein Tropfen auf den heißen Stein
BG

Die Bildungskrise und warum einfache Antworten nicht reichen – auch Scrum4Schools ist da nur ein Tropfen auf den heißen Stein

Ist KI der neue Kollege von Scrum Master, Agile Coach und Co?
BG

Ist KI der neue Kollege von Scrum Master, Agile Coach und Co?

Scrum Beyond IT: Agile Methoden in HR, Marketing und Produktion
BG

Scrum Beyond IT: Agile Methoden in HR, Marketing und Produktion

Design Thinking - Wirkung auf Organisationen und Menschen neu gedacht
BG

Design Thinking - Wirkung auf Organisationen und Menschen neu gedacht

DeepWork für Autoren – Wie du dein Buch effizient schreibst
BG

DeepWork für Autoren – Wie du dein Buch effizient schreibst

Scrum ist tot, es lebe Scrum!
BG

Scrum ist tot, es lebe Scrum!

Agile Leadership ist nicht gleich agile Leadership
BG

Agile Leadership ist nicht gleich agile Leadership