Systembeschreibung nach Annex 11: Inhalt und Detailtiefe

1. Kritikalität und Zweck vor den Umfang stellen

Annex 11 unterscheidet das Inventar relevanter Systeme von der detaillierten Beschreibung kritischer Systeme. Bewerten Sie daher zunächst, welche Bedeutung das betrachtete System für Produktqualität, Patientensicherheit und Datenintegrität hat. Die Zahl der Benutzer oder die Größe des Servers beantwortet diese Frage nicht.

Die Beschreibung soll anschließend konkrete Entscheidungen unterstützen: Welche Teile betrifft ein Update? Wo kann ein Ergebnis verändert werden? Welche Abhängigkeit fällt bei einer Störung aus? Dafür benötigen Fachbereich, QA und IT eine gemeinsame Vorstellung. Ein Dokument, das nur den Herstellerprospekt wiedergibt, erklärt weder Ihre Konfiguration noch den tatsächlichen Arbeitsablauf.

Quellen: [1] [4]

2. Die Systemgrenze praktisch bestimmen

Benennen Sie den vorgesehenen Einsatz, Standort, relevante Instanzen und den betrachteten Softwarestand. Unterscheiden Sie Produktivnutzung, Testumgebung und historische Lesemöglichkeiten, soweit sie für die Beschreibung wichtig sind. Gemeinsame Dienste dürfen außerhalb der engeren Anwendungsgrenze liegen; ihre Wirkung auf die Anwendung muss dennoch erkennbar bleiben.

Ein Verzeichnisdienst kann beispielsweise die Anmeldung liefern, während die Anwendung selbst entscheidet, welche Rolle Daten ändern darf. Eine zentrale Ablage kann Berichte speichern, ohne die fachliche Freigabe durchzuführen. Solche Unterschiede helfen, Verantwortung richtig zuzuordnen. Eine gezeichnete Grenze ist eine methodische Festlegung und darf reale Einflussmöglichkeiten nicht unsichtbar machen.

Quellen: [1] [3]

3. Physische und logische Sicht verbinden

Die physische Sicht beantwortet, wo Komponenten betrieben werden und wie sie verbunden sind. Die logische Sicht erklärt Dienste, Berechtigungen, Verarbeitung und Datenbeziehungen. Beide können in einer übersichtlichen Darstellung mit ergänzenden Tabellen zusammengeführt werden. Annex 11 verlangt dafür weder ein bestimmtes Zeichenprogramm noch zwingend getrennte Dateien.

Als eigene Auswahlhilfe zeigt die Tabelle, welche Information eine sinnvolle Nachweisfrage vorbereitet. Geheimnisse wie Kennwörter gehören nicht in eine breit verteilte Beschreibung. Sicherheitsrelevante Detailunterlagen können geschützt referenziert werden, solange berechtigte Personen sie im erforderlichen Zusammenhang auffinden und bewerten können.

Quellen: [1] [2]

4. Daten vom Ursprung bis zur Verwendung verfolgen

Beschreiben Sie nicht nur Pfeile zwischen Kästen. Ein Datenfluss sollte Quelle, fachlichen Inhalt, relevante Kennungen und Zielverwendung erklären. Halten Sie fest, wo automatische Verarbeitung erfolgt und wo Menschen Daten übertragen oder Entscheidungen treffen. Auch temporäre Speicherung und manuelle Zwischenschritte können die Nachvollziehbarkeit beeinflussen.

PIC/S PI 041-1 nennt die Betrachtung des Datenflusses als hilfreichen Zugang zu Datenrisiken. Für Ihre Beschreibung lässt sich daraus eine konkrete Frage ableiten: Kann eine andere Person anhand des Dokuments einen ausgewählten Record durch den Prozess verfolgen? Wenn ein Export seine ursprüngliche Kennung verliert, hilft ein technisch korrekt gezeichneter Netzwerkpfad allein nicht weiter.

Quellen: [1] [3]

5. Illustratives Beispiel: Laborstatus erreicht die Materialverwaltung

Angenommen, LAB-P bewertet die Probe P-041 zur Materialcharge M-018. Nach einer vorgesehenen fachlichen Entscheidung sendet es den Statuscode F an ERP-P. Im ausdrücklich konstruierten Sollmodell bedeutet F „zur vorgesehenen Materialverwendung freigegeben“. Es handelt sich nicht um die rechtliche Zertifizierung einer Arzneimittelcharge durch eine sachkundige Person.

Die Beschreibung muss erläutern, wie Probe, Charge und Entscheidung verbunden bleiben und was bei fehlender Zuordnung geschieht. Die Tabelle ist ein ausgefülltes eigenes Sollbeispiel. Sie behauptet keine Funktion eines konkreten Produkts. Ob die dargestellten Kontrollen in Ihrem System funktionieren, wäre gesondert zu prüfen.

Quellen: [1] [3]

6. Sicherheitsmaßnahmen auf ihre Wirkung beziehen

Führen Sie aus, welche Stellen unberechtigte Änderungen, Verlust oder Verwechslungen verhindern beziehungsweise erkennen sollen. Dazu können Rollen, geschützte Speicherung, kontrollierte Konfiguration, Protokollierung und Wiederherstellungsverfahren gehören. Die Beschreibung sollte erkennen lassen, welche Schicht eine Kontrolle trägt und wer sie administriert.

„Zugriff ist geschützt“ bleibt dagegen zu unbestimmt. Prüfen Sie beispielsweise, ob ein Anwendungsbenutzer über einen Dateipfad dieselben Daten verändern könnte, die ihm die Oberfläche nur lesend zeigt. Eine vorhandene Sicherung erklärt wiederum nicht automatisch, welche Daten nach Wiederherstellung zusammenpassen. Beschreiben Sie die relevanten Abhängigkeiten, ohne aus einer Sicherheitsfunktion eine absolute Manipulationssicherheit abzuleiten.

Quellen: [1] [3]

7. Anforderungen, Beschreibung und Tests verknüpfen

Die URS erläutert das fachliche Soll, die Beschreibung den konkreten Aufbau und die Prüfung die beobachtete Erfüllung ausgewählter Kriterien. Diese Zwecke können in einem gelenkten Dokumentenmodell verbunden sein. Es gibt keinen sachlichen Gewinn, dieselbe Schnittstellentabelle in mehreren Dateien unabhängig zu pflegen.

Nutzen Sie eindeutige Referenzen: Eine Anforderung zur richtigen Chargenzuordnung verweist auf den beschriebenen Datenübergang und dessen Prüfbelege. Der Testbericht kann dann zeigen, welche Version und Umgebung geprüft wurden. Änderungen bleiben bewertbar, weil Sie nicht erst aus verstreuten Screenshots rekonstruieren müssen, welche Verbindung zum damaligen System gehörte.

Quellen: [1] [2]

8. Beschreibung im Betrieb aktuell halten

Verankern Sie die Aktualitätsprüfung in Änderungen und periodischer Bewertung. Neue Schnittstellen, geänderte Datenablagen, Rollenmodelle oder Betriebsverantwortung können eine Anpassung erfordern. Ein rein redaktioneller Verweiswechsel kann anders behandelt werden als ein neuer Datenweg; die Unterscheidung sollte nachvollziehbar sein.

Beginnen Sie bei einem Altsystem mit belegbaren Informationen. Markieren Sie nicht bestätigte Annahmen ausdrücklich und klären Sie sie am tatsächlichen Betrieb. Ein sauber gestaltetes Diagramm ist kein Beleg für einen unbekannten Zustand. Die Checkliste hilft beim fachlichen Abschluss des Dokuments; sie ersetzt nicht die Prüfung offener Risiken.

• Kritikalität, Einsatzzweck und beschriebene Instanz benannt.
• Physischer und logischer Aufbau zusammen verständlich.
• Datenwege einschließlich manueller Übergaben und relevanter Speicherstellen erklärt.
• Schnittstellen mit fachlichen Kennungen und Zielverwendung beschrieben.
• Sicherheitsmaßnahmen und technische Voraussetzungen zugeordnet.
• Stand, Verantwortlichkeit, Detailverweise und offene Annahmen geprüft.

Quellen: [1] [2]