Data Provenance: Herkunft und Entstehung von Daten nachvollziehen

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.[[2]] 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. Bei Daten aus mehreren Geräten gehört zur Herkunft außerdem, auf welcher gemeinsamen Zeitbasis ihre Ereignisse vergleichbar werden.

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]

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.[[3]]

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.^[4]

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.

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.^[5] Die MHRA betont, dass Daten während ihres Lebenszyklus unter anderem zuordenbar, zeitnah, vollständig und konsistent bleiben sollen.^[6] Die FDA hebt ebenfalls hervor, dass Systemgestaltung und Kontrollen Fehler, Auslassungen und auffällige Ergebnisse über den Datenlebenszyklus erkennbar machen sollen.^[2]

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.

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 semantische Interoperabilität. Gemeinsame Begriffe, Identifikatoren und Austauschformate müssen auch praktisch konsistent umgesetzt werden.

Ein standardisierter PROV-Export ist davon eine getrennte Frage.

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.