„Labor-Bericht auf Knopfdruck“ …
… das gehört zu den meistgenannten Digitalisierungswünschen in akkreditierten Prüflaboren. Aber wer wirklich verstehen will, warum so viele Ansätze scheitern, muss beim richtigen Ende anfangen – nämlich ganz am Anfang des Prozesses.
Der Wunsch ist berechtigt. Wer je einen Prüfbericht für ein akkreditiertes Labor manuell erstellt hat, kennt den Aufwand: Daten aus verschiedenen Systemen zusammentragen, Normbezüge prüfen, Messunsicherheiten berechnen, Konformitätsaussagen treffen, Freigabeworkflows einhalten, Versionen dokumentieren. Für ein einzelnes Laborprojekt kann das Stunden kosten – Stunden, die nicht in die eigentliche Prüfarbeit fließen.
Die naheliegende Reaktion: ein Tool kaufen, das den Bericht automatisch erstellt. Und hier beginnt das eigentliche Problem.
Was die Norm wirklich verlangt
Wer ISO/IEC 17025:2017 kennt, weiß: Abschnitt 7.8 ist einer der technisch anspruchsvollsten Teile der Norm. Ein Prüfbericht ist kein Dokument, das man befüllt. Er ist das finale, rechtlich belastbare Artefakt eines vollständig rückverfolgbaren Laborprozesses.
Jeder der Pflichtinhalte nach 7.8.2.1 muss aus einem anderen Systembereich stammen: die Verfahrensbezeichnung aus den Stammdaten, das Prüfdatum aus der Auftragsplanung, die Beschreibung und eindeutige Kennzeichnung des Prüfgegenstands aus dem Probenmanagement, die Messunsicherheit aus der Messkette, die Konformitätsaussage mit Entscheidungsregel aus dem vertraglich vereinbarten Bewertungsrahmen, die freigebende Person aus dem Personalmanagement. Ein Berichtsgenerator, der diese Daten nicht vorfindet, kann sie nicht erzeugen – er kann sie nur simulieren. Und das ist normwidrig.
Besonders die Messunsicherheit nach Abschnitt 7.6 wird in der Praxis unterschätzt. Sie ist keine feste Zahl im Stammdatensatz, sondern eine proben-, verfahrens- und kalibrierstatus-sensitive Größe. Ihre korrekte automatische Ermittlung setzt voraus, dass das System weiß, welches Gerät mit welchem aktuellen Kalibrierstatus bei welcher Probe unter welchen Umgebungsbedingungen eingesetzt wurde.
Noch grundlegender ist die mit der Revision von 2017 neu eingeführte Anforderung an die Entscheidungsregel. Die 2005er Fassung kannte diese explizite Anforderung noch nicht. Die aktuelle Norm verlangt in Abschnitt 7.1.3 und 7.8.6, dass die Entscheidungsregel – also die Regel, wie bei einer Konformitätsaussage mit der Messunsicherheit umgegangen wird – dokumentiert sein muss, das Risiko falscher Annahmen und falscher Zurückweisungen berücksichtigen muss, und mit dem Kunden vereinbart werden muss. In den meisten Laborinformationssystemen ist das bis heute ein Freitextfeld, wenn es überhaupt vorhanden ist.
Und schließlich 7.8.1.1: Ergebnisse müssen vor der Herausgabe überprüft und freigegeben werden. Das System muss nicht nur den Bericht erzeugen, es muss einen auditierbaren Freigabeworkflow abbilden – wer hat wann was gesehen, bewertet und freigegeben.
Das eigentliche Problem: Der Startpunkt liegt viel früher
Hier liegt der Denkfehler vieler Digitalisierungsansätze in der Laborbranche. Der Fokus richtet sich auf das Ende des Prozesses – den Bericht – und übersieht, dass dieser Bericht nur dann automatisch entstehen kann, wenn der gesamte Prozess davor sauber strukturiert und digital abgebildet ist.
Ein Forschungsprojekt hat diesen Zusammenhang wissenschaftlich untersucht und in den Realbetrieb zweier deutscher Labore übertragen. Im Projekt LabTwin – einem Konsortium aus dem Fraunhofer-Institut für Angewandte Informationstechnik FIT, dem Lehrstuhl für Wirtschaftsinformatik und Wertorientiertes Prozessmanagement der Universität Bayreuth, der Vogler Engineering GmbH, der RAPA Automotive GmbH & Co. KG und dem Kunststoffinstitut Lüdenscheid – wurde ein digitaler Laborzwilling entwickelt, der das Prüflabor als vollständiges soziotechnisches System abbildet.
Die Ausgangsbefunde der Anforderungsanalyse klingen vertraut: Aufträge kommen per E-Mail, werden in Excel-Listen übertragen, Prüfergebnisse in Word-Dokumente überführt und per Mail verschickt. Mehrfachpflege in parallelen Systemen. Keine durchgängige digitale Datensicht. Wichtige Informationen – Kompetenzen der Mitarbeiter, Zustand der Prüfmittel, Probenherkunft, Entnahmestelle – lagen analog oder in unstrukturierter Form vor.
Die zentrale Erkenntnis des Projekts: Eine ganzheitliche Ende-zu-Ende-Datensicht auf das Prüflabor ist die unabdingbare Voraussetzung für jede Form von Automatisierung – einschließlich der Berichtsgenerierung. Ohne sie fehlt die Grundlage. Mit ihr wird der Bericht zu einem natürlichen Destillat des gesamten Prozesses.
Diese Erkenntnis klingt abstrakt, hat aber sehr konkrete Konsequenzen für die Frage: Wo muss man anfangen?
Was wirklich modelliert werden muss
Die richtige Frage ist nicht „Wie baue ich einen Berichtsgenerator?“ sondern: „Was muss vollständig strukturiert vorliegen, damit ein Bericht entstehen kann?“ Die Antwort umfasst mindestens vier Ebenen.
Das normkonforme Prüfprogramm als Stammdaten. Jede Bestimmung, die ein Labor durchführt, muss als strukturiertes Datenobjekt vorliegen – mit Messgröße und Einheit, Analyt oder Prüfmerkmal, Matrix, Prüfverfahren mit Normbezug, Grenzwerten für die Konformitätsaussage, Planzeiten und Vorgänger-Abhängigkeiten zwischen Prüfschritten. Dieses „Template“ muss einmal normgerecht modelliert werden und steht dann für jeden Auftrag, der darauf basiert, vollständig zur Verfügung. Wer hier spart, zahlt später – bei jedem einzelnen Bericht.
Die vollständige Proben- und Prüflingskette. Ein Prüfbericht muss rückverfolgbar machen, was geprüft wurde. Das bedeutet: nicht nur „Probe X“, sondern die vollständige Kette vom Prüfgegenstand – dem, was der Kunde einschickt – über die Probenentnahme mit Entnahmestelle und Entnahmeverfahren bis zum einzelnen Prüfling mit seiner systemweit eindeutigen ID. Diese Unterscheidung ist für Abschnitt 7.3 und 7.8.2.2 nicht trivial: ob das Labor für die Probenahme verantwortlich war oder ob der Kunde die Prüflinge bereits präpariert geliefert hat, beeinflusst direkt den Inhalt des Berichts.
Die Entscheidungsregel vor der Prüfung. Wer eine Konformitätsaussage im Bericht haben will, muss vor der Prüfung entscheiden, wie mit den Grenzfällen umgegangen wird – den Messungen, bei denen die Messunsicherheit die Grenzlinie schneidet. Diese Entscheidung muss auftragsspezifisch, dokumentiert und unveränderlich mit dem Auftrag verknüpft sein. Ein System, das das erzwingt, verhindert strukturell das in der Praxis weit verbreitete, aber normwidrige Vorgehen, die Entscheidungsregel nachträglich dem Ergebnis anzupassen.
Der auditierbare Freigabeworkflow. Bevor ein Bericht herausgegeben werden darf, muss eine autorisierte Person die Ergebnisse geprüft und freigegeben haben. Das ist kein administrativer Akt, das ist ein Systemzustand – nachweisbar im Audit Trail, mit Personenbezug, Zeitstempel und unveränderlicher Bindung an den freigegebenen Berichtsdatensatz.
Die folgende Grafik zeigt einen Ausschnitt des komplexen Informationsnetzes hinter dem Ergebnis eines Prüfschrittes:
So lösen wir das
Die Erkenntnisse des LabTwin-Projekts sind direkt in die Weiterentwicklung von AUDITTRAILS eingeflossen. Die AUDITTRAILS Networks GmbH war am LabTwin-Konsortium beteiligt und hat die dort entwickelte Architektur eines digitalen Laborzwillings zur Marktreife weiterentwickelt und in das AUDITTRAILS Managementsystem integriert.
Der Ansatz: Das Prüflabor von Anfang an als vollständig modelliertes, normkonformes System abbilden – nicht als Sammlung von Dokumenten und Excel-Listen.
Konkret bedeutet das einen strukturierten Katalog von Prüf- und Untersuchungsanforderungen, der für jeden Prüfschritt Messgröße, Analyt, Matrix, Verfahren mit Normbezug, Grenzwerte und Ressourcenpool hinterlegt – hierarchisch gegliedert in Anforderungsgruppen, Abschnitte und Positionen. Eine mehrstufige Proben- und Prüflingshierarchie, die Prüfgegenstand, Probennahme und Prüfling sauber unterscheidet und jeden Prüfling mit einer systemweit eindeutigen ID versieht. Eine auftragsspezifische Entscheidungsregel, die vor der Prüfung festgelegt und mit dem Auftraggeber vereinbart wird – mit einer visuellen Darstellung der fünf Konformitätsfälle unter Messunsicherheit nach ISO/IEC Guide 98-4, um die Abwägung zwischen falscher Annahme und falscher Zurückweisung greifbar zu machen. Und einen Freigabeworkflow, der erzwingt, dass Ergebnisse von autorisiertem Personal geprüft und freigegeben werden, bevor ein Bericht herausgegeben werden kann.
Der Bericht entsteht dann tatsächlich auf Knopfdruck: Deckblatt, Prüfgegenstände, Proben und Prüflinge, Anforderungen mit Normbezug, Entscheidungsregeln, Ergebnisse mit Konformitätsaussage, Freigabesignatur. Alles aus dem System, nichts von Hand.
Das ist nicht Magie. Das ist konsequente Datenhygiene und Prozessarchitektur – und der Knopfdruck ist das letzte Prozent davon.
AUDITTRAILS ist ein LIMS und QM-System für akkreditierte Prüf- und Kalibrierlaboratorien sowie medizinische Laboratorien nach ISO/IEC 17025 und ISO 15189. Das LabTwin-Forschungsprojekt wurde im Rahmen des Förderprogramms des Freistaates Bayern und des Bundesministeriums für Wirtschaft und Klimaschutz (BMWK) gefördert.
