MCP HubMCP Hub
Retour aux compétences

perform-csv-assessment

pjt222
Mis à jour 2 days ago
6 vues
17
2
17
Voir sur GitHub
Designdesign

À propos

Cette compétence réalise des évaluations de Validation de Systèmes Informatiques (CSV) selon la méthodologie GAMP 5. Elle traite les exigences utilisateurs, l'évaluation des risques, la planification IQ/OQ/PQ, les matrices de traçabilité et les rapports de synthèse de validation. Utilisez-la pour les introductions de nouveaux systèmes GxP, les modifications majeures apportées à des systèmes validés, la revalidation périodique ou les analyses d'écarts réglementaires.

Installation rapide

Claude Code

Recommandé
Principal
npx skills add pjt222/agent-almanac -a claude-code
Commande PluginAlternatif
/plugin add https://github.com/pjt222/agent-almanac
Git CloneAlternatif
git clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/perform-csv-assessment

Copiez et collez cette commande dans Claude Code pour installer cette compétence

Documentation


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

Dépôt GitHub

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

Compétences associées

executing-plans

Design

Utilisez la compétence executing-plans lorsque vous disposez d'un plan de mise en œuvre complet à exécuter par lots contrôlés avec des points de contrôle de revue. Elle charge et examine le plan de manière critique, puis exécute les tâches par petits lots (3 tâches par défaut) tout en rapportant la progression entre chaque lot pour une revue par l'architecte. Cela garantit une mise en œuvre systématique avec des points de contrôle de qualité intégrés.

Voir la compétence

requesting-code-review

Design

Cette compétence délègue un sous-agent réviseur de code pour analyser les modifications apportées au code par rapport aux exigences avant de poursuivre. Elle doit être utilisée après avoir terminé des tâches, implémenté des fonctionnalités majeures, ou avant une fusion vers la branche principale. La revue aide à détecter précocement les problèmes en comparant l'implémentation actuelle avec le plan initial.

Voir la compétence

connect-mcp-server

Design

Cette compétence fournit un guide complet permettant aux développeurs de connecter des serveurs MCP à Claude Code via les transports HTTP, stdio ou SSE. Elle couvre l'installation, la configuration, l'authentification et la sécurité pour intégrer des services externes tels que GitHub, Notion et des API personnalisées. Utilisez-la lors de la configuration d'intégrations MCP, de la configuration d'outils externes ou du travail avec le Protocole de Contexte de Modèle de Claude.

Voir la compétence

web-cli-teleport

Design

Cette compétence aide les développeurs à choisir entre les interfaces Web et CLI de Claude Code en fonction de l'analyse des tâches, puis permet une téléportation transparente des sessions entre ces environnements. Elle optimise le flux de travail en gérant l'état et le contexte de la session lors du passage entre le web, la CLI ou le mobile. Utilisez-la pour des projets complexes nécessitant différents outils à diverses étapes.

Voir la compétence