Startseite » Allgemeine Themen für Medizinprodukte » Softwarevalidierung in der Medizintechnik
Die Softwarevalidierung wurde früher in der Medizintechnik stiefmütterlich behandelt. Obwohl die Softwarevalidierung von der FDA in 21CFR820.70(i) immer gefordert war. Mit der Revision der EN ISO 13485 und dem MDSAP Auditprogramm ist die praktische Bedeutung der Softwarevalidierung gestiegen und sie erlangt in Audits zunehmende Aufmerksamkeit.
die
Bei der Softwarevalidierung muss zwischen Software, die Teil des Medizinproduktes ist und sonstiger zu validierender Software unterschieden werden. Software, die Teil eines Medizinproduktes ist, lässt sich unter strikter Anwendung der harmonisierten und von der FDA anerkannten IEC/EN 62304 recht leicht validieren. Auf diese Art Software werde ich daher im Weiteren nicht eingehen.
Die Softwarevalidierung ist auch bekannt als:
Bei Software, die für die Produktion (inkl. Prüfung) von Medizinprodukten verwendet wird oder, die im Qualitätsmanagementsystem selber verwendet wird (z.B. Dokumentenmanagementsystem, Messwertdatenbank, etc.) verhält es sich wesentlich komplizierter. Für diese Art Software existiert keine anerkannte Norm, nach der man bei der Softwarevalidierung vorgehen kann. Häufig fällt im Kontext der Softwarevalidierung für das QM-System oder die Produktion der Begriff GAMP 5. Hierbei handelt es sich um einen Leitfaden aus der pharmazeutischen Industrie zur Validierung dieser Art Software. GAMP 5 ist allerdings sehr mächtig und seine vollständige Umsetzung dementsprechend aufwendig und teuer. Ich selber habe noch nicht ein Unternehmen der Medizintechnik gesehen, dass streng nach GAMP 5 vorgeht. Wo liegt also die Mindestanforderung für die Softwarevalidierung? Sofern Sie in die USA liefern, definiert die Guidance General Principles of Software Validation der FDA das erwartete Vorgehen. Richtig selbsterklärend ist diese Guidance allerdings auch nicht. Daneben existiert noch AAMI TIR36. Bei diesem Dokument handelt es sich um eine recht pragmatische Anleitung, die jedoch am Ende weiterhin viele Fragen offen lässt.
Für den Ansatz der Softwarevalidierung hat es sich in der Praxis bewährt, das Brauchbarste aus den verschiedenen bereits genannten Quellen zusammen zu mischen und darauf zu achten, dass die typischen Elemente wie User Requirements, Risikoanalyse, Testplan, Testreport etc. vorhanden sind. Es lohnt sich beispielsweise die Kategorisierung der zu validierenden Software von GAMP 5 zu übernehmen. Hier geht es im Wesentlichen darum, dass eine Software um so fehleranfälliger sein wird, je kundenspezifischer diese ist. Auf dieser Philosophie basierend, können die Aufwände bei sogenannter Off-The-Shelf-Software, also gängiger Software, wesentlich reduziert werden. Viel mehr sollte man aus Gründen der Praktikabilität allerdings nicht aus GAMP 5 für die Softwarevalidierung übernehmen.
Die nächste Herausforderung bei der Softwarevalidierung für Medizinproduktehersteller ist, dass er als erstes genau aufschreiben muss, was die Software für ihn machen soll. Meist wird nur ein geringer Funktionsumfang der Software tatsächlich benötigt. Die Softwarevalidierung muss nur den tatsächlich genutzten Teil der Software umfassen. Darauf folgt die Risikoanalyse. Für jede genutzte Softwarefunktion gilt es zu analysieren, ob sich die Funktion im Fehlerfall negativ auf das Produkt auswirken könnte oder eine Fehlfunktion zu einer Nicht-Erfüllung von gesetzlichen Vorgaben, wie der Einhaltung des QM-Systems führen kann. Diese Risikoanalyse dient der Steuerung der Testumfänge im Rahmen der Softwarevaliderung. Damit die Risikoanalyse und die daraus abgeleiteten Tests jedoch einen Wert haben, müssen die an der Risikoanalyse beteiligten Personen ein Grundverständnis für Softwarearchitektur und -programmierung haben. Typischerweise wird eingekaufte Software validiert, über die keine Informationen zur genauen Funktionsweise verfügbar ist. Daher müssen die an der Softwarevalidierung beteiligten Personen wissen, wie die von Ihnen untersuchten Softwarefunktionen mit hoher Wahrscheinlichkeit aufgebaut sind. Anderenfalls lassen sich mögliche Fehlerquellen nicht identifizieren und die Risikoanalyse läuft ins Leere. Dasselbe Verständnis von Software ist für die Planung der tatsächlichen Tests der Softwarevalidierung erforderlich.
Die Komplexität einer Softwarevalidierung kann noch gesteigert werden, wenn die zu validierende Software Teil einer Produktions- oder Prüfanlage ist. In diesem Fall werden einige, jedoch nicht alle Softwarefunktionen die Anlage steuern oder deren Daten verarbeiten. Gemäß 21CFR820.70(g) ist für alles Produktionsequipment (inkl. Prüfequipment) eine Abnahme durchzuführen ist. Diese Abnahme wird meist als Installation Qualification (IQ) bezeichnet. Eine der wesentlichen Punkte der Installation Qualification ist die Abnahme der tatsächlichen Funktionen der Anlage. Jetzt treffen zwei Abnahmeinstrumente – die Softwarevalidierung und die Installation Qualification – auf dieselbe Anlage. Nun gilt es zu ermitteln, welche Teile der Softwarefunktionen bereits über die Installation Qualification zufriedenstellend geprüft werden können, und welche eine weitergehende Softwarevalidierung erfordern. Die Abgrenzung, welche Funktionen in der IQ und welche in der Softwarevalidierung abgeprüft werden, gilt es natürlich zu dokumentieren, sodass am Ende sichergestellt ist, dass wirklich alle Software- und Anlagenfunktionen getestet wurden. Eine weitere Steigerung der Komplexität der Softwarevalidierung ist möglich, wenn die Software z.B. an ihr ERP-System angeschlossen wird oder Teile der Softwarefunktion in noch weiteren Teilaspekten Ihres QM-Systems wie beispielsweise einer Kalibrierung abgedeckt we
Eine effiziente Softwarevalidierung lebt von der gründlichen Analyse der Software im Kontext ihres Anwendungsumfeldes. Für die Vermeidung von mehrfachen Testungen derselben Softwarefunktion ist eine enge Abstimmung des Risikomanagements, der Equipmentqualifizierung (IQ), der Softwarevalidierung und ggf. der Softwarevalidierungen weiterer angebundener Software notwendig. Hierfür ist interdisziplinäres Wissen und Erfahrung sowie ein Blick für das Big-Picture erforderlich.
Wie hilfreich war dieser Beitrag?
Klicken Sie auf die Sterne, um zu bewerten!
Durchschnittliche Bewertung 5 / 5. Anzahl Bewertungen: 3
Bisher keine Bewertungen! Seien Sie der Erste, der diesen Beitrag bewertet.
blaurock & philippeit
info@blaurockphilippeit.com
✆ +49-156-78474666 (Hamburg)
✆ +49-721-98614111 (Karlsruhe)
Cookie | Dauer | Beschreibung |
---|---|---|
cookielawinfo-checkbox-advertisement | 1 year | Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Advertisement" category . |
cookielawinfo-checkbox-analytics | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics". |
cookielawinfo-checkbox-functional | 11 months | The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional". |
cookielawinfo-checkbox-necessary | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary". |
cookielawinfo-checkbox-others | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other. |
cookielawinfo-checkbox-performance | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance". |
CookieLawInfoConsent | 1 year | Records the default button state of the corresponding category & the status of CCPA. It works only in coordination with the primary cookie. |
elementor | never | This cookie is used by the website's WordPress theme. It allows the website owner to implement or change the website's content in real-time. |
viewed_cookie_policy | 11 months | The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data. |
Cookie | Dauer | Beschreibung |
---|---|---|
_gat | 1 minute | This cookie is installed by Google Universal Analytics to restrain request rate and thus limit the collection of data on high traffic sites. |
Cookie | Dauer | Beschreibung |
---|---|---|
_ga | 2 years | The _ga cookie, installed by Google Analytics, calculates visitor, session and campaign data and also keeps track of site usage for the site's analytics report. The cookie stores information anonymously and assigns a randomly generated number to recognize unique visitors. |
_gid | 1 day | Installed by Google Analytics, _gid cookie stores information on how visitors use a website, while also creating an analytics report of the website's performance. Some of the data that are collected include the number of visitors, their source, and the pages they visit anonymously. |
CONSENT | 2 years | YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data. |
Cookie | Dauer | Beschreibung |
---|---|---|
VISITOR_INFO1_LIVE | 5 months 27 days | A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface. |
YSC | session | YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages. |
Wir freuen uns von Ihnen zu hören!
Leonhard Blaurock
Sie interessieren Sich für Prozessvalidierung?
Meistern Sie Ihre Prozessvalidierung viel leichter mit der
Pragmatisch, praktisch & compliant
Diese Webseite verwendet Cookies, um Besucherstatistiken anzufertigen. Mit der Verwendung dieser Webseite erklären Sie Ihr Einverständnis zur Erhebung anonymer Besucherstatistiken. Details finden Sie im Impressum.