Wie unterstützt ein elektronisches QMS die MDSAP-Anforderungen?

Von Vaclav Vlcek, MD

Kurz gefasst:

Teil 1 hat die drei Kontrollen im MDSAP Audit Approach dargelegt, die für ein elektronisches QMS besonders relevant sind: die Lenkung von Dokumenten und Aufzeichnungen, die Kompetenz des Personals und die Validierung der Software für ihre vorgesehene Verwendung. Dieser Artikel verfolgt ein einzelnes Dokument durch unser eigenes eQMS und zeigt daran, wie diese Kontrollen umgesetzt werden. Zu jedem Zeitpunkt ist eine Version in Kraft, die ersetzte Version wird aufbewahrt und nicht überschrieben, Signaturen sind einer namentlich benannten Person zugeordnet, und eine Änderung wird danach behandelt, ob sie die Arbeit der Menschen berührt. Das System unterstützt eine Organisation dabei, diese Anforderungen zu erfüllen. Es kann sie nicht an ihrer Stelle erfüllen.

Teil 1 hat dargelegt, was der aktuelle MDSAP Audit Approach von einem Auditor bestätigt sehen will. Die geltende Fassung ist AU P0002.011 mit Revisionsdatum 3. August 2026.

Dieser Artikel zeigt die andere Hälfte.

Die Auditkriterien zu erfüllen ist die Ausgangslage. Ein System zu betreiben, das ein Team täglich nutzen kann, ohne es auszubremsen, ist der Teil, der darüber entscheidet, ob ein Qualitätsmanagementsystem trägt oder zur Last wird.

Wir haben unser eQMS so entworfen, dass es das ISO-13485-Qualitätsmanagementsystem einer Organisation unterstützt, und es ist das System, mit dem wir unsere eigene Qualitätsarbeit betreiben. Im Folgenden zeigen wir dieses System so, wie wir es selbst einsetzen. Die Fassung eines Kunden wird auf dessen Prozesse und auf die angestrebten Märkte zugeschnitten, sodass die Einzelheiten abweichen; die hier beschriebenen Kontrollen gelten in beiden Fällen.

Wir verfolgen hier ein einzelnes Dokument durch das System, um zu zeigen, wie die Kontrollen greifen und wie das System für den täglichen Einsatz konzipiert ist.

Wie das System aufgebaut ist

Das System ist als Hierarchie organisiert, und jede Ebene erbt von der darüberliegenden. Diese Struktur zu verstehen ist der Schlüssel zu allem Weiteren.

Es gibt drei Ebenen.

• Die Kategorie ist die oberste Gruppierung, unter der Dokumente abgelegt werden; sie gibt jedem Dokument seine Nummer.

• Das QMS-Dokument ist der übergeordnete Datensatz, der alles enthält, was über die Lebensdauer eines Dokuments hinweg gemeinsam gilt: Name, Typ und die Zugriffseinstellungen, die festlegen, wer es erstellt, prüft, genehmigt und wer dazu geschult wird.

• Die Dokumentversion ist eine einzelne Datei, die unter diesem übergeordneten Datensatz angelegt wird; nur eine Version ist zu einem Zeitpunkt in Kraft.

Die Vererbung macht das praktikabel.

Die Zugriffseinstellungen und Regeln werden einmal am übergeordneten Datensatz festgelegt, und jede darunter angelegte Version übernimmt sie. Für eine neue Version muss nicht erneut eingetragen werden, wer sie genehmigen darf oder wer dazu geschult werden muss. Das wird einmal entschieden und einheitlich angewendet, was eine häufige Fehlerquelle beseitigt: eine neue Fassung, die unbemerkt mit den falschen Genehmigenden oder für den falschen Adressatenkreis freigegeben wird.

Zugriff und Verantwortung werden in der Regel Rollen zugewiesen.

Autor, Prüfer und Genehmigende eines Dokuments sind in der Regel Rollen und keine namentlich benannten Personen. Der Autor kann der Risikomanager sein, der Prüfer der Qualitätsmanager. Namentlich benannte Personen lassen sich zuweisen, wenn ein Unternehmen das so will, üblich sind jedoch Rollen. Da einer Rolle eine Gruppe zugeordnet ist, werden der Zugriff und die zugehörige Schulung an einer Stelle verwaltet, und wenn jemand hinzukommt oder die Rolle wechselt, folgen Zugriff und Pflichten der Rolle.

Lenkung von Dokumenten und Aufzeichnungen

Lenkung von Dokumenten bedeutet, dass die aktuelle Version dort verfügbar ist, wo sie gebraucht wird, dass Änderungen genehmigt werden, bevor das Dokument verwendet wird, und dass ersetzte Versionen außer Kraft gesetzt und aufbewahrt werden. Das System setzt dies über eine gelenkte Freigabe durch.

Ein Dokument beginnt als Version, die aus einer Vorlage erzeugt wird, mit dem Status Draft. Sobald es fertig ist, startet der Autor die Freigabe.

Die Freigabe läuft als ein einziger geführter Dialog. Er bringt die Dokumentversion und den Freigabeplan an einer Stelle zusammen, mit einer Fortschrittsleiste, die den Stand der Freigabe zeigt, und einem Hinweisfeld, das die nächste erforderliche Handlung benennt, etwa die Festlegung eines Genehmigenden, bevor die Freigabe starten kann. Jeder Teil hat seinen eigenen Status. Ein Freigabeplan kann gespeichert werden, solange er noch unvollständig ist, und die Freigabe selbst lässt sich erst starten, wenn alles Erforderliche vorliegt.

Prüfer, Genehmigende und Target Audience werden aus den Einstellungen des Dokuments selbst übernommen, sodass niemand erneut eintragen muss, wer welche Aufgabe hat. Der Start der Freigabe ist selbst eine signierte Handlung.

Sind Prüfer zugewiesen, prüfen und signieren sie zuerst. Anschließend genehmigt die genehmigende Person das Dokument, bestätigt die Erklärung und signiert.

In der Freigabestufe werden das Datum des Inkrafttretens und das Datum der nächsten Überprüfung festgelegt. Das Datum der nächsten Überprüfung wird aus dem Criticality Index des Dokuments berechnet und lässt sich auch von Hand eintragen. Das Dokument kann sofort freigegeben oder so geplant werden, dass es zum vorgesehenen Datum in Kraft tritt.

Die für ein Audit wichtigste Kontrolle greift in dem Moment, in dem die neue Version in Kraft tritt. Die Version, die sie ersetzt, erhält automatisch den Status Obsolete.

Es gibt keinen gesonderten Schritt, um das alte Dokument außer Kraft zu setzen, und kein Zeitfenster, in dem zwei Versionen zugleich gelten. Welche Version die aktuelle ist, steht nie infrage.

Die ersetzte Version wird aufbewahrt und nicht überschrieben

Teil 1 hat die Aufbewahrungsregel dargelegt: mindestens ein veraltetes Exemplar jedes gelenkten Dokuments, aufbewahrt über einen Zeitraum, der mindestens der Lebensdauer des Produkts entspricht und zwei Jahre ab dem Datum der Produktfreigabe nicht unterschreitet.

Hier zeigt sich der Wert des Versionsmodells. Eine ersetzte Version wird als Obsolete gekennzeichnet und als eigenständige Aufzeichnung aufbewahrt, zusammen mit dem Genehmigungsdatensatz, mit dem sie freigegeben wurde. Das System speichert die Versionshistorie und nicht nur den aktuellen Stand.

Ein Dokument sammelt über seine Lebensdauer Versionen an, und jede davon lässt sich mit dem Nachweis abrufen, wer sie wann genehmigt hat. Was das System leistet, ist das Speichern und Abrufen ersetzter Versionen und deren Verwaltung nach den Aufbewahrungsregeln, die ein Unternehmen festgelegt hat. Die Aufbewahrungsfristen selbst und die Steuerung dessen, wer etwas löschen darf, bleiben Sache der Organisation, weil sie vom Produkt und von den betroffenen Märkten abhängen.

Die Statusbezeichnungen, die diesen Lebenszyklus steuern, von Draft und Approved bis Effective und Obsolete, werden vom System über den Freigabeprozess gesetzt und lassen sich nicht von Hand ändern. Ein davon getrennter arbeitsstatus erlaubt es Teams, ihren eigenen Fortschritt zu kennzeichnen, ohne Auswirkung auf den gelenkten Lebenszyklus. Der Status, auf den sich ein Auditor stützt, ist der vom System gesetzte.

Die Liste der QMS-Dokumente dient zugleich als aktuelle Übersicht darüber, was genehmigt und in Kraft ist, und genau das verlangen mehrere Märkte ausdrücklich. Brasilien verlangt, wie in Teil 1 erwähnt, eine Liste der genehmigten und in Kraft befindlichen Dokumente sowie Änderungsaufzeichnungen und Sicherungen elektronischer Aufzeichnungen. Was davon das System unmittelbar abdeckt und was von der Einrichtung abhängt, ist eine Frage der konkreten Umsetzung und keine Aussage, die sich allgemein treffen lässt.

Eine Einschränkung dieser Darstellung sollte klar benannt werden. Das Audit erfasst Dokumente und Aufzeichnungen sowohl interner als auch externer Herkunft. Was folgt, betrifft überwiegend Dokumente, die ein Unternehmen selbst verfasst und lenkt, und die Aufzeichnungen, die seine Freigaben erzeugen.

Aufzeichnungen und Signaturen

Gelenkte Aufzeichnungen müssen identifizierbar, lesbar, geschützt und abrufbar bleiben und so lange aufbewahrt werden, wie es die Regeln verlangen. Bei einer Freigabeaufzeichnung müssen die Entscheidungen zusätzlich einer Person zuordenbar sein. Dieser Abschnitt zeigt die Nachweise, die eine Freigabe erzeugt, und damit einen Teil der Lenkung von Aufzeichnungen und nicht deren Gesamtheit.

Jede Signaturhandlung wird mit einer persönlichen Signatur-PIN bestätigt, einer vereinfachten elektronischen Signatur. Die PIN steht für die Unterschrift der Person. Sie wird von dieser Person gesetzt und soll nur ihr bekannt sein und nur von ihr verwendet werden. Bei jeder Verwendung bestätigt die Person, dass sie für diese Signatur verantwortlich ist und ihre Zugangsdaten nicht weitergegeben hat. Damit ist die Signatur einer namentlich benannten Person zugeordnet. Solange ein Nutzer seine PIN nicht gesetzt hat, kann er nichts ausführen, was eine Signatur erfordert.

Jede Freigabe erzeugt einen Genehmigungsdatensatz. Er zeigt, was eingereicht wurde und von wem, den Prüfstatus und die prüfende Person sowie den Genehmigungsstatus mit Datum und etwaigen Kommentaren.

Diese Felder sind schreibgeschützt. Die Entscheidungen wurden im Freigabeprozess getroffen, weshalb der Datensatz den Prüfpfad der Freigabe bildet. Dataverse, die der Anwendung zugrunde liegende Datenschicht, speichert die Aufzeichnungen selbst: die Tabellen, die Audit-Protokolle, die Genehmigungen und die Signaturen. Wie viel protokolliert wird und wie lange, hängt davon ab, wie die Umgebung eingerichtet ist, und das gehört zu dem, was eine Organisation konfiguriert und validiert.

Fragen, die während einer Freigabe aufkommen, werden als Konsultationen erfasst und bleiben bei der Freigabe, sodass eine Rückfrage direkt innerhalb der Freigabe beantwortet wird und nicht per E-Mail. Wer eine Konsultation eröffnet hat, kann sie löschen, solange es keine Antworten gibt; sobald Antworten vorliegen, lässt sie sich nur noch schließen. Diese Verläufe gehören zum selben Prüfpfad.

Das Ergebnis ist, dass ein großer Teil der Nachweise, nach denen ein Auditor fragt, bereits vorliegt. Wer welche Version eines Dokuments wann und mit welcher Signatur genehmigt hat, wird festgehalten, während die Arbeit geschieht, und nicht im Nachhinein zusammengetragen.

Kompetenz und die zwei Arten von Änderung

Teil 1 hat dargelegt, was sich im aktuellen Audit Approach geändert hat: Die Personalaufgabe wurde von der Schulung auf die Kompetenz verlagert, und das Audit endet nicht bei der Teilnahme. Es prüft, ob die ergriffene Maßnahme dazu geführt hat, dass die erforderliche Kompetenz erreicht wurde. Die Wirksamkeitsprüfung muss dem Risiko der Arbeit angemessen sein.

Zu entscheiden, was eine Änderung erfordert, ist Aufgabe der Organisation, und sie hält diese Entscheidung in ihrem eigenen Qualitätsmanagementsystem fest. Die Software unterstützt die Arbeit, die daraus folgt.

Das System unterscheidet zwei Arten von Änderung.

Eine Überarbeitung, die das Dokument selbst verändert, wird zu einer neuen Dokumentversion. Sie durchläuft Prüfung, Genehmigung und Freigabe. Wenn eine schulung erforderlich und eingerichtet ist, wird sie bei der Freigabe erzeugt oder der Target Audience des Dokuments zugewiesen, die vom übergeordneten Datensatz geerbt wird.

Die Änderung eines Werts oder eines Querverweises, der in mehreren Dokumenten verwendet wird, erfolgt zentral in der Inhaltsverwaltung. Wird der Wert dort bearbeitet, listet das System alle Dokumente auf, die ihn verwenden, mit einer Anzeige, welche davon nicht mehr übereinstimmen, und der neue Wert lässt sich anschließend in die nicht mehr aktuellen Dokumente übertragen.

Die Grenze dieser Funktion ist der Punkt, den man kennen sollte. Eine solche Übertragung kann keine Version ändern, die in Kraft, obsolet oder bereits in einer laufenden Freigabe ist. Sie erreicht ausschließlich Entwürfe. Ein freigegebenes Dokument wird so geändert, wie jedes freigegebene Dokument geändert wird: durch eine neue Version, die Prüfung, Genehmigung und Freigabe durchläuft.

Nachweis über die Teilnahme hinaus

Eine Schulung wird auf eine von zwei Arten abgeschlossen, und der Unterschied entscheidet darüber, was die Aufzeichnung zeigt.

Eine Schulung vom Typ Read & Understood hält fest, dass eine Person bestätigt hat, das Dokument gelesen zu haben. Eine Schulung vom Typ Questionnaire verlangt die Beantwortung von Fragen. Der Schwellenwert Pass threshold wird als Anzahl der erforderlichen richtigen Antworten im Verhältnis zur Gesamtzahl festgelegt und als Prozentwert angezeigt. Wer die Schwelle nicht erreicht, absolviert die Schulung erneut.

Die daraus entstehende Aufzeichnung enthält das Ergebnis „bestanden“ oder „nicht bestanden“ gemessen an dieser Schwelle, nicht die einzelnen Antworten. Sie geht über eine Lesebestätigung hinaus und ist eine von mehreren Grundlagen. Kompetenz selbst beruht auf Ausbildung, Schulung, Fähigkeiten und Erfahrung zusammen, weshalb ein Ergebnis aus einer solchen Schulung zum Kompetenznachweis beiträgt, Kompetenz aber nicht allein belegt.

Der Schulungsinhalt ist selbst gelenkt. Wo eine Genehmigung erforderlich ist, durchläuft eine Schulungsversion Prüfung und Genehmigung, bevor sie in Kraft tritt. Die Fragen, die Personen beantworten, sind genehmigtes Material und nichts kurzfristig Zusammengestelltes.

Das Dashboard jeder Person zeigt nur die in Kraft befindliche Version der ihr zugewiesenen Dokumente, nach Kategorie gruppiert, zusammen mit ihren Schulungen, geordnet nach Status: überfällig, bald fällig, ausstehend oder abgeschlossen.

Die Ansicht wird aus den Zuweisungen der Person aufgebaut. Dadurch gelangt die Person zur aktuellen Version und sieht, was noch offen ist.

Die Ansicht Coverage Gaps listet Dokumentversionen auf, denen keine Schulung zugeordnet ist oder deren Schulung abgelehnt oder veraltet ist. Sie macht eine Lücke sichtbar, damit jemand darauf reagieren kann. Sie verhindert keine Freigabe: Wird eine Version ohne angelegte Schulung freigegeben, weist das System darauf hin und fragt, ob dennoch fortgefahren werden soll, und die Entscheidung liegt bei der freigebenden Person.

Die Validierung des Systems selbst

Teil 1 hat eine Anforderung dargelegt, über die man leicht hinwegliest. Der Audit Approach erwartet, dass die im Qualitätsmanagementsystem eingesetzte Software anhand eines schriftlichen Protokolls für ihre vorgesehene Verwendung validiert wird, und das gilt auch für extern bezogene statt selbst entwickelte Software.

An dieser Stelle muss die Aufgabenteilung klar benannt werden.

Wir bauen und liefern das System, und wir können die Grundlagen bereitstellen, auf die sich eine Validierung stützt: was die Software tut, wie sich die in diesem Artikel beschriebenen Kontrollen verhalten, was sich in einer Version geändert hat, und unsere eigenen Testnachweise. Die Validierung selbst liegt bei der Organisation. Sie legt ihre eigene vorgesehene Verwendung fest und was sie vom System braucht, bestimmt im Voraus, was als erfolgreiches Ergebnis gilt, wendet das Protokoll auf ihre eigene Konfiguration an und bewahrt die Aufzeichnungen auf.

Validiert wird das konfigurierte System und nicht das Produkt im Allgemeinen. Das heißt: die eingesetzten Abläufe, wer welche Berechtigungen hat, etwaige Verbindungen zu anderen Systemen, die Signatureinstellungen, was die Umgebung protokolliert und wie lange, sowie die Regelungen zu Aufbewahrung und Sicherung. Ändert sich davon etwas, durchläuft die Änderung die Änderungslenkung und wird erneut validiert, wenn die Änderung dies rechtfertigt.

Kein Anbieter kann MDSAP- oder ISO-13485-Konformität mit einem Produkt mitliefern. Ein Auditor prüft den Umgang des Herstellers mit dem System, einschließlich der Frage, ob es für den vom Hersteller vorgesehenen Einsatz validiert wurde.

Das ist gewöhnliche Arbeit im Rahmen der Computersystemvalidierung, und sie ist der Grund, warum der letzte Abschnitt dieses Artikels ebenso wichtig ist wie die Kontrollen davor. Ein System, das sich einfach beschreiben lässt, lässt sich einfacher validieren.

Die Logik hinter dem Entwurf

Die Kontrollen oben unterstützen die Anforderung. Der Entwurf entscheidet darüber, ob die Menschen das System überhaupt nutzen.

Die grundlegende Entscheidung ist, dass das eQMS die Umgebung des Kunden ergänzt, statt sie zu ersetzen.

Es baut auf der Microsoft Power Platform und dem breiteren Microsoft-Ökosystem auf, sodass es die Werkzeuge erweitert, die eine Organisation ohnehin einsetzt: SharePoint, Dataverse, Power Automate, Teams. Das ist dasselbe Prinzip, das QMLogic überall anwendet: nutzen, was funktioniert, erweitern, was nicht funktioniert, und das Werkzeug an die Organisation anpassen. Es erleichtert auch die Einführung, weil es weniger zu lernen und weniger auszutauschen gibt.

Von da an ist das leitende Prinzip die Einfachheit.

Ein Qualitätsmanagementsystem funktioniert nur, wenn die Menschen, die darauf angewiesen sind, es im Alltag tatsächlich nutzen können. Das Entwurfsziel ist deshalb die einfachste Lösung, die die Anforderung erfüllt. Ein System, das die Menschen meiden, hilft einem Unternehmen nicht, so vollständig es auf dem Papier auch aussehen mag.

ISO 13485 lässt dafür Raum. Sie legt die Kontrollen fest, die vorhanden sein müssen, und überlässt den größten Teil der Entscheidungen über deren Umsetzung der Organisation.

Die Lenkung von Dokumenten und die Lenkung von Aufzeichnungen, die beiden Anforderungen, die ein Dokumentenlenkungssystem am stärksten betreffen, verlangen, dass ein Dokument genehmigt, aktuell gehalten und außer Kraft gesetzt wird, wenn es ersetzt wird, und dass Aufzeichnungen lesbar, abrufbar und aufbewahrt bleiben. Sie sagen nicht, wie das System zu bauen ist, das das leistet. Die Umsetzung bleibt der Organisation überlassen, und die einfachste, die die Anforderung erfüllt, ist meist die beste, weil sich später ergänzen lässt, was sich als tatsächlicher Bedarf zeigt.

Der Abstand zwischen dem, was die Norm vorgibt, und dem, was ein funktionierendes System braucht, ist größer, als er wirkt.

Die Validierung der Software, auf der ein Qualitätsmanagementsystem läuft, ist ein Beispiel dafür. Die Norm behandelt sie knapp: Sie verlangt ein dokumentiertes, dem Risiko angemessenes Vorgehen, die Validierung der Software vor der Erstverwendung und erneut, wenn eine Änderung dies erfordert, sowie die Aufbewahrung der entsprechenden Aufzeichnungen. Sie sagt, was zutreffen muss, und überlässt die konkrete Ausgestaltung der Organisation. Das tatsächliche Verfahren auszuarbeiten hieß, von der gelebten Praxis eines Unternehmens auszugehen und dort Kontrollen zu ergänzen, wo sie nötig waren.

Die Arbeit im Microsoft-Umfeld bedeutet außerdem, dass vieles von dem, was ein Qualitätsmanagementsystem braucht, bereits vorhanden ist.

Die Plattform liefert eine Aufzeichnung darüber, wer welchen Eintrag angelegt und geändert hat, eine Versionshistorie und einen Rahmen für Ansichten, Formulare und Zusammenarbeit. Vieles von dem, was ein QMS auf dem Papier braucht, ist in der Umgebung bereits vorhanden, sodass die Arbeit darin besteht, es sinnvoll zu konfigurieren. Bleibt diese Schicht schlank, ist das System einfach im Betrieb, einfacher zu validieren und schnell anpassbar, wenn sich Anforderungen ändern.

Dasselbe Prinzip zeigt sich in den kleineren Entscheidungen.

Ob ein Dokument eine Prüfung braucht, leiten wir daraus ab, ob ein Prüfer zugewiesen ist. Früher war das eine separate Einstellung zum Ein- und Ausschalten. Wir haben das geändert, weil die separate Einstellung eine weitere Fehlerquelle war: Ein Dokument konnte als prüfungspflichtig gekennzeichnet sein, ohne dass ein Prüfer benannt war, oder umgekehrt. Dass der Schritt aus der Zuweisung abgeleitet wird, beseitigt diesen Widerspruch. Gibt es einen Prüfer, gibt es eine Prüfung; gibt es keinen, gibt es keine.

Wir haben den übergeordneten Datensatz umbenannt. Ursprünglich hieß er Master Document, und wir haben festgestellt, dass der Begriff die Menschen verwirrt hat, deshalb heißt er nun QMS-Dokument. Der Datensatz selbst hat sich nicht geändert, nur der Name, aber ein Name, den die Menschen richtig verstehen, gehört dazu, dass ein System benutzbar ist.

Wir lassen eine Schulung mehrere Dokumentversionen abdecken. Werden zusammengehörige Dokumente gleichzeitig geändert, absolvieren die Betroffenen eine einzige Schulung statt einer Reihe fast gleicher. Der Schulungsnachweis wird weiterhin je Person festgehalten, und der Schulungsaufwand vervielfacht sich nicht mit jeder kleinen zusammenhängenden Änderung.

Keine dieser Entscheidungen ändert, was das System lenkt. Jede ändert, wie viel Aufwand erforderlich ist, um es richtig zu betreiben, und das ist der Unterschied zwischen einem Qualitätsmanagementsystem, dem die Menschen folgen, und einem, das sie umgehen.

Was das zeigt

Über den gesamten Ablauf hinweg unterstützt ein auf ISO 13485 aufgebautes elektronisches QMS die drei Kontrollen aus Teil 1 als Teil der normalen Arbeit.

Eine Version ist in Kraft und verfügbar. Die ersetzte Version wird aufbewahrt statt überschrieben und lässt sich abrufen. Signaturen sind einer namentlich benannten Person zugeordnet, und der Prüfpfad entsteht, während die Arbeit geschieht. Wo eine Änderung eine Schulung verlangt, weist die Aufzeichnung anhand einer festgelegten Schwelle das Ergebnis „bestanden“ oder „nicht bestanden“ aus und nicht nur eine Lesebestätigung.

Die Softwarevalidierung liegt bei der Organisation, und ein System, das sich einfach beschreiben lässt, lässt sich einfacher validieren.

Diese Darstellung behandelt die Lenkung von Dokumenten, Aufzeichnungen und Schulungen. Andere Teile des Audits, etwa Korrektur- und Vorbeugungsmaßnahmen, die Bearbeitung von Beschwerden und die Managementbewertung, liegen außerhalb dessen, was hier beschrieben ist. Wie sich ein System erweitern lässt, um sie abzudecken, ist ein eigenes Thema, auf das wir zurückkommen werden.

Häufig gestellte Fragen

1. Wie steuert QMLogic eQMS, welche Dokumentversion in Kraft ist?

   • Über eine gelenkte Freigabe. Tritt eine neue Version in Kraft, wird die Version, die sie ersetzt, automatisch als obsolet gekennzeichnet. Nur eine Version ist zu einem Zeitpunkt in Kraft, sodass nie infrage steht, welches Dokument das aktuelle ist.

2. Was geschieht in QMLogic eQMS, wenn ein Dokument aktualisiert wird?

   • Die bisherige Version wird in dem Moment, in dem die neue Version in Kraft tritt, automatisch als obsolet gekennzeichnet und als Aufzeichnung aufbewahrt, zusammen mit dem Genehmigungsdatensatz, mit dem sie freigegeben wurde. Nichts wird überschrieben. Das System speichert ersetzte Versionen und ruft sie ab; wie lange sie aufbewahrt werden und wer etwas entfernen darf, legt die Organisation entsprechend den für sie geltenden Aufbewahrungsregeln fest.

3. Wie werden elektronische Signaturen in QMLogic eQMS gehandhabt?

   • Jede Signaturhandlung wird mit einer persönlichen Signature PIN bestätigt, einer vereinfachten elektronischen Signatur, die von der Person selbst gesetzt wird und nur ihr bekannt sein soll. Bei jeder Verwendung bestätigt die Person ihre Verantwortung für die Signatur. Damit ist jede Signatur einer namentlich benannten Person zugeordnet.

4. Woher stammt der Prüfpfad einer Freigabe in QMLogic eQMS?

   • Er entsteht aus der normalen Arbeit. Jede Freigabe erzeugt einen schreibgeschützten Genehmigungsdatensatz, der zeigt, wer das Dokument eingereicht, wer es geprüft und wer es genehmigt hat und wann die jeweilige Handlung erfolgte. Fragen, die während der Freigabe aufkommen, werden als Konsultationen erfasst und bleiben bei der Freigabe; wer eine eröffnet hat, kann sie löschen, solange es keine Antworten gibt, und sobald Antworten vorliegen, lässt sie sich nur noch schließen. Wie viel die gesamte Umgebung protokolliert und wie lange, hängt von deren Einrichtung ab.

5. Erfordert jede Dokumentenänderung eine erneute Schulung?

   • Nein. Zu entscheiden, was eine Änderung erfordert, ist Sache der Organisation und wird in ihrem eigenen Qualitätsmanagementsystem festgehalten. In der Software wird eine Überarbeitung des Dokuments zu einer neuen gelenkten Version. Wenn eine Schulung erforderlich und eingerichtet ist, wird sie bei der Freigabe erzeugt oder zugewiesen. Die Änderung eines gemeinsam genutzten Werts oder Querverweises lässt sich zentral in der Inhaltsverwaltung vornehmen, die anzeigt, welche Dokumente nicht mehr übereinstimmen, und den neuen Wert in Entwürfe übertragen kann. Diese Funktion kann keine Version verändern, die in Kraft, obsolet oder in einer laufenden Freigabe ist.

6. Welchen Nachweis erzeugt die Schulung in QMLogic eQMS?

   • Eine Schulung vom Typ Questionnaire verlangt die Beantwortung von Fragen anhand des Schwellenwerts Pass threshold, also der Anzahl der erforderlichen richtigen Antworten im Verhältnis zur Gesamtzahl. Wer die Schwelle nicht erreicht, absolviert die Schulung erneut. Die Aufzeichnung enthält das Ergebnis „bestanden“ oder „nicht bestanden“ gemessen an dieser Schwelle, nicht die einzelnen Antworten. Sie geht über eine Lesebestätigung hinaus und ist eine Grundlage für die Beurteilung der Kompetenz, aber für sich genommen kein Beleg dafür.

7. Muss ein eQMS für MDSAP validiert werden?

   • Ja. Der MDSAP Audit Approach erwartet, dass die im Qualitätsmanagementsystem eingesetzte Software für ihre vorgesehene Verwendung validiert wird, und das gilt auch für extern bezogene statt selbst entwickelte Software. Der Anbieter kann bereitstellen, worauf sich eine Validierung stützt; die Organisation legt ihre eigene vorgesehene Verwendung fest, bestimmt im Voraus, was als erfolgreiches Ergebnis gilt, wendet das Protokoll auf ihre eigene Konfiguration an und bewahrt die Aufzeichnungen auf. Validiert wird das konfigurierte System, einschließlich Abläufen, Berechtigungen, Verbindungen, Signatureinstellungen, Protokollierung und Aufbewahrung, mit erneuter Validierung, wenn eine Änderung dies rechtfertigt.

8. Macht der Einsatz eines konformen eQMS unser Qualitätsmanagementsystem konform?

   • Nein. Konformität liegt bei der Organisation. Ein Auditor betrachtet, wie der Hersteller das System einsetzt, einschließlich der Frage, ob es für den vom Hersteller vorgesehenen Einsatz validiert wurde. Kein Produkt kann Konformität mitliefern.