Enero 19, 2023
En septiembre de 2022, la FDA publicó Proyecto de guía de garantía de sistemas informáticos (CSA) Aclara los requisitos de validación de software para los fabricantes de dispositivos médicos. Esta guía reduce significativamente la carga de validación para los fabricantes y genera un mayor potencial para acelerar la adopción de tecnologías digitales.
La guía de la CSA se basa en 21 CFR Parte 820, que regula ampliamente el software utilizado en los sistemas de producción y calidad. Por ello, analizamos las diferencias entre la CSA y la validación de software informático (CSV) y el contenido de la nueva guía.
¿Qué es la garantía de software informático (CSA)?
Según la definición de la FDA, CSA es “un enfoque basado en el riesgo para establecer y mantener la confianza de que el software es adecuado para el uso previsto”.
Además, el enfoque de CSA considera los riesgos para la seguridad o la calidad del dispositivo si el software no funciona según lo previsto. Por lo tanto, el nivel de garantía y las actividades relacionadas que se utilizan para generar confianza en el software se basan en dichos riesgos. enfoque menos onerosoLas actividades de aseguramiento son la cantidad mínima de información necesaria para abordar el riesgo.
En última instancia, la orientación de la CSA para los sistemas de calidad tiene como objetivo reducir los obstáculos innecesarios que podrían retrasar la comercialización de dispositivos médicos para garantizar que los pacientes tengan acceso oportuno a los productos.
Dónde encaja la nueva orientación
Actualmente, Reglamento del Sistema de Calidad 21 CFR 820.70(i) Requiere que los fabricantes validen el software utilizado como parte del sistema de producción o de calidad. Esto incluye el software del sistema de gestión de calidad (SGC).
Desde la publicación de 21 CFR 820.70(i), la FDA ha participado en varios documentos de orientación relacionados con la validación de software. Estos incluyen el documento de la agencia Principios generales de validación de software (GPSV) y la Sociedad Internacional de Ingeniería Farmacéutica (ISPE) Enfoque basado en riesgos para sistemas informáticos que cumplen con las normas GxP (GAMP 5).
La guía de la CSA complementa la GPSV, reemplazando únicamente la Sección 6. Se basa en la Marco GAMP 5, que reconoce diferentes niveles de riesgo asociados con distintos tipos de software.
Comprensión de la guía de la CSA para el enfoque de sistemas de calidad
Durante décadas, los fabricantes han aplicado principios de validación de software a todo el software utilizado, independientemente del riesgo para la seguridad. Sin embargo, GPSV recomienda el aseguramiento de la calidad del software para prevenir defectos en su desarrollo, incluyendo un enfoque basado en el riesgo para demostrar su correcto funcionamiento.
La nueva guía de CSA para el aseguramiento del software incluye recomendaciones para computadoras o software utilizados en sistemas de producción o calidad. Por lo tanto, la guía es aplicable al software de SGC.
Afortunadamente, la CSA permite una mayor flexibilidad para cumplir con 21 CFR 820.70(i) al permitir que los fabricantes aprovechen actividades como:
- Pruebas basadas en riesgos – analizar el riesgo en función de la complejidad del software, la criticidad del negocio, la frecuencia de uso y las áreas de defectos probables
- Pruebas sin guion – requiere menos tiempo que los scripts de prueba tradicionales; reservado para funciones y sistemas de riesgo bajo a medio
- Monitoreo continuo del desempeño – el proceso de evaluar continuamente el rendimiento del software según las expectativas
- Monitoreo de datos – identificar claramente cómo la calidad de los datos cumplirá con sus objetivos establecidos
- Actividades de validación – tal como lo completan otras partes, como los proveedores de software
El marco de orientación sobre riesgos de la CSA
El marco de riesgo de CSA se centra en cuatro pasos distintos:
- Identificar el uso previsto de la característica o función del software
- Determinación del enfoque basado en riesgos
- Determinar las actividades de aseguramiento correspondientes que deben realizarse
- Crear el registro apropiado que documente QUÉ
1. Identificación del uso previsto
El Título 21 del Código de Regulaciones Federales (CFR) 820.70(i) exige que los fabricantes validen el software que forma parte de los sistemas de producción o calidad para su uso previsto. Esto incluye el software para automatizar procesos de calidad, recopilar y procesar datos de calidad o mantener registros de calidad.
En ocasiones, el software utilizado en sistemas de producción o calidad puede tener varias características, funciones y operaciones con uno o más usos previstos. En este caso, la FDA recomienda analizar los usos previstos de cada característica y función para determinar las actividades de aseguramiento adecuadas.
Por ejemplo, se utiliza un software comercial estándar (COTS) para documentar los datos de tiempo y temperatura de un proceso de curado. Dado que el software permite mantener registros de calidad, mantener un estado validado podría no requerir actividades de aseguramiento más allá de:
- Lo que el desarrollador ya ha hecho en términos de validación
- Realizar una evaluación de proveedores
- Instalación y configuración de software
Por el contrario, si una fórmula personalizada calcula estadísticas para monitorear el proceso de curado, podría ser necesaria una validación adicional.
2. Determinación del enfoque basado en el riesgo
Tras determinar que el software forma parte de los sistemas de producción o calidad, el siguiente paso es un análisis basado en riesgos para determinar las actividades de aseguramiento. Este enfoque basado en riesgos incluye:
- Identificación de fallos de software razonablemente previsibles
- Determinar si cada fallo supone un alto riesgo para el proceso
- Seleccionar y realizar actividades de aseguramiento acordes con el riesgo del dispositivo médico o del proceso, según corresponda
Además, el análisis basado en riesgos debe considerar los factores que pueden impedir que el software funcione según lo previsto, incluidos:
- Configuración o gestión del sistema
- La seguridad del sistema
- Almacenamiento y transferencia de datos
- Error del operador
Para fallos razonablemente previsibles, este análisis debe examinar el riesgo resultante, incluyendo (1) el riesgo del proceso y (2) el riesgo del dispositivo médico. La FDA define estos riesgos de la siguiente manera:
- Riesgo de proceso:Potencial para comprometer la producción o el sistema de calidad
- Riesgo de los dispositivos médicos:Potencial de dañar al paciente
El alto riesgo de proceso ocurre cuando una falla de software puede resultar en un problema de calidad que podría aumentar el riesgo para los dispositivos médicos. Por otro lado, si una falla de software no representa un riesgo para los dispositivos médicos, no se considera un alto riesgo de proceso. Por lo tanto, funciones del SGC como gestión de reclamacionesEl control de cambios y la gestión documental no se consideran de alto riesgo.
La guía de la FDA dice que la agencia está “principalmente interesada en la revisión y garantía de aquellas características, funciones y operaciones de software que representan un alto riesgo de proceso porque una falla también representa un riesgo para el dispositivo médico”.
En la práctica, muchos fabricantes utilizan Gestión sistemática del riesgo, Herramientas que cubren una gama de riesgos intermedios. En este caso, dado que la FDA solo considera los riesgos altos y bajos, los riesgos intermedios también se consideran bajos. Para aquellos que se consideran de alto riesgo de proceso, el siguiente paso lógico es evaluar el riesgo del dispositivo médico.
3. Determinación de las actividades de aseguramiento adecuadas
La guía de la CSA recomienda que, para los problemas de calidad que representan un alto riesgo de proceso, las actividades de aseguramiento se correlacionen con el riesgo del dispositivo médico. Por otro lado, cuando un problema de calidad no se considera de alto riesgo de proceso, el nivel de las actividades de aseguramiento debe corresponder al riesgo del proceso.
Por ejemplo, la FDA utiliza una función que registra los datos del proceso para su revisión, lo que implica un menor riesgo. Sin embargo, el riesgo es mayor cuando los datos del proceso ayudan a determinar la aceptabilidad del producto antes de la revisión.
Las características de software de alto riesgo suelen requerir actividades de aseguramiento más rigurosas, como pruebas con guiones o pruebas con guiones limitadas. Por otro lado, un riesgo de proceso bajo suele implicar la generación de evidencia menos objetiva. Por ejemplo, las actividades de aseguramiento de un riesgo de proceso bajo pueden incluir métodos de prueba no predefinidos (como pruebas ad hoc, de intuición de errores o pruebas exploratorias).
Además de las características del software, los fabricantes de dispositivos deben revisar otros controles dentro del sistema de calidad, aprovechando trabajos como:
- Actividades de control de producción, incluidos los procedimientos de integridad de datos
- Procesos de selección de proveedores
- Trabajo de validación ya realizado por el proveedor de software
- Datos de monitoreo continuo para detectar problemas de rendimiento del software
- Herramientas CSV como seguimiento de errores y pruebas automatizadas
Si bien las herramientas utilizadas pueden variar, lo importante es que el fabricante garantice que el software mantenga un estado validado.
4. Creación del registro
La guía de la FDA establece que los fabricantes deben crear un registro de las actividades de verificación. Para cada software incluido, el registro debe incluir el uso previsto, la determinación del riesgo y la documentación de las actividades de verificación realizadas, incluyendo:
- Descripción de la prueba
- ¿Se encontraron problemas y qué se hizo para resolverlos?
- Conclusión que establece la aceptabilidad de los resultados
- Fecha de la prueba y persona que la realizó
- Firma y fecha de la persona que revisa el registro
La conexión del sistema de gestión de calidad con la guía CSV
software de gestión de calidad Generalmente, el software se clasifica como de categoría 4 o 5 según la guía GAMP 5, dependiendo de si se añaden funciones personalizadas. La categoría 4 es el software más común en el sector. En comparación con el software preconfigurado, proporciona herramientas validadas para configurar el software sin necesidad de codificación, a fin de cumplir con los requisitos del negocio. Esto se compara con el software de categoría 5, que presenta niveles adicionales de personalización que requieren cambios en el código.
El Enfoque de CSA Reduce significativamente las necesidades de validación cuando el proveedor de software ya ha realizado una validación completa. Para algunas funciones, las empresas pueden simplemente utilizar la documentación del proveedor, demostrando así el funcionamiento del software en un escenario de prueba integral. Las empresas deben evaluar la documentación técnica del proveedor, así como las plantillas de validación para las funciones configuradas del SGC.
Conclusión
La transición de la validación de sistemas informáticos a la CSA puede reducir drásticamente el tiempo y los costos asociados con la implementación de software automatizado. De hecho, el Foro de Casos de Calidad del Consorcio de Innovación en Dispositivos Médicos (MDIC) de 2020 señala una reducción del 50 % o más en el tiempo de validación con este enfoque.
Basándose en las regulaciones y directrices existentes, la CSA representa una vía simplificada para mantener el software en un estado validado. Para los fabricantes, reduce las barreras para la adopción de nuevas tecnologías que pueden mejorar la seguridad del paciente, incluido el software de SGC. Con este cambio, las empresas pueden ahorrar tiempo y dinero, a la vez que aumentan la productividad y la eficiencia.
Sobre el Autor
Estefanía Ojeda Es Directora de Gestión de Productos para la industria de Ciencias de la Vida en AssurX. Stephanie cuenta con más de 15 años de experiencia liderando funciones de control de calidad en diversas industrias, como la farmacéutica, la biotecnológica, la de dispositivos médicos, la de alimentos y bebidas y la manufacturera.
