Datenintegrität an Schnittstellen: Wann reicht eine technisch korrekte Übertragung nicht aus?

EU-GMP Annex 11 enthält in seiner Validierungssektion einen auffälligen Satz. Werden Daten in ein anderes Datenformat oder System übertragen, soll die Validierung Prüfungen einschließen, dass die Daten während dieser Migration nicht in „value and/or meaning" verändert werden. Für kritische Systeme verlangt Annex 11 außerdem eine aktuelle Systembeschreibung, die Datenflüsse und Schnittstellen zu anderen Systemen oder Prozessen erfasst. Wo computergestützte Systeme Daten elektronisch austauschen, sollen geeignete eingebaute Prüfungen die korrekte und sichere Eingabe und Verarbeitung unterstützen.

Der Zusatz „and/or meaning" ist bemerkenswert. Ein Transfer kann technisch sauber aussehen: Ein System übermittelt einen Gewichtswert an ein anderes. Wert, Einheit und Zuordnung kommen so an, wie sie für die Übertragung vorgesehen wurden. Das Zielsystem bestätigt den erfolgreichen Transfer.

Dort soll mit dieser Information aber etwas geschehen. Ein nachgelagerter Prozess muss sie zuordnen, prüfen, bewerten oder weiterverarbeiten. Damit entsteht eine zweite Frage: Reicht das, was angekommen ist, auch für genau diese Tätigkeit?

Dieser Beitrag bezieht sich auf die von der Europäischen Kommission weiterhin in EudraLex Volume 4 geführte Fassung des Annex 11 von Januar 2011. Annex 11 ist keine eigenständige EU-Rechtsnorm. § 2 Nr. 3 AMWHV definiert den EU-GMP-Leitfaden einschließlich seiner Anhänge; das Bundesministerium für Gesundheit hat Anhang 11 hierzu mit Bekanntmachung vom 8. August 2011 (BAnz Nr. 125, S. 2901–2906) in deutscher Sprache veröffentlicht. Eine Überarbeitung wurde 2025 zur Konsultation gestellt; sie wird hier nicht als aktuelle Fassung des Annex 11 behandelt.

An dieser Stelle wäre es falsch, technische Übertragungstreue kleinzureden. Wenn eine Schnittstelle die vereinbarten Daten korrekt und vollständig entsprechend ihrer Spezifikation überträgt, kann die technische Aussage „Transfer erfolgreich" vollkommen richtig sein.

Das ist keine bloße IT-Perspektive, die anschließend durch eine vermeintlich höhere Quality-Perspektive ersetzt werden müsste. Annex 11 selbst verlangt bei elektronischem Datenaustausch geeignete Kontrollen für die korrekte und sichere Eingabe und Verarbeitung von Daten. Technische Richtigkeit ist also Teil der regulatorischen Kontrolle.

Nur beantwortet sie nicht jede Frage, die nach dem Übergang entsteht.

Ein korrekt übertragener Gewichtswert kann im Zielsystem exakt derselbe sein wie im Ursprung. Ob der empfangende Prozess damit seine GMP-relevante Tätigkeit zuverlässig ausführen kann, kann zusätzlich davon abhängen, zu welchem Material, welcher Charge, welchem Zeitpunkt, welchem Status oder welchem Prozessschritt dieser Wert gehört. Welche dieser Informationen erforderlich sind, lässt sich nicht abstrakt beantworten. Es hängt davon ab, was der nachgelagerte Prozess mit dem Wert tun soll.

Damit verändert sich der Betrachtungsmaßstab. Nicht möglichst viele Informationen müssen über jede Systemgrenze bewegt werden. Aber diejenigen Informationen, die für die vorgesehene Tätigkeit auf der anderen Seite benötigt werden, müssen dort in einer Form verfügbar sein, die diese Tätigkeit trägt.

„Vollständig" klingt zunächst wie eine Eigenschaft eines Datensatzes. Entweder alles ist vorhanden oder etwas fehlt.

An einer Systemgrenze ist diese Vorstellung zu einfach.

Ein Datensatz kann für eine Tätigkeit ausreichend und für eine andere unzureichend sein. Ein Ergebnis, das für eine reine Anzeige genügt, muss nicht dieselbe Informationsgrundlage bieten wie für einen fachlichen Review. Ein Status, der für eine Übersicht ausreicht, muss nicht alle Informationen enthalten, die für seine weitere Verarbeitung oder Bewertung benötigt werden.

Für die folgende Analyse lässt sich daraus eine Unterscheidung ableiten: Die Gleichwertigkeit von Informationen wird nicht abstrakt zwischen zwei Systemen, Datenträgern oder Darstellungen beurteilt. Sie wird im Verhältnis zu einer bestimmten nachgelagerten Tätigkeit beurteilt.

„Gleichwertig" bedeutet hier deshalb nicht: technisch identisch. Es bedeutet auch nicht, dass sämtliche Daten und Metadaten des Ursprungssystems im Ziel dupliziert werden müssen. Gemeint ist enger, ob die nach dem Übergang verfügbare Information für die konkrete weitere Tätigkeit eine ebenso belastbare Informationsgrundlage bietet wie das, was auf der abgebenden Seite verfügbar war.

Ob eine statische Darstellung einen elektronischen Originalrecord regulatorisch ersetzen kann, betrifft zugleich den Erhalt und die Herkunft von Daten. Hier interessiert eine andere Seite desselben Übergangs: Welche Informationsgrundlage benötigt die Tätigkeit, die anschließend mit der Zielinformation durchgeführt werden soll?

Diese Unterscheidung wird besonders wichtig, wenn die Information im Ziel nicht nur zusätzlich angezeigt wird, sondern praktisch an die Stelle dessen tritt, was im Ursprung verfügbar ist.

Ein Dashboard kann bewusst eine Zusammenfassung sein, ohne sämtliche zugrunde liegenden Records ersetzen zu sollen. Ein Ausdruck kann einen Wert dokumentieren, ohne als vollständige Grundlage eines elektronischen Datenreviews gedacht zu sein. Ein übertragener Status kann für einen bestimmten Schritt im ERP genügen, während für eine andere Tätigkeit weiterhin der Zugriff auf Informationen im Ursprungssystem erforderlich bleibt.

Das Problem entsteht deshalb nicht schon dadurch, dass Informationen verdichtet, übertragen oder in einer anderen Darstellung gezeigt werden.

Die entscheidende Frage lautet vielmehr: Für welche Tätigkeit wird die Zielinformation anschließend verwendet – und wird sie dabei so behandelt, als könne sie die im Ursprung verfügbare Informationsgrundlage für genau diese Tätigkeit ersetzen?

Eine solche Gleichwertigkeit kann bewusst festgelegt und geprüft worden sein. Sie kann aber auch stillschweigend im Arbeitsablauf entstehen: weil ein bestimmter Export traditionell als Review-Paket dient, weil ein Status in einem Folgesystem als maßgeblich behandelt wird oder weil eine Schnittstelle genau diejenigen Felder überträgt, die seit ihrer Einführung vorgesehen sind.

Damit wird die Grenze fachlich interessant. Nicht weil dort zwangsläufig etwas verloren geht, sondern weil dort festgelegt wird, welche Form von Information für die nächste Tätigkeit genügen soll.

Das ist der stärkste Einwand gegen diese Betrachtung.

Eine Schnittstelle kann nur das zuverlässig übertragen, was als Anforderung definiert wurde. Fehlt im Ziel eine für den Prozess notwendige Information, liegt es nahe zu sagen: Dann war die Spezifikation unvollständig. User Requirements, Datenmapping und Validierung müssen den Bedarf eben richtig abbilden.

Der Einwand ist berechtigt.

Annex 11 verlangt, dass User Requirements die erforderlichen Funktionen des computergestützten Systems beschreiben, auf dokumentierter Risikobewertung und GMP-Impact beruhen und über den Lebenszyklus rückverfolgbar bleiben. Für kritische Systeme sollen zudem Datenflüsse und Interfaces beschrieben werden. Eine fachlich unvollständige Anforderung wird nicht dadurch richtig, dass sie technisch fehlerfrei umgesetzt wird.

Aber damit ist nur die erste Hälfte beschrieben.

Auch wenn exakt das Spezifizierte übertragen wird, bleibt zu klären, welche Rolle die Zielinformation im tatsächlichen Prozess übernimmt. Dient sie nur der Anzeige? Ist sie eine Zusammenfassung? Wird für den anschließenden Review zusätzlich das Ursprungssystem geöffnet? Oder wird die Zielinformation praktisch als vollständige Grundlage der Tätigkeit behandelt?

Die Frage lautet deshalb nicht nur, ob der Informationsbedarf korrekt in Felder und Übertragungsregeln übersetzt wurde.

Sie lautet auch: Ist fachlich begründet, dass das, was danach vorliegt, für die konkrete Tätigkeit tatsächlich an die Stelle der zuvor verfügbaren Informationsgrundlage treten kann?

Das ist keine zusätzliche technische Fehlerklasse. Es ist eine Frage an die Beziehung zwischen abgebendem Prozess, Übergang und empfangender Tätigkeit.

Ein FDA-Warning-Letter an IDT Australia Ltd. aus dem Jahr 2018 zeigt, wie praktisch diese Unterscheidung werden kann.

Bei einer Inspektion im Dezember 2017 überprüfte die FDA elektronische HPLC-Daten und fand mindestens 100 als „test" bezeichnete Injections. Die analytischen Verfahren und Methoden des Unternehmens behandelten solche „test" injections nicht. Nach der gegenüber dem Investigator beschriebenen Praxis prüften Labor-Supervisoren und Quality Unit nur diejenigen Chromatogramme, die Analysten ausgedruckt und ihnen vorgelegt hatten. Weil die Ergebnisse der „test" injections nicht ausgedruckt wurden, wurden sie von Supervisoren und Quality Unit nicht überprüft. Das Verfahren verlangte auch keinen Review der zugrunde liegenden elektronischen Records oder Daten auf Genauigkeit und Vollständigkeit. FDA hielt anschließend fest, dass die Quality Unit bei Batch-Disposition-Entscheidungen auf unvollständige Daten vertraute.

Ein FDA Warning Letter ist eine veröffentlichte, informelle Behördenposition; FDA betrachtet Warning Letters nicht als final agency action. Das Verfahren gegen IDT wurde im August 2019 mit einem Close-Out Letter abgeschlossen.

Der Warning Letter enthält daneben weitere erhebliche Befunde zur Vollständigkeit und Integrität von Qualitätsdaten, darunter nicht an die Quality Unit weitergegebene fehlgeschlagene Identitätsprüfungen und unvollständige mikrobiologische Records. FDA verlangte deshalb eine umfassende Data-Integrity-Aufarbeitung. Einen kausalen Zusammenhang zwischen diesen weiteren Befunden und der hier betrachteten HPLC-Review-Praxis stellt der Warning Letter jedoch nicht her.

Nicht entscheidend ist, welche einzelnen Injections für eine konkrete Chargenentscheidung hätten gewürdigt werden müssen. Das würde die Frage öffnen, welche Informationen einer Quality-Entscheidung zugrunde liegen müssen.

Hier interessiert der Schritt davor.

Elektronisch war eine breitere Informationsgrundlage vorhanden als in dem Material, auf dessen Grundlage der nachgelagerte Review tatsächlich stattfand.

Für die Kategorie der „test" injections enthielten die beschriebenen analytischen Verfahren selbst keine Regelung. Damit wird eine zweite Seite der Systemgrenze sichtbar: Eine nachgelagerte Tätigkeit kann eine Information nur dann kontrolliert berücksichtigen, wenn nicht nur die erforderlichen Daten verfügbar sind, sondern auch bestimmt ist, welche Rolle diese Informationen in der Tätigkeit spielen.

Der IDT-Befund erklärt nicht, was Annex 11 unter „meaning" versteht. Er beweist auch nicht, dass ein Ausdruck generell ungeeignet wäre. Er zeigt einen realen betrieblichen Sachverhalt, an dem die zuvor entwickelte Frage konkret wird: Eine Darstellung wird für eine Tätigkeit verwendet, obwohl im Ursprung zusätzliche Informationen vorhanden sind, die für diese Tätigkeit relevant sein können.

Damit braucht auch hier jede Aussage über Gleichwertigkeit ein Wofür.

Eine kontrollierte Systemgrenze muss deshalb nicht möglichst viele Daten bewegen. Ein vollständiger technischer Spiegel des Ursprungssystems wäre häufig weder erforderlich noch sinnvoll.

Ihre Aufgabe lässt sich anders beschreiben.

Zunächst muss klar sein, welche Tätigkeit auf der empfangenden Seite stattfindet. Erst daraus lässt sich bestimmen, welche Informationen diese Tätigkeit benötigt. Danach kann festgelegt werden, was über die Grenze übertragen werden muss, welche Information gegebenenfalls weiterhin im Ursprung einzusehen ist und welche Darstellung lediglich als Referenz oder Zusammenfassung dienen soll.

Dazu gehört auch, dass im empfangenden Verfahren bestimmt ist, wie die betreffende Information in dieser Tätigkeit berücksichtigt wird. Eine Information kann kaum als gleichwertige Grundlage für eine Tätigkeit beurteilt werden, wenn ihre Rolle innerhalb dieser Tätigkeit selbst nicht festgelegt ist.

Für die betriebliche Analyse sind damit vier Beziehungen relevant: Was ist im Ursprung für die betreffende Information verfügbar? Was kommt nach dem Übergang tatsächlich im Ziel an? Welche Tätigkeit wird dort damit ausgeführt? Und ist begründet, dass die Zielinformation für genau diese Tätigkeit eine gleichwertige Grundlage bildet – oder benötigt der Prozess zusätzlich Informationen aus dem Ursprung?

Das ist keine Forderung, jede Schnittstelle mit sämtlichen Metadaten des Quellsystems zu überladen. Ebenso wenig folgt daraus, dass statische Darstellungen, Exporte oder Zusammenfassungen regulatorisch minderwertig wären. Ihre Eignung hängt davon ab, welche Rolle sie im nachgelagerten Prozess tatsächlich übernehmen.

Darin liegt die positive Aufgabe einer kontrollierten Grenze: Sie macht nicht nur die Übertragung zuverlässig. Sie macht auch bewusst, welche Informationsform auf der anderen Seite für welche Tätigkeit verwendet werden kann.

Annex 11 bietet dafür mehrere regulatorische Anknüpfungspunkte. Die Beschreibung kritischer Systeme soll Datenflüsse und Interfaces zu anderen Systemen oder Prozessen erfassen. Beim elektronischen Datenaustausch sollen eingebaute Prüfungen die korrekte und sichere Eingabe und Verarbeitung unterstützen. Und für die Übertragung in ein anderes Format oder System verlangt Nr. 4.8 im Rahmen der Validierung Prüfungen darauf, dass Daten während der Migration nicht in Wert und/oder Bedeutung verändert werden.

Diese Vorgaben formulieren keine eigene Theorie der „Gleichwertigkeit für eine Tätigkeit". Die Relation zwischen Ursprung, Ziel und nachgelagerter Verwendung ist die analytische Perspektive dieses Beitrags.

In den für diesen Beitrag ausgewerteten veröffentlichten FDA-Befunden lässt sich die hier untersuchte Frage besonders detailliert bei elektronischen analytischen Daten beobachten. Daraus folgt nicht, dass Systemgrenzen dort häufiger problematisch wären. Die veröffentlichten Befunde geben dort lediglich einen ungewöhnlich tiefen Einblick in elektronische Quelldaten, Ausdrucke, Review-Pakete und nachgelagerte Prüfungen.

In anderen Warning Lettern fordert FDA im Rahmen der Sanierung beispielsweise technologische Verbesserungen, um elektronische Daten aus Stand-alone-Geräten wie Waagen, pH-Metern oder Wassergehaltsprüfungen stärker in LIMS-Netzwerke zu integrieren. Solche Forderungen finden sich unter anderem bei Stason Pharmaceuticals und Jost Chemical. Die Schreiben liefern jedoch keinen vergleichbar sauberen Einzelfall, in dem eine ansonsten technisch korrekte Systemübergabe gerade wegen einer für die empfangende Tätigkeit unzureichenden Informationsgrundlage beanstandet wird.

Das ist eine Grenze der veröffentlichten Behördenpraxis – keine Aussage darüber, wie häufig solche Konstellationen in pharmazeutischen Betrieben auftreten.

Am Anfang stand eine kleine sprachliche Besonderheit. Annex 11 spricht bei der Übertragung von Daten nicht nur von ihrem Wert, sondern von „value and/or meaning".

Für die betriebliche Praxis muss daraus keine abstrakte Definition von „meaning" entstehen.

Nützlicher ist die Frage, die nach einem erfolgreichen Transfer übrig bleibt.

Der Wert kann stimmen. Die vorgesehenen Felder können korrekt übertragen worden sein. Das Zielsystem kann technisch fehlerfrei arbeiten.

Dann beginnt die nächste Tätigkeit.

Und erst für sie entscheidet sich, ob das Angekommene tatsächlich genügt.

Eine Systemgrenze ist deshalb nicht allein dort kontrolliert, wo sich nachweisen lässt, dass das Vorgesehene richtig übertragen wurde. Ebenso wichtig ist, ob begründet ist, dass die auf der anderen Seite verfügbare Information für das, was dort als Nächstes geschehen soll, eine gleichwertige Informationsgrundlage bildet.