La incorporación de un nuevo software a la planta farmacéutica supone siempre un reto. La elección del software más adecuado debe contemplar varios factores, como son la adaptación a las necesidades de funcionamiento de la compañía, la interrelación con el resto de los sistemas existentes, el cumplimiento de las exigencias regulatorias, etc. Habitualmente se trata de un proceso largo y complejo, que requiere la dedicación de un grupo de trabajo especializado que participe a distintos niveles en cada una de las etapas del proyecto.
Una de las etapas fundamentales del Ciclo de Vida del software tal y como se define en GAMP 5 es la etapa de Verificación o Validación. Se trata de una etapa que consume una gran cantidad de recursos, y cuyo éxito depende en gran medida de la correcta planificación y ejecución de las etapas anteriores. Por tanto, para que la etapa de Validación se lleve a cabo de forma satisfactoria, debemos poner especial énfasis en el desarrollo de las Especificaciones de Usuario (URS) y el control de las etapas de diseño (FS, DS).
¿Quieres saber cuáles son los problemas más habituales que podemos encontrar durante la etapa de validación y que podrían resolverse con una gestión eficaz de la etapa de diseño?
¡Te lo contamos ahora mismo!
1. Seguridad de accesos insuficiente
La gestión de los permisos de usuario en el sistema es un punto clave para garantizar la integridad de los datos. Por lo tanto, es fundamental que el sistema proporcione una capacidad adecuada para la configuración y gestión de los distintos niveles de usuario que serán necesarios para la operación con el software. El sistema debe permitir la creación de perfiles con diferentes niveles de acceso, que deben ser coherentes con las responsabilidades y cualificación del personal dentro del organigrama de la compañía. En ocasiones, los sistemas no permiten la creación de suficientes niveles de acceso, y no permiten la configuración detallada de cada uno de ellos, poniendo en riesgo la seguridad de los datos.
Las capacidades del sistema deben, además, complementarse con las herramientas adecuadas a nivel del Sistema de Gestión de Calidad. Es decir, deben definirse adecuadamente las responsabilidades sobre el sistema (System Owner, Process Owner, Administrador, usuarios de distintos niveles, etc.) y debe proporcionarse la formación adecuada a cada uno de los niveles para el desarrollo de sus actividades. Es fundamental además desarrollar una política para la actualización permanente de los permisos de acceso ante nuevas altas o bajas en la compañía, cambios de funciones, cambios de responsabilidades, etc.
Por otra parte, el sistema debe incorporar una serie de medidas para evitar el uso indebido de las credenciales de acceso, como son la desconexión programada transcurrido un tiempo de actividad, la renovación periódica de la contraseña, el bloqueo tras accesos fallidos, la firma de las operaciones críticas, etc. También en este sentido debemos acompañar las características que nos brinda el sistema informático con una gestión adecuada a nivel del Sistema de Gestión de Calidad. Debemos evitar prácticas incorrectas como el uso compartido de perfiles genéricos (usuarios tipo “almacén” o “admin” de uso múltiple), la disposición de las credenciales de acceso de forma pública (por ejemplo, escritas en un post-it sobre la pantalla del ordenador). Es fundamental concienciar a todos los usuarios del sistema de la trascendencia de mantener sus credenciales de acceso de forma personal y privada.
2. Audit Trail inaccesible o incompleto
El Sistema debe contar con una herramienta para registrar todas las acciones llevadas a cabo sobre el mismo, incluyendo fecha y hora de realización, usuario implicado y sentido de la acción realizada (creación, modificación o eliminación de registros). Existen aún sistemas que carecen de esta funcionalidad, o que permiten su desactivación por parte del usuario con determinado nivel de acceso, como, el administrador (sí, todavía existen, y debemos huir de ellos).
Durante la fase de selección del sistema y definición de requisitos de usuario es fundamental trasladar al desarrollador o proveedor la importancia de esta funcionalidad, ya que de otro modo no podremos garantizar la integridad de los datos que se han generado o almacenado en el sistema.
Además este Audit Trail debe ser accesible para verificación por el personal con la autoridad suficiente. Es crítico que la información que contenga sea completa y accesible, y que además esté almacenada de forma segura para evitar pérdidas o manipulaciones.
El Sistema de Calidad debe adecuarse también a estos requisitos, definiendo la política de revisión de Audit Trail para el sistema informático (periodicidad, responsabilidades, operativa, registros conservados, etc.). ¿Cuándo debemos revisar el Audit Trail? En el caso de registros asociados a un lote es fácil. Cada lote, como parte del proceso de revisión de documentación para su liberación. Pero ¿y en el caso de registros no necesariamente asociados a lotes? Por ejemplo, Audit Trail del gestor documental, del sistema de gestión de desviaciones, del sistema de monitorización ambiental de las cámaras de estabilidad… En estos casos debemos definir una frecuencia adecuada, en base al riesgo de cada sistema.
3. Seguridad de los datos insuficiente
Los datos generados y almacenados en el sistema deben mantenerse accesibles, legibles y protegidos frente a eliminación o modificación durante todo su tiempo de retención. El sistema, por tanto, debe proporcionar suficiente seguridad en este sentido, tanto “dentro” de la propia aplicación como “fuera”. Por tanto, la infraestructura sobre la que opera el software debe proporcionar suficiente nivel de protección para los datos.
Una vez más, el Sistema de Calidad debe garantizar que se mantienen estos criterios, desplegando las medidas de seguridad tanto lógica como física adecuadas, desarrollando procedimientos adecuados para la realización y verificación periódica de copias de seguridad, planificando las acciones a tomar en caso de contingencia, etc.
4. Flujo de trabajo inapropiado
El Sistema informático debe adaptarse a las necesidades operativas de la compañía, y desempeñar correctamente sus funciones, incluyendo la comunicación con otros sistemas de la compañía o con sistemas de agentes externos como proveedores o clientes.
Claro, ¡faltaría más! Sin embargo, los sistemas no siempre hacen lo que queríamos que hicieran. Para evitar encontrarnos con problemas de este tipo es fundamental trasladar al desarrollador o proveedor estas necesidades, y verificar durante las etapas de implantación y validación que se han traslado todos los requisitos al flujo de trabajo de la aplicación, o bien adaptar las actividades a las posibilidades que ofrece el sistema.
Como hemos visto, la Validación del Software debe sustentarse en una serie de pilares que se construyen en las etapas tempranas del proyecto (definición de requisitos y verificación de especificaciones funcionales y de diseño) y se complementan durante la etapa de utilización del sistema (definiendo las políticas adecuadas para la gestión del sistema una vez implantado). Debemos por tanto concebir la Validación del Software como una etapa del ciclo de vida del sistema, y no como un hito aislado o un objetivo final. Una vez concluida la validación, la gestión del sistema debe asegurar que se mantienen las condiciones adecuadas para garantizar la integridad de los datos y el cumplimiento de las expectativas regulatorias. Por tanto, tras la validación, el reto y el compromiso continúan.
¿Tienes un proyecto de implantación de software y necesitas ayuda? Podemos acompañarte durante todo el proceso para alcanzar el éxito. Podemos ayudarte en la definición de requisitos con tu proveedor, en la Evaluación de Riesgos del sistema, durante la Validación y durante la adaptación de tu Sistema de Calidad para la gestión del sistema, garantizando la integridad de los datos durante todo el ciclo de vida del software.
Déjanos tus datos y contactaremos contigo Solicita presupuesto