Design Compliance Architecture

Compliance-Architektur entwerfen

Den uebergeordneten Compliance-Rahmen erstellen, der Vorschriften Systemen zuordnet, Kritikalitaet klassifiziert und Governance fuer ein reguliertes Umfeld definiert.

Wann verwenden

• Eine neue regulierte Einrichtung, Abteilung oder ein neues Programm wird aufgebaut
• Eine bestehende Organisation muss ihre Compliance-Postur ueber mehrere Systeme formalisieren
• Eine regulatorische Lueckenanalyse zeigt fehlende Systemklassifizierung oder Validierungsstrategie
• Fusionen, Akquisitionen oder Reorganisationen erfordern Harmonisierung der Compliance ueber Einheiten
• Vorbereitung eines Standortmasterdokuments oder Qualitaetshandbuchs mit Referenzen auf computergestuetzte Systeme

Eingaben

• Erforderlich: Liste der computergestuetzten Systeme im Umfang (Name, Zweck, Anbieter/individuell)
• Erforderlich: Anwendbare regulatorische Rahmen (21 CFR Part 11, EU Annex 11, GMP, GLP, GCP, ICH Q7, ICH Q10)
• Erforderlich: Organisatorischer Kontext (Abteilung, Standort, Produkttypen)
• Optional: Vorhandener Validierungsmasterplan oder Qualitaetshandbuch
• Optional: Fruehere Auditbefunde oder regulatorische Inspektionsbeobachtungen
• Optional: Organigramm mit Qualitaets- und IT-Berichtslinien

Vorgehensweise

Schritt 1: Systeminventar aufbauen

Ein umfassendes Inventar aller computergestuetzten Systeme erstellen:

# System Inventory
## Document ID: SI-[SITE]-[YYYY]-[NNN]

| ID | System Name | Version | Vendor | Purpose | Department | Data Types | Users |
|----|-------------|---------|--------|---------|------------|------------|-------|
| SYS-001 | LabWare LIMS | 8.1 | LabWare Inc. | Sample management and testing | QC | Test results, COA | 45 |
| SYS-002 | SAP ERP | S/4HANA | SAP SE | Batch release and inventory | Production | Batch records, BOM | 120 |
| SYS-003 | Custom R/Shiny | 2.1.0 | Internal | Statistical analysis | Biostatistics | Clinical data | 8 |
| SYS-004 | Windows Server | 2022 | Microsoft | File server | IT | Documents | 200 |

Erwartet: Jedes System, das GxP-relevante Daten erstellt, aendert, speichert, abruft oder uebertraegt, ist aufgelistet. Bei Fehler: Koennen Systemeigentuemer keine vollstaendigen Informationen liefern, die Luecke dokumentieren und einen Entdeckungsworkshop anberaumen. Fehlende Systeme sind ein kritisches Compliance-Risiko.

Schritt 2: Systemkritikalitaet klassifizieren

Jedem System eine Kritikalitaetsstufe zuweisen:

# System Criticality Classification
## Document ID: SCC-[SITE]-[YYYY]-[NNN]

### Classification Criteria

| Tier | Definition | Validation Required | Examples |
|------|-----------|-------------------|----------|
| **GxP-Critical** | Directly impacts product quality, patient safety, or data integrity. Generates or processes GxP records. | Full CSV per GAMP 5 | LIMS, ERP (batch), CDMS, MES |
| **GxP-Supporting** | Supports GxP processes but does not directly generate GxP records. Failure has indirect impact. | Risk-based qualification | Email, document management, scheduling |
| **Non-GxP** | No impact on product quality, safety, or data integrity. | IT standard controls only | HR systems, cafeteria, general web |

### System Classification Matrix

| System ID | System | Tier | Rationale |
|-----------|--------|------|-----------|
| SYS-001 | LabWare LIMS | GxP-Critical | Generates test results used for batch release |
| SYS-002 | SAP ERP | GxP-Critical | Manages batch records and material traceability |
| SYS-003 | R/Shiny App | GxP-Critical | Performs statistical analysis for regulatory submissions |
| SYS-004 | Windows Server | GxP-Supporting | Stores controlled documents but does not generate GxP data |

Erwartet: Jedes System hat eine Stufenzuweisung mit dokumentierter Begruendung. Bei Fehler: Wird die Kritikalitaet eines Systems beanstandet, an den Qualitaetsrat eskalieren. Im Zweifel eine Stufe hoeher klassifizieren und nach einer formalen Risikobewertung neu beurteilen.

Schritt 3: GAMP-5-Softwarekategorien zuweisen

Fuer jedes GxP-kritische und GxP-unterstuetzende System die GAMP-5-Kategorie zuweisen:

# GAMP 5 Category Assignment

| System ID | System | GAMP Category | Rationale | Validation Effort |
|-----------|--------|---------------|-----------|-------------------|
| SYS-001 | LabWare LIMS | 4 — Configured Product | COTS with extensive workflow configuration | Medium-High |
| SYS-002 | SAP ERP | 4 — Configured Product | COTS with custom transactions | Medium-High |
| SYS-003 | R/Shiny App | 5 — Custom Application | Internally developed | High — Full lifecycle |
| SYS-004 | Windows Server | 1 — Infrastructure | Operating system, no custom configuration | Low — Verify installation |

Kategoriereferenz:

• Kategorie 1: Infrastruktur (Betriebssystem, Firmware) — Installation verifizieren
• Kategorie 3: Nicht-konfiguriertes COTS — Funktionalitaet wie vorhanden pruefen
• Kategorie 4: Konfiguriertes Produkt — alle Konfigurationen pruefen
• Kategorie 5: Benutzerdefinierte Anwendung — vollstaendige Lebenszyklusvalidierung

Erwartet: Kategorienzuweisung entspricht der Nutzung des Systems, nicht nur dem, was es ist. Bei Fehler: Umfasst ein System mehrere Kategorien (z. B. COTS mit benutzerdefinierten Erweiterungen), die benutzerdefinierten Teile als Kategorie 5 und die Basis als Kategorie 4 klassifizieren.

Schritt 4: Regulatorische Anforderungen Systemen zuordnen

Eine Matrix zur Rueckverfolgbarkeit regulatorischer Anforderungen erstellen:

# Regulatory Requirements Traceability Matrix
## Document ID: RRTM-[SITE]-[YYYY]-[NNN]

| Regulation | Clause | Requirement | Applicable Systems | Control Type |
|-----------|--------|-------------|-------------------|--------------|
| 21 CFR 11 | 11.10(a) | Validation | SYS-001, SYS-002, SYS-003 | Procedural + Technical |
| 21 CFR 11 | 11.10(d) | Access controls | SYS-001, SYS-002, SYS-003, SYS-004 | Technical |
| 21 CFR 11 | 11.10(e) | Audit trail | SYS-001, SYS-002, SYS-003 | Technical |
| 21 CFR 11 | 11.50 | Signature manifestation | SYS-001, SYS-002 | Technical |
| EU Annex 11 | §4 | Validation | SYS-001, SYS-002, SYS-003 | Procedural + Technical |
| EU Annex 11 | §7 | Data storage and backup | All | Technical |
| EU Annex 11 | §9 | Audit trail | SYS-001, SYS-002, SYS-003 | Technical |
| EU Annex 11 | §12 | Security and access | All | Technical |
| ICH Q10 | §3.2 | Change management | All GxP-Critical | Procedural |
| ICH Q10 | §1.8 | Knowledge management | SYS-001, SYS-003 | Procedural |

Erwartet: Jede anwendbare regulatorische Klausel ist mindestens einem System zugeordnet, und jedes GxP-kritische System ist den relevanten regulatorischen Klauseln zugeordnet. Bei Fehler: Nicht zugeordnete Klauseln stellen Compliance-Luecken dar. Einen Sanierungsplan mit Zeitplaenen fuer jede Luecke erstellen.

Schritt 5: Validierungsstrategie pro System definieren

Basierend auf Kritikalitaet, Kategorie und regulatorischer Zuordnung:

# Validation Strategy Summary

| System | Category | Criticality | Validation Approach | Key Deliverables |
|--------|----------|------------|--------------------|--------------------|
| LabWare LIMS | 4 | Critical | Prospective CSV | URS, RA, VP, IQ, OQ, PQ, TM, VSR |
| SAP ERP | 4 | Critical | Prospective CSV | URS, RA, VP, IQ, OQ, TM, VSR |
| R/Shiny App | 5 | Critical | Prospective CSV + code review | URS, RA, VP, IQ, OQ, PQ, TM, VSR, code audit |
| Windows Server | 1 | Supporting | Installation qualification | IQ checklist |

Abkuerzungen: URS (Benutzeranforderungen), RA (Risikobewertung), VP (Validierungsplan), IQ/OQ/PQ (Installations-/Operations-/Leistungsqualifizierung), TM (Rueckverfolgbarkeitsmatrix), VSR (Validierungszusammenfassungsbericht).

Erwartet: Validierungsaufwand ist proportional zum Risiko — Kategorie-5-GxP-kritische Systeme erhalten vollstaendigen Lebenszyklus; Kategorie-1-Infrastruktur erhaelt vereinfachte IQ. Bei Fehler: Druecken Stakeholder auf reduzierte Validierung kritischer Systeme, die Risikoakzeptanz mit QA-Genehmigung dokumentieren.

Schritt 6: Governance-Struktur entwerfen

Den organisatorischen Rahmen zur Aufrechterhaltung der Konformitaet definieren:

# Compliance Governance Structure

## Roles and Responsibilities
| Role | Responsibility | Authority |
|------|---------------|-----------|
| Quality Director | Overall compliance accountability | Approve validation strategies, accept risks |
| System Owner | Day-to-day system compliance | Approve changes, ensure validated state |
| Validation Lead | Plan and coordinate validation activities | Define validation scope and approach |
| IT Operations | Technical infrastructure and security | Implement technical controls |
| QA Reviewer | Independent review of validation deliverables | Accept or reject validation evidence |

## Governance Committees
| Committee | Frequency | Purpose | Members |
|-----------|-----------|---------|---------|
| Change Control Board | Weekly | Review and approve system changes | System owners, QA, IT, validation |
| Periodic Review Committee | Quarterly | Review system compliance status | Quality director, system owners, QA |
| Audit Programme Committee | Annual | Plan internal audit schedule | Quality director, lead auditor, QA |

## Escalation Matrix
| Issue | First Escalation | Second Escalation | Timeline |
|-------|-----------------|-------------------|----------|
| Critical audit finding | System Owner → QA Director | QA Director → Site Director | 24 hours |
| Validated state breach | Validation Lead → System Owner | System Owner → Quality Director | 48 hours |
| Data integrity incident | System Owner → QA Director | QA Director → Regulatory Affairs | 24 hours |

Erwartet: Klare Verantwortlichkeit fuer jede Compliance-Aktivitaet ohne verwaiste Zustaendigkeiten. Bei Fehler: Ueberlappen oder fehlen Rollen, einen RACI-Workshop einberufen. Unklare Eigentuemeschaft ist eine wiederkehrende regulatorische Zitation.

Schritt 7: Compliance-Architekturdokument zusammenstellen

Alle Komponenten in das Masterdokument zusammenfuehren:

# Compliance Architecture
## Document ID: CA-[SITE]-[YYYY]-[NNN]
## Version: 1.0

### 1. Purpose and Scope
[Organisation, site, product scope, regulatory scope]

### 2. System Inventory
[From Step 1]

### 3. Criticality Classification
[From Step 2]

### 4. GAMP 5 Category Assignments
[From Step 3]

### 5. Regulatory Requirements Traceability
[From Step 4]

### 6. Validation Strategy
[From Step 5]

### 7. Governance Structure
[From Step 6]

### 8. Periodic Review Schedule
- System inventory refresh: Annual
- Criticality re-assessment: When new systems added or regulations change
- Regulatory mapping update: When new guidance issued
- Governance review: Annual or after organisational change

### 9. Approval
| Role | Name | Signature | Date |
|------|------|-----------|------|
| Quality Director | | | |
| IT Director | | | |
| Regulatory Affairs | | | |

Erwartet: Ein einzelnes Dokument, das als Compliance-Blaupause fuer die gesamte regulierte Umgebung dient. Bei Fehler: Uebersteigt das Dokument die praktische Groesse, ein Masterdokument mit Referenzen auf Unterlagendokumente pro System oder Bereich erstellen.

Validierung

• Systeminventar umfasst jedes System, das GxP-Daten verarbeitet
• Jedes System hat eine Kritikalitaetsstufe mit dokumentierter Begruendung
• GAMP-5-Kategorien allen GxP-kritischen und GxP-unterstuetzenden Systemen zugewiesen
• Matrix zur Rueckverfolgbarkeit regulatorischer Anforderungen deckt alle anwendbaren Klauseln ab
• Jedes GxP-kritische System hat eine definierte Validierungsstrategie
• Governance-Struktur definiert Rollen, Ausschuesse und Eskalationspfade
• Alle Dokumente haben eindeutige IDs und Versionskontrolle
• Compliance-Architekturdokument von Qualitaets- und IT-Leitung genehmigt

Haeufige Stolperfallen

• Unvollstaendiges Inventar: Fehlende Systeme sind fuer die Compliance unsichtbar. Netzwerkscans, Software-Asset-Management-Tools und Abteilungsinterviews verwenden — nicht nur IT befragen.
• Binaeres Denken: Systeme sind nicht einfach "GxP" oder "nicht GxP". Das Drei-Stufen-Modell (Kritisch, Unterstuetzend, Nicht-GxP) vermeidet sowohl Ueber- als auch Untervalidierung.
• Kategorienverwechslung: GAMP-5-Kategorie beschreibt, was die Software IST, aber der Validierungsaufwand sollte widerspiegeln, wie sie GENUTZT wird. Ein Kategorie-4-System fuer die Chargenfreigabe benoetigt mehr Tests als ein Kategorie-4-System fuer Terminplanung.
• Statische Architektur: Die Compliance-Architektur ist ein lebendes Dokument. Neue Systeme, regulatorische Aenderungen und Auditbefunde erfordern alle Updates.
• Governance ohne Wirkung: Ausschuesse, die nur auf dem Papier existieren, aber sich nie treffen, bieten keinen Compliance-Wert. Sitzungsrhythmus und Beschlussfaehigkeit definieren.

Verwandte Skills

• perform-csv-assessment — die hier definierte Validierungsstrategie fuer einzelne Systeme ausfuehren
• manage-change-control — den in der Governance definierten Aenderungskontrollprozess operationalisieren
• implement-electronic-signatures — in der regulatorischen Matrix zugeordnete e-Signatur-Kontrollen implementieren
• prepare-inspection-readiness — diese Architektur als Grundlage fuer die Inspektionsvorbereitung nutzen
• conduct-gxp-audit — gegen die Compliance-Architektur als Basislinie auditieren