Datenherkunft und Entstehungskontext
Data Provenance: Herkunft und Entstehung von Daten nachvollziehen
Ein Zwischenprodukt liegt vor. Welche Verarbeitung hat es erzeugt, welches Material ging ein und wer war beteiligt? Diese Fragen führen zurück zum Entstehungsvorgang.
Kurzdefinition: Data Provenance dokumentiert den Herkunfts-, Erzeugungs- und Verantwortungszusammenhang von Daten. Dadurch wird aus einem isolierten Wert ein nachvollziehbarer Bestandteil eines betrieblichen Prozesses.
Eine Quellenangabe ist noch keine Entstehungsgeschichte
Die Nennung eines Geräts sagt noch nicht, welcher Messvorgang einen angezeigten Wert erzeugte. Für eine Untersuchung braucht es die Verbindung zwischen Quelle, konkreter Tätigkeit und Ergebnis. W3C PROV stellt dafür ein Modell aus Entitäten, Aktivitäten und Akteuren bereit.[1]
Welche Angaben den Entstehungsvorgang erschließen
Eine Kennung am Zwischenprodukt verweist zunächst auf das Produkt selbst. Für seine Herkunft wird eine andere Verbindung benötigt: der Verarbeitungsvorgang mit seinen Eingaben und dem erzeugten Ergebnis. Das spätere Chargenbeispiel benennt diese Elemente getrennt.
Die FDA beschreibt Metadaten als Informationen, die zum Verständnis von Daten benötigt werden, darunter Zeit-, Nutzer- und Gerätebezüge.[6] Ein Herkunftsmodell ordnet solche Angaben dem Entstehungsvorgang zu. Dadurch bleibt etwa eine Aufzeichnung über die Herstellung von einer späteren Prüfung derselben Aufzeichnung unterscheidbar.
Das Grundmodell von W3C PROV
Das World Wide Web Consortium hat mit der PROV-Familie ein domänenunabhängiges Modell für die Darstellung und den Austausch von Provenance-Informationen veröffentlicht. Das konzeptionelle Datenmodell PROV-DM unterscheidet drei besonders grundlegende Kategorien: Entity, Activity und Agent.[1]
Das verwendete, erzeugte oder betrachtete physische, digitale oder konzeptionelle Objekt.
Der Vorgang, der Entitäten verwendet, erzeugt oder in einen neuen Zustand überführt.
Die Person, Organisation oder das System mit einem Beteiligungs- oder Verantwortungsbezug.
Entity: das verwendete oder erzeugte Objekt
Bei einem Verarbeitungsvorgang können Ausgangsmaterial und Zwischenprodukt als Entitäten modelliert werden. Auch eine SOP-Fassung oder ein Analyseergebnis kann eine eigene Entität sein. Unterschiedliche Zustände derselben Sache lassen sich dabei gesondert betrachten.[2]
Activity: der Vorgang, der etwas verwendet oder verändert
Verarbeitung, Nacharbeit und Prüfung sind unterschiedliche Aktivitäten. Die Unterscheidung erlaubt es, ihre jeweiligen Eingaben und Ergebnisse getrennt zuzuordnen, auch wenn sie dieselbe Charge betreffen.
Agent: die verantwortungsbezogene Beteiligung
Eine ausführende Person, eine prüfende Organisation oder ein beteiligtes Softwaresystem kann als Agent auftreten. Die Zuordnung beschreibt den modellierten Verantwortungsbezug; sie legt keine rechtliche Zuständigkeit fest.[1]
Beziehungen machen Provenance verständlich
Der eigentliche Informationswert entsteht durch die Beziehungen zwischen diesen Elementen. Eine Aktivität kann eine Entity verwenden und eine andere erzeugen. Sie kann einem Agenten zugeordnet sein. Eine Entity kann aus einer früheren Entity abgeleitet worden sein.
Das W3C-Modell ist ausdrücklich domänenunabhängig und kann um fachspezifische Informationen erweitert werden.[1] Es schreibt einem Betrieb daher nicht vor, welche konkreten Chargen-, Prüf- oder Freigabedaten er erfassen muss.
Mit PROV-O stellt das W3C außerdem eine Ontologie bereit, durch die sich Provenance-Informationen maschinenlesbar repräsentieren und zwischen unterschiedlichen Anwendungen austauschen lassen.[3]
Ausgangsmaterial, Verarbeitung und Ergebnis auseinanderhalten
Ein fiktiver Verarbeitungsvorgang V-07 verwendet Material M-12 und erzeugt Zwischenprodukt Z-04. M-12 und Z-04 sind im Modell Entitäten, V-07 ist die Aktivität. Person P-03 ist ihr als Agent zugeordnet.
„V-07 verwendet M-12“ bezeichnet die Nutzung, „V-07 erzeugt Z-04“ die Erzeugung. Die Ableitungsbeziehung zwischen Z-04 und M-12 hält den Zusammenhang von Ergebnis und Ausgangsmaterial fest. Bei der Zuordnung eines Agenten zur Aktivität kann PROV außerdem einen Plan angeben: die vorgesehenen Schritte, auf die sich der Agent dabei stützt – hier beispielsweise die geltende SOP-Version.[1]
Wird Z-04 nachgearbeitet, kommt eine weitere Aktivität hinzu. Deren Ergebnis erhält einen unterscheidbaren Bezug. Die erste Verarbeitung bleibt Teil der Vorgeschichte; die Nacharbeit ersetzt sie nicht. Welche Mengen und Eigenschaften dafür dokumentiert werden müssen, hängt von der fachlichen Fragestellung ab.
Eine nachträgliche Prüfung ist ebenfalls ein eigener Vorgang. Sie kann die Aufzeichnungen bewerten, ist aber nicht die Aktivität, die das Material hergestellt hat. Genau diese Trennung verhindert, dass „hergestellt“, „dokumentiert“ und „geprüft“ im Modell zu einer einzigen unklaren Beziehung werden.
Beziehungen erfassen oder später rekonstruieren
Beim Ausführen von V-07 können die Kennungen des eingesetzten Materials und des entstehenden Zwischenprodukts unmittelbar verbunden werden. Diese prozessnahe Erfassung verringert den späteren Zuordnungsaufwand. Ihre Richtigkeit hängt dennoch davon ab, ob tatsächlich das verwendete Material und der richtige Vorgang erfasst wurden.
Wird der Zusammenhang erst aus Berichten, Zeitstempeln oder Dateinamen erschlossen, sollte er als Rekonstruktion erkennbar bleiben. Eine vermutete Beziehung ist nicht gleichwertig mit einer eindeutig belegten Zuordnung. Erfassungsquelle, Unsicherheit und spätere Berichtigung gehören deshalb zur Bewertung eines Provenance-Modells.
Auch ein während der Arbeit erfasstes Modell kann Lücken haben. Seine Abdeckung ist anhand des konkreten Zwecks zu beurteilen: Ein Materialbezug kann ausreichen, um den eingesetzten Ausgangsstoff zu finden, aber nicht, um eine bestimmte Messmethode zu belegen.
Auch ein Analyseergebnis hat eine Vorgeschichte
Wird aus den Aufzeichnungen eine Kennzahl berechnet, entsteht ein weiteres Ergebnis mit eigenen Eingaben und Verarbeitungsschritten. Seine Herkunft ist von der Herkunft des untersuchten Produkts zu unterscheiden. Eine spätere Änderung einer Eingabe kann Anlass geben, die Kennzahl erneut zu prüfen.
Für Process Mining ist nachvollziehbar zu halten, welcher Ereignisbestand in die Analyse einging und wie er vorbereitet wurde. Provenance unterstützt diese Erklärung. Sie belegt weder eine Ursache für beobachtete Unterschiede noch automatisch die Eignung eines Analyseverfahrens.
Data Provenance und benachbarte Begriffe
Die Begriffe werden häufig nebeneinander verwendet, beantworten aber unterschiedliche Fragen.
| Begriff | Zentrale Frage | Schwerpunkt |
|---|---|---|
| Data Provenance | Woher stammt ein Datum, wie ist es entstanden und wer oder was war daran beteiligt? | Entstehungs-, Ableitungs- und Verantwortungszusammenhang |
| Data Lineage | Welchen Weg nahm ein Datum durch Quellen, Systeme und Transformationen? | Datenfluss und Verarbeitungskette |
| Audit Trail | Welche Handlungen, Eingaben und Änderungen wurden protokolliert? | Zeitlich nachvollziehbare Ereignis- und Änderungshistorie |
| Datenintegrität | Sind Daten über ihren Lebenszyklus vollständig, konsistent, korrekt und verlässlich? | Qualitäts- und Vertrauenseigenschaften von Daten |
| Event Sourcing | Wie wird der Zustand einer Anwendung aus gespeicherten Ereignissen gebildet? | Architekturprinzip für Zustände und Zustandsänderungen |
Die Bereiche können sich überschneiden. Ein Audit Trail kann wichtige Provenance-Informationen enthalten. Eine Data Lineage kann Ableitungen und Transformationen sichtbar machen. Ein ereignisbasiertes System kann den Aufbau eines Provenance-Modells erleichtern. Keiner dieser Begriffe ist jedoch ohne Weiteres mit Data Provenance gleichzusetzen.
Besonders wichtig ist die Abgrenzung zur Datenintegrität. Provenance kann helfen, Herkunft und Verarbeitung eines Datums zu beurteilen. Sie garantiert aber nicht, dass die ursprüngliche Beobachtung sachlich richtig war oder dass sämtliche erforderlichen Kontrollen eingehalten wurden.
Bedeutung für regulierte Prozessdaten
Regulatorische Anforderungen unterscheiden sich nach Branche, Produkt und konkretem Anwendungsfall. Dennoch zeigen Leitlinien für GxP-regulierte Umgebungen, welche Bedeutung dem Datenkontext und dem gesamten Datenlebenszyklus zukommt.
PIC/S beschreibt den Datenlebenszyklus als Zusammenhang von Erzeugung, Verarbeitung, Berichterstattung, Prüfung, Entscheidungsnutzung, Speicherung und späterer Löschung.[4] Die MHRA betont, dass Daten während ihres Lebenszyklus unter anderem zuordenbar, zeitnah, vollständig und konsistent bleiben sollen.[5] Die FDA hebt ebenfalls hervor, dass Systemgestaltung und Kontrollen Fehler, Auslassungen und auffällige Ergebnisse über den Datenlebenszyklus erkennbar machen sollen.[6]
Diese Behördenquellen definieren kein allgemeines, branchenübergreifend verpflichtendes Provenance-System. Sie verdeutlichen aber, weshalb isolierte Werte und bloße Abschlussdokumente in kontrollierten Prozessen häufig nicht ausreichen: Entscheidungen müssen im Zusammenhang der zugrunde liegenden Daten und Aufzeichnungen beurteilt werden können.
Data Provenance kann diesen Zusammenhang technisch strukturieren. Welche Informationen tatsächlich erforderlich sind, muss sich aus dem jeweiligen Prozess, Risiko und Regelungsrahmen ergeben.
Herkunft an der ausgeführten Aufgabe festhalten
Bei 420+ verbindet die ausgeführte Aufgabe das verwendete Material und die geltende SOP-Fassung mit den neu erfassten Ergebnissen und der handelnden Person in ihrer Rolle. Für einen Verarbeitungsschritt heißt das: Das Ergebnis verweist auf seine Ausführung, die Ausführung auf ihre Eingaben und Beteiligten.
Der Vorteil dieser Zuordnung liegt beim späteren Rückweg. Wer ein Ergebnis untersucht, kann von dort zur betreffenden Aufgabe und ihren Grundlagen gelangen. Welche Beziehungen tatsächlich erfasst sind, bestimmt den erreichbaren Ausschnitt; fehlende Zuordnungen bleiben als Lücken erkennbar.
In der Ledger-Architektur ergänzen neue Einträge die bestehende Historie, sodass frühere Bezüge nachvollziehbar bleiben. Ein standardisierter PROV-Export ist davon eine getrennte Frage.
Was Data Provenance nicht leistet
- Provenance garantiert nicht die Wahrheit einer Eingabe. Eine nachvollziehbar erfasste Messung kann dennoch fehlerhaft sein.
- Ein umfangreiches Log ist nicht automatisch ein Provenance-Modell. Ereignisse müssen in ihrem fachlichen Zusammenhang interpretierbar sein.
- Provenance und Unveränderbarkeit sind unterschiedliche Eigenschaften. Herkunftsbeziehungen können dargestellt werden, ohne dass ihre technische Manipulationssicherheit damit bewiesen wäre.
- Mehr Daten sind nicht automatisch bessere Daten. Erfassungsumfang und Granularität müssen zum Zweck, Risiko und tatsächlichen Prozess passen.
- Ein Modell schafft noch keine Interoperabilität. Gemeinsame Begriffe, Identifikatoren und Austauschformate müssen auch praktisch konsistent umgesetzt werden.
Aufsichtsbefund
Befund: Die FDA beanstandete bei einem Wirkstoffhersteller, dass Ergebnisse eines Auftragslabors auf Analysenzertifikaten mit eigenem Firmenbriefkopf wiedergegeben wurden, ohne das Labor zu benennen, das die ursprüngliche Analyse durchgeführt hatte.[7]
Einordnung: Der Aussteller eines Zertifikats und der Erzeuger eines Prüfergebnisses können verschiedene Organisationen sein. Für die Provenienz müssen beide Bezüge unterscheidbar bleiben. Der Befund betrifft die Herkunftsangabe; daraus wird hier keine Fälschung abgeleitet. Er stammt aus der Wirkstoff-CGMP und schreibt kein bestimmtes Provenienzmodell vor.
Prüffrage: Ist zu jedem übernommenen Prüfergebnis das tatsächlich analysierende Labor erkennbar, getrennt vom Aussteller des Zertifikats?
Schreiben vom 18.08.2026 · Quelle geprüft am 18.09.2026.
Dargestellt ist der ausgewählte Behördenbefund zum Zeitpunkt des Schreibens. Unternehmensantworten und spätere Entwicklungen werden hier nicht bewertet; die Darstellung beschreibt keinen aktuellen Compliance-Status.
Die Herkunftsfrage bestimmt den erforderlichen Ausschnitt
Für Z-04 lässt sich nun gezielt fragen: Welches Material ging ein? Welcher Vorgang erzeugte es? Welche weitere Bearbeitung folgte? Diese Fragen benötigen unterscheidbare Objekte und eindeutige Beziehungen, nicht die größtmögliche Liste an Kontextfeldern.
Ein gutes Provenance-Modell zeigt zugleich, wo seine Auskunft endet. Ist die Materialverwendung erfasst, aber die Messmethode nur vermutet, muss dieser Unterschied erhalten bleiben. So wird Herkunft zu einer prüfbaren Erklärung.
Primärquellen und weiterführende Literatur
- World Wide Web Consortium (W3C), PROV-DM: The PROV Data Model, W3C Recommendation vom 30. April 2013, insbesondere Abstract sowie Abschnitte 2 und 5. Originalquelle
- World Wide Web Consortium (W3C), PROV Model Primer, W3C Working Group Note vom 30. April 2013, insbesondere Abschnitte 1 und 2. Originalquelle
- World Wide Web Consortium (W3C), PROV-O: The PROV Ontology, W3C Recommendation vom 30. April 2013. Originalquelle
- Pharmaceutical Inspection Co-operation Scheme (PIC/S), Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments, PI 041-1 vom 1. Juli 2021, insbesondere Abschnitt 5.1.2. Originaldokument
- Medicines and Healthcare products Regulatory Agency (MHRA), GXP Data Integrity Guidance and Definitions, Revision 1, März 2018, insbesondere Abschnitte 3.10, 4 und 6. Originaldokument
- U.S. Food and Drug Administration (FDA), Data Integrity and Compliance With Drug CGMP – Questions and Answers, Guidance for Industry, Dezember 2018, insbesondere Frage 1. Originaldokument
- U.S. Food and Drug Administration (FDA): Warning Letter to Shoolin Pharma Chem LLP, MARCS-CMS 734100, 18.08.2026. Ziffer 2, zweiter Befundabsatz zum ausführenden Auftragslabor. Originalquelle. Abgerufen am 18. September 2026. ↩