QM Dokumentenlenkung: Wie viele im Audit scheitern

Unter Dokumentenlenkung versteht man ein dokumentiertes Verfahren, das festlegt, wie Dokumente erstellt, geprüft, genehmigt, gekennzeichnet, verteilt und aktualisiert werden.

Nach ISO 9001 oder ISO 13485 zertifizierte Organisationen sind zur Dokumentenlenkung verpflichtet.

1. Gegenstand der Dokumentenlenkung

Dass es bei der Dokumentenlenkung um Dokumente geht, ist offensichtlich. Weniger offensichtlich ist, was Dokumente sind.

Als Dokumente verstehen manche die Übermenge von

• Vorgabedokumenten (z. B. Verfahrensanweisungen, Arbeitsanweisungen, Templates, Checklisten, Formulare) und
• Aufzeichnungen (z. B. Messprotokolle, ausgefüllte Checklisten und Formulare).

Teilweise werden die „Vorgabedokumente“ und „Dokumente“ synonym verwendet, was zur Verwirrung beiträgt.

Daher ist es hilfreich, die Übermenge der Vorgabedokumente und Aufzeichnungen als „dokumentierte Informationen“ zu bezeichnen, wie das die ISO 9001 ab der Version 2015 tut. Sie unterscheidet bei der Dokumentenlenkung (im Gegensatz zu anderen Normen wie der ISO 13485) nicht mehr zwischen Vorgabedokumenten und Aufzeichnungen.

2. Ziele der Dokumentenlenkung

Für Auditoren gilt: Was nicht dokumentiert ist, das existiert nicht. Entsprechend wichtig sind Dokumente und Aufzeichnungen auch im Audit.

Was unter der Dokumentenlenkung zu verstehen ist, wird im Englischen mit „Control of Document“ klarer: Die Dokumentenlenkung hat als Ziel sicherzustellen, dass

• die richtigen (korrekten, vollständigen) Informationen
• zum richtigen Zeitpunkt
• bei den richtigen Adressaten

verfügbar sind. Das wiederum bedingt, dass

• keine ungültigen, falschen, unvollständigen Informationen verteilt werden,
• ungültige Informationen zurückgezogen werden,
• man weiß, wer diese Informationen erhalten muss,
• diese Personen über neue, geänderte oder gelöschte Dokumente informiert werden und
• man sicherstellt, dass diese Personen diese Informationen auch verstehen.

3. Regulatorische Anforderungen an die Dokumentenlenkung

Die eben genannten Aspekte finden sich in den Normen wie der ISO 13485. Sie fordern, dass man festlegt (dokumentiert natürlich :-)), wie man

• Dokumente bewertet, bevor man sie verteilt,
• Dokumente aktualisiert und genehmigt,
• sicherstellt, dass Änderungen erkennbar sind,
• gewährleistet, dass die Dokumente verfügbar sind (und auch lesbar bleiben),
• sicherstellt, dass keine alten Versionen im Umlauf sind und
• die Dauer bestimmt, für die man Dokumente aufbewahren will (wobei es hier konkrete Mindestanforderungen gibt).

Die ISO 13485 spricht nicht von der ‚Freigabe‘ der Dokumente, sondern von deren ‚Genehmigung‘.

4. Typische Probleme: Was im Audit immer wieder schiefgeht

In den Audits stoßen Hersteller und Auditoren regelmäßig auf Probleme wie diese:

• Die Dokumente bzw. Informationen sind unbekannt. Fragen Sie mal einen Mitarbeiter am Band, was die Qualitätspolitik ist …
• Am Arbeitsplatz liegt eine veraltete Arbeitsanweisung.
• In internen Audits wurde die Dokumentenlenkung nicht geprüft.
• Es ist nicht eindeutig, auf welche Produkt- oder Software-Version sich Dokumente beziehen.
• Für eine Produkt- oder Software-Version gibt es keine aktualisierten Dokumente.
• Die Entwicklungsdokumente wie der Entwicklungsplan wurden freigegeben, nachdem die Entwicklung längst gestartet war.
• Die Verfahrensanweisung legt nicht fest, wie lange und auf welche Weise Dokumententypen aufzubewahren sind, oder sie ignoriert gesetzliche Vorgaben.
• Es fehlen festgelegte Prüfkriterien, anhand derer die verschiedenen Dokumententypen jeweils zu bewerten sind. Eine Unterschrift alleine genügt nicht.
• Im Dateisystem oder im SharePoint finden sich Dokumente, die den Status (z. B. Entwurf, freigegeben, zurückgezogen) nicht erkennen lassen.
• Im Dateisystem befinden sich mehrere Dateien des gleichen Namens, aber mit verschiedenen Inhalten.
• Der Hersteller kann nicht erklären, ob und wie er Dokumente wie Arbeits- oder Verfahrensanweisungen geschult hat bzw. weshalb das nicht notwendig war.
• Geänderte Vorgabedokumente wurden nicht erneut geschult.

Das Johner Institut erlebt regelmäßig Audits, in denen die Dokumentenlenkung zu Abweichungen führt. Diese Beanstandungen sind nicht Ausdruck eines überbordenden Formalismus, sondern meist eines Chaos beim Medizinprodukte-Hersteller, das nicht auf die Dokumente beschränkt ist.

5. Möglichkeiten, um Dokumente zu lenken

5.1 Übersicht

Es stehen zahlreiche technische Möglichkeiten zur Verfügung, um Dokumente zu lenken. Dazu zählen

• Dateisystem, Netzwerklaufwerke
  Hier sollten Sie Lese- und Schreibberechtigungen regeln und sicherstellen, dass die betreffenden Personen auch Zugriff haben. Das ist besonders in der Produktion ein Thema.
• Cloudspeicher
  Mit Diensten wie Dropbox oder Google Drive und deren Mobil-Clients können Ihre Mitarbeitenden leicht auf Dokumente zugreifen. Die Einschränkung von Lese- oder Schreibrechten gelingt aber nicht so einfach.
• Dokumentenmanagementsysteme
  Anwendungen wie Microsoft Sharepoint (auch als Cloud-Service verfügbar) oder Dokumentenlenkungs-Software (von z. B. roXtra oder PTC) vereinfachen die Versionierung und erlauben die Definition von Dokumenten-Workflows zum Erstellen, Prüfen, Freigeben, Veröffentlichen und Zurückziehen von Dokumenten. Die Schwierigkeiten liegen meist im Detail, im Aufsetzen und Konfigurieren der Werkzeuge sowie in deren Schulung.
• Wiki → PDF
  Einige Firmen arbeiten mit Wiki-Systemen wie Confluence und nutzen entweder Plug-ins zur Freigabe (elektronische Unterschrift) oder exportieren die Dokumente als PDF, nutzen das Wiki also „nur“ als Editor. Die Werkzeuge unserer Schwesterfirma Medsoto wie das MedPack und das DocuPack ersparen sogar das Ausdrucken.
• Versionsverwaltungssysteme
  Firmen, die entwicklungsnah arbeiteten, setzen überwiegend Versionsverwaltungssysteme wie SVN oder Git ein. Diese Systeme eignen sich aber eher für rein textuelle Dokumente, z. B. in Markdown. Die allgemeine Benutzerfreundlichkeit ist nicht immer gegeben. Andererseits eröffnen Feature wie Branching, Tagging, Commit-Kommentare und die Einbindung in Build-Tools neue Möglichkeiten. Mehr dazu finden Sie im nächsten Kapitel beschrieben.

5.2 Beispiel: Dokumentenlenkung (nur für Techies)

5.2.1 Vorgehen

Techies können eine Kombination der Werkzeuge Git, Pandoc und Jenkins einsetzen. Mit dieser Tool-Chain lässt sich der folgende Workflow erreichen:

• Dokument in Markdown
  Der Autor erstellt ein Dokument in Markdown. Das ist eine rein textbasierte Sprache, die sehr einfach zu erlernen ist. Beispiel: Man unterstreicht man einen Text mit Gleichheitszeichen („=======“), um ihn als Überschrift zu kennzeichnen. Diese Texte sind direkt lesbar und werden in Systemen wie Github als schön formatierte Webseiten angezeigt.
• Speicherung der Dokumente in Git (mit entsprechenden Branches)
  Der Autor commited seine Änderungen oder sein neues Dokument auf einen Entwicklungs-Branch. Sobald er freigegeben wird, werden die Änderungen auf den Master-Branch „gemerged“. Wenn wir an Kunden-Dokumenten arbeiten, erzeugen wir eigene Branches.
• Erzeugen von Word-Dokumenten
  Weil viele lieber mit Word arbeiten: Jeder Commit triggert einen Build-Prozess, der automatisch ein Word-Dokument erzeugt. Diese Word-Dokumente werden beim Build automatisch versioniert und im Versionsverwaltungssystem (Git) gespeichert.
• Arbeiten mit den Word-Dokumenten
  Optional können Anwender diese Dokumente mit ihrem Rechner synchronisieren.

Man kann auch auf die Generierung von Word-Dokumenten verzichten.

5.2.2 Bewertung

Vorteile

• Klarer, transparenter Workflow
• Einfaches Nachvollziehen von Änderungen über die Git-Bordmittel (das ist bei Word aufwändig und nur über die Vergleichsfunktion möglich)
• Einheitliches Dokumentenlayout. Durch ein Anpassen des Templates erhalten alle Dokumente ein einheitliches bzw. neues Layout.
• Arbeiten mit mehreren Versionen parallel: Wir können Verbesserungen, die wir für einen Kunden erarbeitet haben, einfach in unseren Master-Branch zurückmergen.
• Die Dokumente stehen den Anwendern im gewohnten Word-Format zur Verfügung.
• Eine Konvertierung in PDF, LaTeX, HTML usw. ist „built-in“.

Nachteile

• Das System aus Git, Pandoc und Jenkins (einschließlich Build-Skript) muss aufgesetzt und eine entsprechende Tool-Landschaft gepflegt werden.
• Das Erstellen und Ändern von Dokumenten bedarf Kenntnissen, die über die Bedienung von Word hinausgehen.
• Die Markdown-Sprache erlaubt nur eingeschränkte Anpassungen im Layout (obwohl sogar das Ausrichten von Text in Tabellen, Listen in Listen, Fußzeilen usw. möglich sind).

6. Ausblick

Die Dokumentenlenkung und die Anforderungen daran verstehen viele Organisationen noch sehr wörtlich, nämlich als die Lenkung von Dokumenten auf Papier oder als Dateien, z. B. als PDF. Die meisten Behörden und Benannten Stellen fordern solche Dokumente.

Dokumentenorientierte Ansätze sind jedoch ein Konzept der Vergangenheit. Moderne Unternehmen steigen von dokumentengetriebenen Prozessen auf datengetriebene Prozesse um. Dadurch erreichen sie:

• höhere Konformität (z. B. durch automatisierte Prüfungen),
• geringere Arbeitsbelastung (z. B. durch die Automatisierung der Erstellung und Prüfung der Inhalte)
• schnellere Time-to-market und damit auch
• höhere Wettbewerbsfähigkeit.

Die normativen Anforderungen an die Dokumentenlenkung bleiben allerdings bestehen, etwa die Transparenz über den (Freigabe-) Status der Informationen oder den Schutz vor Verlust der Informationen.

7. Zusammenfassung

Ohne eine präzise Dokumentenlenkung haben Organisationen wenig Chancen, ein Audit erfolgreich zu bestehen. Sie schaffen nicht nur unnötige regulatorische Risiken, sondern erhöhen auch die Wahrscheinlichkeit, dass ihre Produkte und Dienstleistungen nicht konform sind und Patienten gefährden.

Eine sorgfältig zusammengestellte Tool-Chain hilft, den „Overhead“ bei der Dokumentenlenkung zu minimieren. So können Sie sicherstellen, dass die richtigen Personen zum richtigen Zeitpunkt über die richtigen Informationen verfügen und diese auch verstehen.

Die Zukunft der Dokumentenlenkung ist die Lenkung von strukturierten Informationen und nicht mehr von Dokumenten. Darauf sollten sich Hersteller einstellen und ihre eigene digitale Transformation vorantreiben.

---

Änderungshistorie

• 2024-07-29: Im Kapitel 3 Link auf den überarbeiteten Artikel zu den elektronischen Unterschriften eingefügt.
• 2024-05-02: Einleitungstext geändert, 1. Kapitel eingefügt, andere Kapitel neu nummeriert, Abb. 2 neu gestaltet, bei 5. Kapitel die Struktur angepasst, 6. Kapitel sowie letzten Satz eingefügt
• 2019-03-20: Erste Version erstellt