Medizinische Software schnell, preisgünstig und "auditsicher" entwickeln
Sie entwickeln medizinische Software? Sie müssen die Normen IEC 62304, IEC 62366, ISO 14971 und ISO 13485 einhalten? Dann sind Sie hier richtig!
Mein Team und ich lieben es, Sie beim Entwickeln hochwertiger medizinischer Software zu unterstützen. Es ist unsere Mission, Ihre Softwareentwicklung sowohl gesetzeskonform als auch effizient, d.h. ohne QM-Overhead zu gestalten. Dazu
entschlacken wir für Sie Ihr QM-Handbuch und Ihre SOPs.
überarbeiten wir gemeinsam mit Ihnen Ihre Prozesse, damit Sie wieder zu dem kommen, um was es eigentlich geht: hochwertige Medizinprodukte zu entwickeln
optimieren wir das Testing, um die Qualität Ihrer Produkte dauerhaft zu steigern
unterstützen wir Sie beim Erheben von Anforderungen, damit Sie genau das Entwickeln, was Ihre Kunden benötigen, und aufwendige Nacharbeiten vermeiden
erstellen wir Ihre Produktakte z.B. die Risikomanagementakte, weil Sie so schneller bereit für eine Auditierung sind
führen wir ein Architektur-Refactoring durch, um die Wartbarkeit und Testbarkeit Ihrer Software zu verbessern,
bilden wir Ihre Mitarbeiter aus Softwareentwicklung, Qualitätssicherung und Regulatory Affairs weiter, damit Sie unabhängig von unserer Hilfe werden
Übrigens: Wir, unser Team aus Software-Experten und Leadauditoren, schulen auch benannte Stellen, also die Personen, die Sie auditieren.
Auf diesen Seiten haben wir kostenlose Informationen für Sie bereitgestellt. Sehen Sie sich um und melden Sie sich bei uns, wenn Sie Fragen haben. Wir antworten schnell und kostenlos.
Keine Konferenz zur Entwicklung medizinischer Software könnte es mehr wagen, auf Vorträge und Workshops zu agiler Softwareentwicklung zu verzichten. Sind die nun alle Probleme gelöst? Haben die Entwickler und die Verantwortlichen für die Qualitätssicherung endlich einen Modus zur friedlichen Koexistenz gefunden?
Mit etwas Sorge beobachte ich diesen Hype. Im möchte einige Gedanken mit Ihnen teilen, unter welchen Umständen Agilität zu Problemen - nicht nur beim Audit - führen wird. Lesen Sie weiter...
Viele Software Requirement Specifications (SRS) sind unvollständig, fehlerhaft und vermischen Kundenwünsche, Nutzungsanforderungen, Systemanforderungen und Vorgaben für die konkrete Lösung (z.B. die Architektur betreffend).
Das ist gefährlich, denn solche mangelhaften Dokumente widersprechen den Forderungen der IEC 62304 (Kapitel 5.1) und können im ISO 13485 Audit zu Problemen führen.
Dabei ist es gar nicht so schwer, eine gesetzeskonforme und vor allem der Entwicklung nützliche Dokumentation zu erstellen. Lesen Sie weiter...
Die Wertschöpfung bei der Software-Entwicklung findet beim (idealerweise gemeinsamen) Denken und Diskutieren statt und nicht beim Kodieren. Fehler in diesem Plan lassen sich an einem Whiteboard in Minuten korrigieren, was im Code Tage bedeuten würde.
Auch die IEC 62304 verlangt, dass keine ad-hoc Design-Entscheidungen mehr getroffen werden. Dabei sind deren Anforderungen an die Dokumentation der Software-Architektur mehr als bescheiden. Lesen Sie weiter...
Tipp zur IEC 62304 Kapitel 5.5
Reverse Code Reviews
Eins der wichtigsten Mittel, um die Fehlerrate in meinem Team signifikant einbrechen zu lassen, waren Code-Reviews. Und zwar konsequent bei allem Code. Das klappt aber nur, wenn man das richtig macht und ein paar Regeln einhält. Lesen Sie weiter...
Das Missverständnis der IEC 60601-1
Verifizierung und Validierung unterscheiden
Die IEC 60601-1 zeigt ebenso wie die IEC 62304 in ihrem Anhang das V-Modell ohne dieses Entwicklungsprozessmodell zu fordern. Dieses Modell ist aber ideal, um eine Dokumentationslandschaft zu diskutieren. Es reflektiert auch das Verständnis vieler Auditoren.
Leider verwechseln die Autoren (und auch viele Auditoren) die Begrifflichkeiten: Sie sprechen lediglich von Anforderungen und Bedürfnissen und versäumen es daher, Nutzungs- und Systemanforderungen zu unterscheiden. Konsequenterweise misslingt dann auch die Unterscheidung von Verifizierung und Validierung. Lesen Sie weiter...
92/42/EWG und IEC 62366 konform validieren
Validierung von medizinischer Software
Die Richtlinien für Medizinprodukte, speziell die “Medical Device Directive” (93/42/EWG) und die “Active Implantable Device Directive” sind sich einig: Zu den grundlegenden Anforderungen eines Medizinproduktes zählt:
“Bei Geräten, die Software enthalten oder bei denen es sich um medizinische Software an sich handelt, muss die Software entsprechend dem Stand der Technik validiert werden, wobei die Grundsätze des Software-Lebenszyklus, des Risikomanagements, der Validierung und Verifizierung zu berücksichtigen sind.” Ergänzung durch die 2007/47/EC
Und wie lassen Sie nun Ihren Auditor vermuten, dass Sie Ihre Software nach dem Stand der Technik validiert haben? Normalerweise würden Sie eine Norm einhalten. Für die Software-Validierung gibt es aber keine spezifische. Lesen Sie weiter...
Tipp (nicht nur) zur ISO 13485
Welche Software (außer der des Medizinprodukts) Sie validieren müssen
Schnell hat es einem mit einer “Minor Non-Conformity” erwischt: Man hat nicht alle Software validiert, die man hätte validieren müssen. Doch welche Software-Anwendungen betrifft das?
Die Antwort hängt zuerst davon ab, für welchen Markt Sie Ihr Medizinprodukt entwickeln. Ich konzentriere mich in diesem Beitrag auf den europäischen.
