Viele regulatorische Vorgaben fordern die Hersteller auf, Prozesse und Verfahren festzulegen. Solche Forderungen stellen beispielsweise die EU-Verordnungen (MDR und IVDR), Normen wie die ISO 13485, IEC 62304 und ISO 14971 sowie die FDA.
Inhalt
Sie finden auf dieser Seite Verweise auf Fachartikel zu Prozessen und Verfahren:
Die Beschreibung von Prozessen und Verfahren unterscheidet sich in ihrem Granularitätsgrad. Prozesse beschreiben, WAS gemacht wird. Verfahrensanweisungen beschreiben, WIE etwas gemacht wird.
Aber die regulatorischen Anforderungen unterscheiden beides nicht immer präzise.
Alle Anweisungen müssen letztlich bestimmen,
Die Prozesse und Verfahren sind Teil des Qualitätsmanagements. Diese Übersichtseite verschafft einen guten Einstieg in das Thema Qualitätsmanagement.
Hilfreich ist der Artikel zum Erstellen von Prozess- und Verfahrensanweisungen. Das sollte nur bei ausgewählten Prozessen die Aufgabe des QM-Beauftragten sein.
Sind die Prozesse definiert, müssen sie einer Prozessvalidierung unterworfen werden.
Hersteller sollten den Unterschied von Prozessorientierung und Prozessmanagement beachten.
Alle Hersteller müssen einen Entwicklungsprozess festlegen. Dazu sollten sie die Abgrenzung und das Zusammenspiel von Entwicklungsplan und Entwicklungsprozess verstehen.
Bei der Software-Entwicklung nutzen viele Hersteller agile Entwicklungsmodelle. Die Dokumentation hingegen sollte eher einem Modell folgen, das an das V-Modell erinnert.
Ein Teil der Entwicklung umfasst das Risikomanagement bzw. den Risikomanagementprozess. Dabei müssen die Hersteller auch die Risiken durch unzureichende Prozesse analysieren, etwa mit einer Prozess-FMEA (pFMEA).
Die Prozesse müssen den ganzen Lebenszyklus der Produkte abdecken:
Das Johner Institut hilft Herstellern von Medizinprodukten dabei, schlanke und normenkonforme Prozesse und Verfahren festzulegen.
Damit gelingt es Ihnen, Ihre Produkte in der geplanten Zeit und mit den geplanten Kosten schnell und sicher zu entwickeln und in den Markt zu bringen.
Melden Sie sich, damit wir gemeinsam einen Plan erstellen können, wie Sie in kurzer Zeit und zu minimalen Kosten diese Prozesse und Verfahren bei sich etablieren.
Häufig stellt sich beim Thema „Werkzeug Validierung“ die Frage, ob man auch Testwerkzeuge (z.B. N/JUnit) und ALM-Tools (z.B. MedPack, JIRA, Microsoft TFS) validieren bzw. verifizieren muss. Und falls die Antwort ja wäre, müsste man dann die zu dieser Validierung bzw. Verifizierung eingesetzten Werkzeuge selbst wieder prüfen? Da würde sich ja ein Teufelskreis auftun. Dieser Artikel…
Weiterlesen
Die ISO 9001 und damit die ISO 13485 fordern eine Prozessorientierung. Doch was ist damit gemeint? Dass sich das QM-System an Prozessen orientieren soll? Keineswegs! Lesen Sie hier, was die Normen unter Prozessorientierung und Prozessmanagement verstehen, wie sich beide unterscheiden und wie Sie beide erreichen.
WeiterlesenDie Risikoanalyse bei Software unterscheidet sich: Software selbst kann keine Schäden verursachen. Dies geschieht immer via Hardware oder Menschen. Doch das heißt nicht, dass es keiner Risikoanalyse bei Software bedarf. Im Gegenteil!
IT-Projekte werden nicht nur im Gesundheitswesen mit einem der folgenden Ziele gestartet: Effektivität und Effizienz erhöhen z.B. von Prozessen oder Systemen Gesetzliche Anforderungen erfüllen Bestehende Systeme ablösen Innovation z.B. in neue Produkte oder Märke tätigen Gründe fürs Scheitern von IT-Projekten » Kosten für IT-Projekte richtig berechnen » Projektauftrag korrekt formulieren »
WeiterlesenVon Blackbox-Testing spricht man, wenn man Testfälle alleine aus der Spezifikation des zu testenden Objekt (Produkt, Komponente) ableitet. Beim White-box-Testing leitet man die Testfälle hingegen aus der inneren Struktur des Objekts ab z.B. aus dessen Quellcode oder dessen Software-Architektur. Leider beobachte ich, dass viele Medizinproduktehersteller weder die Testfälle spezifizieren, noch diese systematisch mit einem Blackbox-Testverfahren herleiten. Vielmehr klickt sich ein…
WeiterlesenAuf die Frage, was ein Design Review sei, bekommt man häufig unterschiedliche Antworten — abhängig davon, ob man einen Entwickler oder einen Qualitätsmanager fragt. Genau diese unterschiedlichen Sichten können im Audit zum Problem werden.
