Ein integriertes QMS ISMS verbindet Qualitätsmanagement und Informationssicherheit dort, wo sie für Medizinprodukte tatsächlich wirksam werden: in Entwicklungs-, Risiko-, Nachweis- und Freigabeprozessen. Zwei getrennte Managementsysteme mit jeweils eigenen Dokumenten reichen dafür nicht aus.
Das strukturelle Problem
Getrennte Systeme
Warum kommen getrennte QMS- und ISMS-Strukturen im Audit an Grenzen? Die Dokumente können vollständig aussehen. Trotzdem bleibt im entscheidenden Moment offen, wie Anforderungen, Entscheidungen und Nachweise zusammengehören.
In vielen Unternehmen sind QMS und ISMS organisatorisch getrennt aufgebaut. Das Qualitätsmanagement beschreibt Entwicklung, Lieferantensteuerung, CAPA und Managementbewertung. Das Informationssicherheitsmanagement führt parallel dazu Risiken, Controls, Sicherheitsmaßnahmen und Auditnachweise.
Diese Trennung kann formal funktionieren. Operativ erzeugt sie jedoch häufig Doppelarbeit, widersprüchliche Zuständigkeiten und Lücken an den Schnittstellen. Besonders kritisch wird das bei Software als Medizinprodukt: Produktsicherheit und Informationssicherheit lassen sich dort nicht sauber voneinander trennen.
Ein Cybersecurity-Risiko kann Einfluss auf die Sicherheit und Leistung des Medizinprodukts haben. Eine Softwareänderung kann neue Gefährdungen auslösen. Erkenntnisse aus Schwachstellentests können Anpassungen am Risikomanagement, an den Produktanforderungen oder an der technischen Dokumentation erforderlich machen.
Normen operativ zuordnen
Es ist erkennbar, welche regulatorische Anforderung in welchem Prozess umgesetzt wird.
Rollen eindeutig halten
Prozessverantwortung, fachliche Entscheidung und Freigabe sind nachvollziehbar geregelt.
Nachweise auffindbar machen
Vom Normkapitel führt ein nachvollziehbarer Weg zum Prozess, zur Entscheidung und zum Ergebnis.
Ein integriertes QMS ISMS sorgt dafür, dass dein Team Anforderungen und Nachweise nicht erst unter Auditdruck zusammensuchen muss.
Die regulatorischen Anforderungen werden dadurch nicht kleiner. Ihre Umsetzung wird aber nachvollziehbarer, Verantwortlichkeiten werden klarer und unnötige Doppelpflege lässt sich reduzieren.
Prozessebene statt Normenliste
Bidirektionale Traceability
Ist eine Norm nur irgendwo im QM-Handbuch erwähnt oder lässt sich ihre Umsetzung wirklich verfolgen? Entscheidend ist der Weg von der Anforderung zum Prozess und vom Prozess zurück zur regulatorischen Grundlage.
Das im Whitepaper beschriebene System arbeitet mit einer bidirektionalen Norm-Traceability. Die regulatorischen Anforderungen sind vom QM-Handbuch aus mit den relevanten Prozessen verbunden. Gleichzeitig trägt jede relevante Prozesskarte ihre normative Begründung.
Damit kann die Prüfung in zwei Richtungen erfolgen: vom Normkapitel zum ausführenden Prozess und von einer Prozesskarte zurück zur zugrunde liegenden Anforderung. Inkonsistenzen werden dadurch früher sichtbar und müssen nicht erst im Auditgespräch rekonstruiert werden.
Prozesskarten
Die Prozesslandschaft bildet operative Abläufe, Zuständigkeiten und Verbindungen strukturiert ab.
Norm-Mappings
Normanforderungen werden mit den jeweils relevanten Prozesskarten verknüpft.
ISO-13485-Einträge
Der Schwerpunkt liegt auf einer tiefen Abbildung der Qualitätsmanagement- und Design-Control-Anforderungen.
IEC-62304-Einträge
Der Software-Lebenszyklus wird als verketteter Prozess und nicht nur als Sammlung von Vorlagen behandelt.
Entscheidend ist nicht die Anzahl der Einträge. Der praktische Wert entsteht erst durch die Verbindung zwischen Anforderung, Prozess, Rolle, Dokument und Prüfschritt.
Die vollständige Systembeschreibung und die dokumentierten Prüfergebnisse stehen im Whitepaper zum integrierten QMS/ISMS.
Product Life Cycle
Produkt-Normen im Prozess
Muss jede Produktnorm als eigenes Kapitel im QMS erscheinen? Nein. Das Managementsystem muss sicherstellen, dass anwendbare Anforderungen erkannt, in die Entwicklung übernommen und nachweisbar erfüllt werden.
Produkt- und Prüfnormen wie IEC 60601-1, ISO 10993 oder ISO 14155 sind keine QMS-Normen. Für den Hersteller bleibt aber entscheidend, dass ihre Anwendbarkeit systematisch bewertet und ihre Anforderungen in den Entwicklungsprozessen berücksichtigt werden.
Anwendbarkeit erkennen
Die relevante Norm wird als Entwicklungseingabe identifiziert und in der Normenliste dokumentiert.
Anforderungen überführen
Die normativen Anforderungen fließen in Produkt-, System- und Softwareanforderungen ein.
Erfüllung bestätigen
Verifikation oder Validierung zeigen, ob die Anforderungen am Produkt wirksam umgesetzt wurden.
Damit bleibt die produktspezifische Bewertung dort, wo sie hingehört: in der Entwicklung und in der technischen Dokumentation. Das integrierte Managementsystem stellt den beherrschten und wiederholbaren Prozess dafür bereit.
Die Herstellerpflichten nach der europäischen Medizinprodukteverordnung umfassen unter anderem Konformitätsbewertung, Risikomanagement, technische Dokumentation, Qualitätsmanagement sowie Post-Market-Surveillance- und Vigilanzprozesse. Diese Pflichten müssen in der betrieblichen Umsetzung zusammengeführt werden. Der offizielle Verordnungstext ist über EUR-Lex verfügbar.
QMS und ISMS MedTech
Cybersecurity im Lebenszyklus
Wann beginnt Cybersecurity bei einem Software-Medizinprodukt? Nicht kurz vor der Freigabe. Sie muss von der Planung bis zur Überwachung nach dem Inverkehrbringen in den Product Life Cycle eingebunden sein.
Das beschriebene integrierte Managementsystem bindet Cybersecurity-Aktivitäten direkt in den Product Life Cycle ein. Dazu gehören die Sicherheitsplanung, Threat Modelling, Schwachstellenprüfungen, Cybersecurity-Analysen und die Bewertung sicherheitsrelevanter Änderungen.
Auch die ISO/IEC-27001-Controls werden nicht nur als abstrakte Kontrollliste geführt. Sie sind konkreten Registern, Ablageorten und Verantwortlichkeiten zugeordnet. Für QMS und ISMS sind gemeinsame Steuerungspunkte vorgesehen, während fachlich getrennte Auditnachweise weiterhin nachvollziehbar bleiben.
Managementbewertung und CAPA
Gemeinsame Steuerungsprozesse vermeiden widersprüchliche Entscheidungen und unnötige Doppelpflege.
Fachliche Evidenz bleibt eindeutig
QMS- und ISMS-Nachweise können fachlich getrennt geführt werden, ohne ihre Schnittstellen zu verlieren.
Prüfung und Transparenz
Unabhängig geprüft
Was wurde geprüft, wer hat geprüft und welche offenen Punkte wurden gefunden? Ein belastbarer Prüfhinweis benennt nicht nur Stärken, sondern legt auch Befunde und Grenzen offen.
Das Whitepaper dokumentiert einen internen, evidenzbasierten Verifikationslauf der Wissensbasis. Die unabhängige fachliche Prüfung erfolgte nach Angabe des Herausgebers durch Prof. Dr. Dr. h.c. Frank Stein.
Frank Stein wird als Senior Expert Medical Devices mit Schwerpunkten im Qualitätsmanagement und in der weltweiten Zulassung von Medizinprodukten geführt. Weitere Angaben zu seinem beruflichen Hintergrund sind im öffentlichen Expertenprofil hinterlegt.
Gegenstand des dokumentierten Verifikationslaufs waren insbesondere die Systemstruktur, die referenzielle Integrität, die Klassifizierung der Normzuordnungen und die technische Auditierbarkeit der Evidenz.
Major Findings
Es wurde kein Befund der höchsten Schwereklasse dokumentiert.
Minor Findings
Die dokumentierten Abweichungen betreffen technische Aspekte der Evidenzverknüpfung.
Observations
Zusätzliche Hinweise betreffen unter anderem Datenpflege, Schlüsselfelder und Beschreibungen.
Offen dokumentiert
Die Ergebnisse werden nicht hinter einem pauschalen Perfektionsversprechen versteckt.
Wichtige Abgrenzung: Die unabhängige fachliche Prüfung und der dokumentierte Verifikationslauf ersetzen weder ein Zertifizierungsaudit noch eine produktspezifische Konformitätsbewertung oder die Bewertung durch eine Benannte Stelle.
Nutzen im Tagesgeschäft
Praktischer Nutzen
Kann das System konkrete Fragen zuverlässig beantworten? Welcher Prozess setzt eine Anforderung um, wer entscheidet, welcher Design Input wurde abgeleitet und wo liegt der Verifikationsnachweis?
Welcher Prozess setzt die Anforderung um?
Die Verbindung zwischen Normanforderung und operativem Prozess muss ohne Interpretationssprünge erkennbar sein.
Wer entscheidet und gibt frei?
Rollen, Mandate und Freigaben müssen auch dann eindeutig bleiben, wenn eine Person mehrere Funktionen übernimmt.
Welcher Design Input wurde abgeleitet?
Normative und regulatorische Anforderungen müssen in konkrete Produkt- und Systemanforderungen überführt werden.
Wo liegt der Verifikationsnachweis?
Der Nachweis muss auffindbar, eindeutig zugeordnet und in seiner Version nachvollziehbar sein.
Die Bewertung liefert damit keine pauschale Zertifizierungsaussage. Sie schafft Transparenz über den Reifegrad der Systemarchitektur und über die nächsten sinnvollen Verbesserungen.
Einordnung
Für wen passt der Ansatz?
Für welche Unternehmen lohnt sich ein integriertes QMS ISMS? Besonders relevant ist der Ansatz für MedTech-Unternehmen, die Qualitätsmanagement, Informationssicherheit und Produktentwicklung mit begrenzten Ressourcen steuern müssen.
Eine standardisierte Systemstruktur ist sinnvoll, wenn das Unternehmen sein QMS und ISMS selbst betreiben, wiederkehrende Prozesse einheitlich abbilden und Software-, Risiko- und Cybersecurity-Aktivitäten miteinander verbinden möchte.
Für Start-ups und kleinere Teams mit einfacherem bis mittlerem Scope ist das häufig auch über den Easy13485 Makerspace lösbar, den das Unternehmen selbst betreibt. Bei komplexen Produktportfolios, gewachsenen Organisationsstrukturen oder unternehmensspezifischen Verantwortungsmodellen ist eine individuelle Prozessberatung meist die passendere Tür.
Ein System ersetzt keine Verantwortung. Wirksamkeit entsteht erst durch gepflegte Anforderungen, belastbare Risikobewertungen, dokumentierte Entscheidungen und konsequent ausgeführte Entwicklungs- und Überwachungsprozesse.
Häufige Fragen
Vor der Einführung
Ist das System automatisch zertifizierungsfähig? Was belegt die unabhängige Prüfung? Und wie weit sollten QMS und ISMS tatsächlich zusammengeführt werden?
Ist ein integriertes QMS ISMS automatisch zertifizierungsfähig?
Nein. Eine strukturierte und geprüfte Systemarchitektur kann Auditierbarkeit und konsistente Nachweisführung unterstützen. Ob das Unternehmen die Anforderungen erfüllt, hängt von der konkreten Implementierung, dem Anwendungsbereich, den Produkten und der gelebten Prozessumsetzung ab.
Ist die Prüfung durch Frank Stein eine Zertifizierung?
Nein. Die unabhängige fachliche Prüfung ist weder ein Zertifizierungsaudit noch eine Bewertung durch eine Benannte Stelle. Sie macht aber nachvollziehbar, welche Systemaspekte geprüft und welche Befunde dokumentiert wurden.
Warum werden Minor Findings und Observations veröffentlicht?
Weil ein System ohne sichtbare offene Punkte nicht automatisch gründlicher geprüft ist. Die Veröffentlichung zeigt, wo die Systemarchitektur trägt und an welchen Stellen die technische Auditierbarkeit oder Datenpflege verbessert werden muss.
Müssen QMS und ISMS vollständig in einem einzigen System verschmelzen?
Nicht zwingend. Fachlich getrennte Nachweise können sinnvoll oder erforderlich bleiben. Entscheidend ist, dass gemeinsame Steuerungspunkte, Schnittstellen und Auswirkungen eindeutig geregelt sind. Dazu gehören beispielsweise Managementbewertung, CAPA, Änderungsmanagement, Risikomanagement und Verantwortlichkeiten.
Was passiert, wenn bestehende Prozesse nicht zum Standardsystem passen?
Dann sollte nicht der tatsächliche Ablauf in ein unpassendes Modell gezwungen werden. Die Prozessarchitektur muss an Produkte, Organisation, Verantwortlichkeiten und regulatorische Risiken angepasst werden. Genau dort beginnt individuelle Prozessberatung.
Prozessberatung für MedTech
QMS und ISMS verbinden
Wie lassen sich Prozesslandschaft, Verantwortlichkeiten und regulatorische Nachweise so abstimmen, dass sie im Tagesgeschäft funktionieren und im Audit nachvollziehbar bleiben?
