Design Compliance Architecture

Diseñar Arquitectura de Cumplimiento

Establecer el marco de cumplimiento de alto nivel que mapea las regulaciones a los sistemas, clasifica la criticidad y define la gobernanza para un entorno regulado.

Cuándo Usar

• Se está estableciendo una nueva instalación, departamento o programa regulado
• Una organización existente necesita formalizar su postura de cumplimiento en múltiples sistemas
• Un análisis de brechas regulatorias revela clasificación de sistemas o estrategia de validación faltante
• Fusiones, adquisiciones o reorganizaciones requieren armonizar el cumplimiento entre entidades
• Al preparar un expediente de sitio o manual de calidad que hace referencia a sistemas informatizados

Entradas

• Requerido: Lista de sistemas informatizados en alcance (nombre, propósito, proveedor/personalizado)
• Requerido: Marcos regulatorios aplicables (21 CFR Parte 11, EU Anexo 11, GMP, GLP, GCP, ICH Q7, ICH Q10)
• Requerido: Contexto organizacional (departamento, sede, tipos de productos)
• Opcional: Plan maestro de validación o manual de calidad existente
• Opcional: Hallazgos de auditorías anteriores u observaciones de inspecciones regulatorias
• Opcional: Organigrama con líneas de reporte de calidad y TI

Procedimiento

Paso 1: Construir el Inventario de Sistemas

Crear un inventario completo de todos los sistemas informatizados:

# 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 |

Esperado: Cada sistema que crea, modifica, almacena, recupera o transmite datos relevantes para GxP está listado. En caso de fallo: Si los propietarios de sistemas no pueden proporcionar información completa, documentar la brecha y programar un taller de descubrimiento. Los sistemas faltantes son un riesgo crítico de cumplimiento.

Paso 2: Clasificar la Criticidad del Sistema

Asignar a cada sistema un nivel de criticidad:

# 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 |

Esperado: Cada sistema tiene una asignación de nivel con fundamento documentado. En caso de fallo: Si la criticidad de un sistema está en disputa, escalar al consejo de calidad. Ante la duda, clasificar un nivel más alto y reevaluar tras una evaluación formal de riesgo.

Paso 3: Asignar las Categorías de Software GAMP 5

Para cada sistema GxP-Crítico y GxP-de Soporte, asignar la categoría GAMP 5:

# 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 |

Referencia de categorías:

• Categoría 1: Infraestructura (SO, firmware) — verificar instalación
• Categoría 3: COTS no configurado — verificar funcionalidad tal como está
• Categoría 4: Producto configurado — verificar todas las configuraciones
• Categoría 5: Aplicación personalizada — validación completa del ciclo de vida

Esperado: La asignación de categoría se alinea con cómo se usa el sistema, no solo con lo que es. En caso de fallo: Si un sistema abarca categorías (por ejemplo, COTS con complementos personalizados), clasificar las partes personalizadas como Categoría 5 y la base como Categoría 4.

Paso 4: Mapear los Requisitos Regulatorios a los Sistemas

Crear una matriz de trazabilidad de requisitos regulatorios:

# 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 |

Esperado: Cada cláusula regulatoria aplicable se mapea a al menos un sistema, y cada sistema GxP-Crítico se mapea a las cláusulas regulatorias relevantes. En caso de fallo: Las cláusulas sin mapear representan brechas de cumplimiento. Crear un plan de remediación con plazos para cada brecha.

Paso 5: Definir la Estrategia de Validación por Sistema

Basándose en la criticidad, la categoría y el mapeo regulatorio:

# 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 |

Abreviaturas: URS (Requisitos de Usuario), RA (Evaluación de Riesgos), VP (Plan de Validación), IQ/OQ/PQ (Calificación de Instalación/Operacional/Desempeño), TM (Matriz de Trazabilidad), VSR (Informe de Resumen de Validación).

Esperado: El esfuerzo de validación es proporcional al riesgo — los sistemas GxP-Críticos de Categoría 5 obtienen el ciclo de vida completo; la infraestructura de Categoría 1 obtiene IQ simplificado. En caso de fallo: Si las partes interesadas presionan para reducir la validación de sistemas críticos, documentar la aceptación del riesgo con la firma de Aseguramiento de Calidad.

Paso 6: Diseñar la Estructura de Gobernanza

Definir el marco organizacional para mantener el cumplimiento:

# 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 |

Esperado: Responsabilidad clara para cada actividad de cumplimiento sin responsabilidades huérfanas. En caso de fallo: Si los roles se superponen o no están asignados, convocar un taller RACI para resolver. La propiedad ambigua es una cita regulatoria recurrente.

Paso 7: Compilar el Documento de Arquitectura de Cumplimiento

Reunir todos los componentes en el documento maestro:

# 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 | | | |

Esperado: Un único documento que sirve como el plano de cumplimiento para todo el entorno regulado. En caso de fallo: Si el documento supera un tamaño práctico, crear un documento maestro con referencias a documentos subsidiarios por sistema o dominio.

Validación

• El inventario de sistemas incluye cada sistema que maneja datos GxP
• Cada sistema tiene un nivel de criticidad con fundamento documentado
• Categorías GAMP 5 asignadas a todos los sistemas GxP-Críticos y GxP-de Soporte
• La matriz de trazabilidad de requisitos regulatorios cubre todas las cláusulas aplicables
• Cada sistema GxP-Crítico tiene una estrategia de validación definida
• La estructura de gobernanza define roles, comités y rutas de escalación
• Todos los documentos tienen IDs únicos y control de versiones
• El documento de arquitectura de cumplimiento está aprobado por el liderazgo de calidad y TI

Errores Comunes

• Inventario incompleto: Los sistemas faltantes son invisibles para el cumplimiento. Usar escaneos de red, herramientas de gestión de activos de software y entrevistas departamentales, no solo preguntar a TI.
• Pensamiento binario: Los sistemas no son simplemente "GxP" o "no GxP". El modelo de tres niveles (Crítico, De Soporte, No GxP) evita tanto la sobrevalidación como la subvalidación.
• Confusión de categorías: La categoría GAMP 5 describe lo que el software ES, pero el esfuerzo de validación debe reflejar cómo se USA. Un sistema de Categoría 4 usado para la liberación de lotes necesita más pruebas que uno de Categoría 4 usado para programación.
• Arquitectura estática: La arquitectura de cumplimiento es un documento vivo. Los nuevos sistemas, los cambios regulatorios y los hallazgos de auditorías requieren actualizaciones.
• Gobernanza sin efecto real: Los comités que existen sobre el papel pero nunca se reúnen no aportan valor de cumplimiento. Definir la cadencia de reuniones y los requisitos de quórum.

Habilidades Relacionadas

• perform-csv-assessment — ejecutar la estrategia de validación definida aquí para sistemas individuales
• manage-change-control — operacionalizar el proceso de control de cambios definido en la gobernanza
• implement-electronic-signatures — implementar los controles de firma electrónica mapeados en la matriz regulatoria
• prepare-inspection-readiness — usar esta arquitectura como base para la preparación de inspecciones
• conduct-gxp-audit — auditar contra la arquitectura de cumplimiento como línea de base