Zurück zu Fähigkeiten

perform-csv-assessment

pjt222
Aktualisiert 2 days ago
9 Ansichten
17
2
17
Auf GitHub ansehen
Designdesign

Über

Diese Fähigkeit führt Computer System Validation (CSV)-Bewertungen nach der GAMP 5-Methodik durch. Sie behandelt Benutzeranforderungen, Risikobewertung, IQ/OQ/PQ-Planung, Rückverfolgbarkeitsmatrizen und Validierungsabschlussberichte. Nutzen Sie sie für die Einführung neuer GxP-Systeme, wesentliche Änderungen an validierten Systemen, periodische Revalidierung oder regulatorische Lückenanalysen.

Schnellinstallation

Claude Code

Empfohlen
Primär
npx skills add pjt222/agent-almanac -a claude-code
Plugin-BefehlAlternativ
/plugin add https://github.com/pjt222/agent-almanac
Git CloneAlternativ
git clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/perform-csv-assessment

Kopieren Sie diesen Befehl und fügen Sie ihn in Claude Code ein, um diese Fähigkeit zu installieren

Dokumentation


name: perform-csv-assessment description: > Realizar una evaluación de Validación de Sistemas Informatizados (CSV) siguiendo la metodología GAMP 5. Cubre requisitos de usuario, evaluación de riesgo, planificación IQ/OQ/PQ, creación de matrices de trazabilidad e informes de resumen de validación. Usar cuando se introduce un nuevo sistema informatizado en un entorno GxP, cuando un sistema validado existente experimenta un cambio significativo, cuando se requiere revalidación periódica, o cuando una inspección regulatoria exige un análisis de brechas de validación. locale: es source_locale: en source_commit: 6f65f316 translator: claude-sonnet-4-6 translation_date: 2026-03-16 license: MIT allowed-tools: Read Write Edit Bash Grep Glob metadata: author: Philipp Thoss version: "1.0" domain: compliance complexity: advanced language: multi tags: csv, gamp-5, validation, risk-assessment, iq-oq-pq, traceability

Realizar Evaluación CSV

Llevar a cabo una evaluación de Validación de Sistemas Informatizados usando la metodología basada en riesgo GAMP 5 para entornos regulados.

Cuándo Usar

  • Se introduce un nuevo sistema informatizado en un entorno GxP
  • Un sistema validado existente experimenta un cambio significativo
  • Se requiere revalidación periódica
  • La preparación para una inspección regulatoria exige un análisis de brechas de validación

Entradas

  • Requerido: Descripción del sistema (nombre, propósito, proveedor, versión)
  • Requerido: Declaración de uso previsto y contexto regulatorio (alcance GxP)
  • Requerido: Categoría de software GAMP 5 (1–5)
  • Opcional: Especificación de requisitos de usuario (URS) existente
  • Opcional: Documentación del proveedor (especificaciones de diseño, notas de versión, SOPs)
  • Opcional: Documentación de validación previa

Procedimiento

Paso 1: Determinar la Categoría de Software GAMP 5

Clasificar el sistema:

CategoríaTipoEjemploEsfuerzo de Validación
1Software de infraestructuraSO, firmwareBajo — verificar instalación
3Producto no configuradoCOTS tal como estáBajo-Medio — verificar funcionalidad
4Producto configuradoLIMS con configuraciónMedio-Alto — verificar configuración
5Aplicación personalizadaApp R/Shiny a medidaAlto — validación completa del ciclo de vida

Esperado: Categoría claramente asignada con fundamento documentado. En caso de fallo: Si la categoría es ambigua, usar la categoría superior y documentar el fundamento.

Paso 2: Redactar la Especificación de Requisitos de Usuario (URS)

Crear un documento URS con requisitos numerados:

# User Requirements Specification
## System: [System Name] v[Version]
## Document ID: URS-[SYS]-[NNN]

### 1. Purpose
[Intended use statement]

### 2. Functional Requirements
| ID | Requirement | Priority | Source |
|----|-------------|----------|--------|
| URS-001 | System shall calculate BMI from height and weight inputs | Must | Regulatory SOP-xxx |
| URS-002 | System shall generate audit trail entries for all data changes | Must | 21 CFR 11.10(e) |
| URS-003 | System shall export results in PDF format | Should | User request |

### 3. Non-Functional Requirements
| ID | Requirement | Priority | Source |
|----|-------------|----------|--------|
| URS-010 | System shall respond within 3 seconds for standard queries | Should | Usability |
| URS-011 | System shall restrict access via role-based authentication | Must | 21 CFR 11.10(d) |

### 4. Data Integrity Requirements
[ALCOA+ requirements: Attributable, Legible, Contemporaneous, Original, Accurate]

### 5. Regulatory Requirements
[Specific 21 CFR Part 11, EU Annex 11, or other applicable requirements]

Esperado: Todos los requisitos tienen IDs únicos, prioridades y trazabilidad a la fuente. En caso de fallo: Señalar para revisión de las partes interesadas los requisitos sin fuente o prioridad clara.

Paso 3: Realizar la Evaluación de Riesgo

Aplicar el enfoque basado en riesgo GAMP 5 usando un Análisis de Modos de Fallo y Efectos (FMEA):

# Risk Assessment
## Document ID: RA-[SYS]-[NNN]

| Req ID | Failure Mode | Severity (1-5) | Probability (1-5) | Detectability (1-5) | RPN | Risk Level | Mitigation |
|--------|-------------|----------------|-------------------|---------------------|-----|------------|------------|
| URS-001 | Incorrect BMI calculation | 4 | 2 | 1 | 8 | Low | OQ test case |
| URS-002 | Audit trail entries missing | 5 | 3 | 3 | 45 | High | IQ + OQ + monitoring |
| URS-011 | Unauthorized access | 5 | 2 | 2 | 20 | Medium | OQ test + periodic review |

Número de Prioridad de Riesgo (RPN) = Severidad x Probabilidad x Detectabilidad.

Rango RPNNivel de RiesgoRequisito de Prueba
1–12BajoVerificación básica
13–36MedioCaso de prueba documentado
37+AltoIQ/OQ/PQ completo con reprueba

Esperado: Cada requisito URS tiene una fila correspondiente en la evaluación de riesgo. En caso de fallo: Escalar al responsable de validación los requisitos sin evaluar antes de proceder.

Paso 4: Definir la Estrategia de Validación (Plan de Validación)

# Validation Plan
## Document ID: VP-[SYS]-[NNN]

### Scope
- System: [Name] v[Version]
- GAMP Category: [N]
- Validation approach: [Prospective / Retrospective / Concurrent]

### Qualification Stages
| Stage | Scope | Applies? | Rationale |
|-------|-------|----------|-----------|
| IQ | Installation correctness | Yes | Verify installation, dependencies, configuration |
| OQ | Operational requirements | Yes | Verify functional requirements from URS |
| PQ | Performance under real conditions | [Yes/No] | [Rationale] |

### Roles and Responsibilities
| Role | Name | Responsibility |
|------|------|---------------|
| Validation Lead | [Name] | Plan, coordinate, approve |
| Tester | [Name] | Execute test scripts |
| System Owner | [Name] | Approve for production use |
| QA | [Name] | Review and sign-off |

### Acceptance Criteria
- All critical test cases pass
- No unresolved critical or major deviations
- Traceability matrix complete

Esperado: Plan de validación aprobado por todas las partes interesadas antes de la ejecución de pruebas. En caso de fallo: No proceder a la ejecución de pruebas sin un plan de validación aprobado.

Paso 5: Crear Protocolos de Prueba (IQ/OQ/PQ)

Redactar scripts de prueba para cada etapa de calificación:

# Operational Qualification Protocol
## Test Case: TC-OQ-001
## Traces to: URS-001

**Objective:** Verify BMI calculation accuracy

**Prerequisites:**
- System installed per IQ protocol
- Test data set prepared

**Test Steps:**
| Step | Action | Expected Result | Actual Result | Pass/Fail |
|------|--------|-----------------|---------------|-----------|
| 1 | Enter height=180cm, weight=75kg | BMI displayed as 23.15 | | |
| 2 | Enter height=160cm, weight=90kg | BMI displayed as 35.16 | | |
| 3 | Enter height=0, weight=75kg | Error message displayed | | |

**Tester:** _________ Date: _________
**Reviewer:** _________ Date: _________

Esperado: Cada requisito de riesgo medio y alto tiene al menos un caso de prueba. En caso de fallo: Añadir los casos de prueba faltantes antes de que comience la ejecución.

Paso 6: Construir la Matriz de Trazabilidad

Crear una Matriz de Trazabilidad de Requisitos (RTM) que vincule cada requisito a través de la evaluación de riesgo hasta los casos de prueba:

# Traceability Matrix
## Document ID: TM-[SYS]-[NNN]

| URS ID | Requirement | Risk Level | Test Case(s) | Test Result | Status |
|--------|-------------|------------|--------------|-------------|--------|
| URS-001 | BMI calculation | Low | TC-OQ-001 | Pass | Verified |
| URS-002 | Audit trail | High | TC-IQ-003, TC-OQ-005 | Pass | Verified |
| URS-003 | PDF export | Low | TC-OQ-008 | Pass | Verified |
| URS-011 | Role-based access | Medium | TC-OQ-010, TC-OQ-011 | Pass | Verified |

Esperado: El 100% de los requisitos URS aparece en la matriz de trazabilidad con resultados de prueba vinculados. En caso de fallo: Cualquier requisito sin resultado de prueba vinculado se señala como una brecha de validación.

Paso 7: Redactar el Informe de Resumen de Validación

# Validation Summary Report
## Document ID: VSR-[SYS]-[NNN]

### 1. Executive Summary
[System name] v[version] has been validated in accordance with [VP document ID].

### 2. Validation Activities Performed
| Activity | Document ID | Status |
|----------|-------------|--------|
| User Requirements | URS-SYS-001 | Approved |
| Risk Assessment | RA-SYS-001 | Approved |
| Validation Plan | VP-SYS-001 | Approved |
| IQ Protocol/Report | IQ-SYS-001 | Executed — Pass |
| OQ Protocol/Report | OQ-SYS-001 | Executed — Pass |
| Traceability Matrix | TM-SYS-001 | Complete |

### 3. Deviations
| Dev ID | Description | Impact | Resolution |
|--------|-------------|--------|------------|
| DEV-001 | [Description] | [Impact assessment] | [Resolution and rationale] |

### 4. Conclusion
The system meets all user requirements as documented in [URS ID]. The validation is considered [Successful / Successful with conditions].

### 5. Approval
| Role | Name | Signature | Date |
|------|------|-----------|------|
| Validation Lead | | | |
| System Owner | | | |
| Quality Assurance | | | |

Esperado: El informe hace referencia a todos los entregables de validación con una conclusión clara de aprobado/fallido. En caso de fallo: Si las desviaciones no están resueltas, el informe debe indicar el estado "condicional" con referencias CAPA.

Validación

  • Categoría GAMP 5 asignada con fundamento documentado
  • La URS tiene requisitos numerados con prioridades y trazabilidad a la fuente
  • La evaluación de riesgo cubre cada requisito URS
  • El plan de validación aprobado antes de la ejecución de pruebas
  • Los protocolos de prueba tienen campos de prerrequisito, paso, resultado esperado y firma
  • La matriz de trazabilidad vincula cada requisito con el riesgo y los resultados de prueba
  • El informe de resumen de validación documenta todas las actividades, desviaciones y conclusión
  • Todos los documentos tienen IDs únicos y control de versiones

Errores Comunes

  • Sobrevalidación: Aplicar el esfuerzo de Categoría 5 al software de Categoría 3 desperdicia recursos. Ajustar el esfuerzo al riesgo.
  • Trazabilidad faltante: Los requisitos que no se vinculan hasta los casos de prueba son brechas invisibles.
  • Probar sin un plan: Ejecutar pruebas antes de que el plan de validación esté aprobado invalida los resultados.
  • Ignorar los requisitos no funcionales: Los requisitos de seguridad, rendimiento e integridad de datos a menudo se pasan por alto.
  • Validación estática: Tratar la validación como un evento único. Los cambios requieren reevaluación.

Habilidades Relacionadas

  • setup-gxp-r-project — estructura del proyecto para entornos R validados
  • write-validation-documentation — redacción de protocolos e informes IQ/OQ/PQ
  • implement-audit-trail — implementación de registro de auditoría para registros electrónicos
  • validate-statistical-output — metodología de verificación de salida estadística
  • conduct-gxp-audit — auditoría de sistemas validados

GitHub Repository

pjt222/agent-almanac
Pfad: i18n/es/skills/perform-csv-assessment
0
agentsagentskillsai-assisted-developmentclaude-codeskillsteams

Verwandte Skills

executing-plans

Design

Verwenden Sie die Fähigkeit "executing-plans", wenn Sie einen vollständigen Implementierungsplan zur Ausführung in kontrollierten Batches mit Überprüfungspunkten vorliegen haben. Sie lädt den Plan und überprüft ihn kritisch, führt dann Aufgaben in kleinen Batches (standardmäßig 3 Aufgaben) aus und meldet den Fortschritt zwischen jedem Batch zur Überprüfung durch den Architekten. Dies gewährleistet eine systematische Implementierung mit integrierten Qualitätskontrollpunkten.

Skill ansehen

requesting-code-review

Design

Diese Fähigkeit sendet einen Unteragenten für Code-Review, um Codeänderungen anhand der Anforderungen zu analysieren, bevor fortgefahren wird. Sie sollte nach dem Abschließen von Aufgaben, der Implementierung größerer Funktionen oder vor dem Zusammenführen in den Hauptzweig verwendet werden. Die Überprüfung hilft dabei, Probleme frühzeitig zu erkennen, indem die aktuelle Implementierung mit dem ursprünglichen Plan verglichen wird.

Skill ansehen

connect-mcp-server

Design

Diese Fähigkeit bietet Entwicklern eine umfassende Anleitung, um MCP-Server über HTTP-, stdio- oder SSE-Transports mit Claude Code zu verbinden. Sie behandelt Installation, Konfiguration, Authentifizierung und Sicherheit für die Integration externer Dienste wie GitHub, Notion und benutzerdefinierter APIs. Nutzen Sie sie beim Einrichten von MCP-Integrationen, bei der Konfiguration externer Tools oder bei der Arbeit mit Claude's Model Context Protocol.

Skill ansehen

web-cli-teleport

Design

Diese Fähigkeit unterstützt Entwickler bei der Wahl zwischen Claude Code Web- und CLI-Schnittstellen basierend auf Aufgabenanalysen und ermöglicht nahtloses Session-Teleporting zwischen diesen Umgebungen. Sie optimiert den Workflow, indem sie den Sitzungsstatus und Kontext beim Wechsel zwischen Web, CLI oder Mobilgeräten verwaltet. Nutzen Sie sie für komplexe Projekte, die in verschiedenen Phasen unterschiedliche Werkzeuge erfordern.

Skill ansehen