Pruebas orientadas a evidencia para sistemas de investigación regulada

OpenFactory puede automatizar comprobaciones acotadas de infraestructura y aplicación para una organización de investigación por contrato. No determina cumplimiento FDA, valida un sistema informatizado completo automáticamente ni sustituye el sistema de calidad y aprobaciones responsables de la organización regulada.

21 CFR Part 11  aplica a registros y firmas electrónicos especificados e incluye controles más allá de una imagen de sistema operativo: validación del sistema, protección y recuperación de registros, comprobaciones de acceso y autoridad, pistas de auditoría con marca de tiempo, formación, políticas, controles documentales y requisitos de firma. Las reglas predicate aplicables y el uso previsto deben establecerlos personal legal, regulatorio y de calidad cualificado.

La guía actual de Computer Software Assurance de la FDA  describe un enfoque basado en riesgo para software de producción y sistemas de gestión de calidad. Los equipos deben determinar la aplicabilidad a su sistema y contexto en lugar de tratar un recuento genérico de pruebas como validación.

Qué puede respaldar la evidencia OpenFactory

• procedencia exacta de receta y fuente para una compilación de imagen;
• aserciones de paquete, servicio, archivo, puerto y comando en un guest arrancado;
• evidencia GUI y de captura acotada donde se ejecute una aserción admitida;
• marcas de tiempo, salida e identificadores de artefacto por ejecución;
• pruebas negativas y de recuperación repetibles; y
• comparación de un artefacto nuevo contra una línea base aprobada.

Cada elemento es evidencia para un requisito declarado. Ninguno establece por sí solo aceptabilidad regulatoria.

Empieza por uso previsto y riesgo

Antes de redactar pruebas, documenta:

1. el uso previsto del sistema informatizado;
2. registros y firmas regulados, si los hay;
3. usuarios, roles, interfaces y flujos de datos;
4. riesgos para pacientes, calidad de producto e integridad de datos;
5. requisitos y criterios de aceptación ligados a esos riesgos;
6. responsabilidades de proveedor y componente; y
7. procedimientos de cambio, incidente, copia de seguridad, recuperación, retención y desmantelamiento.

La imagen del sistema operativo es solo un elemento de configuración dentro de ese sistema.

Escenario acotado de ejemplo

Este ejemplo comprueba un servicio de integración sintético y configuración de auditoría local. No afirma que un EDC, LIMS, base de datos de seguridad o flujo Part 11 esté validado.

{
  "id": "synthetic-integration-smoke",
  "name": "Synthetic integration and audit smoke test",
  "enabled": true,
  "tests": ["boot", "login", "packages", "services"],
  "custom_tests": [
    {
      "description": "Confirm the synthetic receiver and audit controls are present.",
      "assertions": [
        {
          "type": "service_running",
          "description": "The synthetic receiver is running.",
          "params": {"service": "synthetic-receiver"}
        },
        {
          "type": "port_listening",
          "description": "The synthetic receiver listens on its lab port.",
          "params": {"port": 2575}
        },
        {
          "type": "service_running",
          "description": "The Linux audit daemon is running.",
          "params": {"service": "auditd"}
        },
        {
          "type": "file_contains",
          "description": "The approved synthetic data path has an audit watch.",
          "params": {
            "path": "/etc/audit/rules.d/research-system.rules",
            "content": "-w /var/lib/synthetic-study"
          }
        }
      ]
    }
  ]
}

Usa solo datos de prueba sintéticos no sensibles en sistemas compartidos de compilación y captura. Una captura puede exponer identificadores de sujetos, credenciales, notificaciones o contenido de escritorio no relacionado. Define controles de captura, redacción, acceso, retención, exportación y eliminación antes de recogerla.

Paquete de evidencia

Para cada ejecución de prueba aprobada, conserva:

• identificadores de requisito y riesgo;
• protocolo de prueba y resultado esperado;
• revisión de receta, commits de fuente, inventario de dependencias y digest de imagen;
• identidad de entorno y datos de prueba;
• salida en bruto, capturas donde estén justificadas, marcas de tiempo y versión del runner;
• desviaciones, pasos fallidos, investigaciones y enlaces de re-prueba;
• identidad del revisor, decisión y fecha; y
• trazabilidad de requisito a evidencia y decisión de release.

No reetiquetes un log de eventos automatizado o carpeta de capturas como pista de auditoría Part 11. Los controles de pista de auditoría Part 11 conciernen acciones sobre registros regulados, retención, disponibilidad e integridad en todo el sistema aplicable.

Flujo de cambio y regresión

1. Evalúa el impacto del cambio propuesto.
2. Selecciona pruebas según riesgo y requisitos afectados.
3. Compila un artefacto inmutable nuevo; conserva el artefacto aprobado anterior.
4. Ejecuta el protocolo en un entorno controlado.
5. Revisa fallos y desviaciones sin borrar evidencia desfavorable.
6. Obtén las aprobaciones de calidad, seguridad, negocio y regulatorias requeridas.
7. Despliega mediante control de cambios y verifica la configuración de producción.
8. Monitoriza deriva y ejecuta la ruta de recuperación probada cuando haga falta.

OpenFactory puede acortar la recopilación de evidencia para pasos que realmente automatiza. La organización regulada sigue siendo responsable de la validación de uso previsto, controles procedimentales, gobernanza de datos y la decisión final de release.