• Buscar:
    30Sep, 2024
    Entregables documentales para la calificación de sistemas computarizados.

    La calificación de un sistema computarizado es un proceso documental que requiere enfoque, orden y consistencia lógica para llevar a buen puerto el proceso deseado. En ocasiones pensamos que los entregables documentales para validación de sistemas computarizados difieren según sea el caso de sistemas a validar. Lo más factible es que los procesos de validación sean estructurados y sistemáticos. De esta manera podremos establecer procesos o procedimientos replicables para estas actividades. ¿Pero que entregables documentales son los que se deben generan y mostrar ante una inspección regulatoria?

    En este articulo te compartimos los documentos y su alcance dentro del proceso de calificación de sistemas computarizados para los sectores farmacéutico, almacenes y de dispositivos médicos.

    El siguiente proceso lógico documental te servirá para procesos y proyectos de calificación de sistemas computarizados, tales cuales son: ERP, SAP, software personalizado, Software comercial, CRM, Plataformas Web y Hojas de cálculo.

    ACUERDO DE NIVEL DE SERVICIO (SLA)

    Un acuerdo de nivel de servicio es un documento de base legal y calidad. En este documento se establecen los alcances del proyecto. Así como, los entregables documentales, tiempo y responsabilidades entre el cliente-proveedor. Es importante, que este documento considere mencionar y acordar la estructuración de los procesos de actualización y la obtención de documentos de soporte como controles de cambio hacia el cliente para favorecer el mantenimiento del estado validado del servicio obtenido.

    ANÁLISIS DE RIESGO

    Un análisis de riesgo es un documento que establece como base la detección de eventos que pudiesen suceder durante el proceso de validación. Es decir, este documento establece eventos críticos y/o relevantes del sistema que deben ser cumplidos por el sistema. Y según aplique, el detalle de acciones a considerar si el sistema “per-se” manifiesta la falta de requerimientos normativos y de cumplimiento en integridad de datos. Se recomienda, que en este documento también se incluya la categorización del software a calificar-validar. Conoce acerca de las categorías de software aquí>>https://deappharma.com/gamp-5-y-la-categorizacion-de-software/

    PLAN DE VALIDACIÓN

    El plan de validación es un documento que establece como su nombre lo indica un plan de validación. Este plan establece de manera detallada las siguientes tareas:

    • Definir la estrategia de la calificación-validación que se aplicara.
    • Determinar los entregables que se generaran en cada actividad.
    • Identificar el equipo de calificación-validación y pruebas junto con su responsabilidad para la finalización de cada actividad.
    • Definir el procedimiento para las pruebas de calificación-validación.

    ESPECIFICACIONES

    Las especificaciones son la base documental para la estructuración de pruebas y evidencias. Dentro del proceso de calificación deben existir tres principales actores:

    • Especificación de requerimientos de usuario de software: este documento establece y define de manera puntual cada requerimiento de usuario solicitado y cada requerimiento regulatorio que deberá ser evaluado con la determinación de su entregable. Este documento del sistema detalla: ambiente, propósito y manejo de datos, funciones de entrada, función de proceso, funciones de salida, funcione generales, características de usuarios, restricciones, suposiciones dependencias, requerimientos futuros, requerimientos de rendimiento requerimientos específicos, copias de seguridad, archivo y restauración y requisitos de conservación.
    • Especificación de diseño: este documento establecer y define de manera puntual los detalles de infraestructura y técnicos que se requieren para que el sistema funcione y se instale correctamente. Este documento detalla: plataforma y entorno, interfaces, ajuste de configuración, nombre, versión, modelo, código, recuperación y requisitos.
    • Especificación funcional: este documento establece y muestra barra de funciones, así como el alcance de cada una de ellas en un entorno productivo.

    PROTOCOLOS DE CALIFICACIÓN

    El protocolo de calificación es un documento que establece las instrucciones para llevar a cabo cada etapa del proceso. Este documento está estrechamente vinculado a las especificaciones y su entregables. Este documento puede ser uno solo o, segmentado a cuatro protocolos de calificación. Es importante mencionar, que, aunque la normativa no define que necesariamente deben ser protocolos. Se debe tener en cuenta que no se puede avanzar de etapa de calificación hasta haber concluido la previa en la cual no se determinen eventos críticos que detenga en proceso.  De cualquier forma, el o los protocolos deben mostrar las instrucciones de verificación del diseño, instalación, operación y desempeño del sistema a dictaminar.

    • Protocolo de diseño: es el documento que establece las instrucciones de trabajo con base en las especificaciones de diseño previamente autorizadas.
    • Protocolo de instalación: es el documento que establece las instrucciones con base en la documentación del sistema y el sistema de gestión de la calidad del negocio. Así como, consideraciones del fabricante para llevar a cabo la instalación. Importante mencionar que esta etapa de instalación debe incluir como parte de su evaluación las operaciones de configuración del sistema.
    • Protocolo de operación: es el documento que establece las instrucciones. Con base base, en la especificación de requerimientos de usuario de software. Esta etapa, define la evaluación de operaciones de entrada y proceso del sistema.
    • Protocolo de desempeño: es el documento que establece las instrucciones de pruebas que se establecen con base en las especificaciones de funcionalidad sobre un proceso real de trabajo. Esta etapa define pruebas de transacciones generales estructuradas bajo eventos reales de trabajo.

    REPORTE DE CALIFICACIÓN

    El reporte de calificación es un documento que establece los resultados finales cada etapa del proceso. Este documento está estrechamente vinculado al o los protocolos de calificación. Este documento puede ser uno solo o, segmentado a cuatro reportes de calificación. Es importante mencionar, que, aunque la normativa no define que necesariamente deben ser reportes. Se debe tener en cuenta que no se puede avanzar de etapa de calificación hasta haber concluido el reporte previo en la cual no se hallan determinado eventos críticos que detenga en proceso.  De cualquier forma, el o los reportes deben mostrar los resultados, hallazgos y acciones determinada en cada etapa que ha sido verificada par el: diseño, instalación, operación y desempeño.

    MATRIZ DE TRAZABILIDAD

    La matriz de trazabilidad es un documento en formato de tabla preferentemente que relaciona uno de los requerimientos con los entregables que se hayan solicitado. Este cuadro es de doble sentido ya que permite identificar que se resultado se alcanza a través de cada requisito y a la vez, que requisitos son los que permite obtener un entregable como resultado reportable.

    CONCLUSIÓN

    Un proceso de calificación ordenado, conciso y detallado tiene como principal beneficio el cumplimiento regulatorio.

    Te invitamos a recibir nuestro apoyo en proyectos de calificación de sistemas computarizados. Nuestra esencia como empresa en el desarrollo de software y nuestro enfoque en el sector regulado te brinda el ¿Qué? y ¿Cómo? llevar a buen puerto tu proyecto.

    ¡Recuerda!  que en deappharma tienes un aliado para realizar la validación de sistemas computarizados. ¡Con nuestro método obtendrás el cumplimiento requerido!

    Nuestro servicio te da acceso a un beneficio totalmente gratis por un año. Este beneficio consiste en implementar eDocuSeed  un software que centraliza todos tus libros de Excel y documentos en un solo punto. De esta manera les brindamos los atributos de integridad de datos, trazabilidad y mantenimiento necesarios para dar cumplimiento a las regulaciones más exigentes. Nuestra solución ya impacta de manera positiva a empresas del sector farmacéutico en México y Sudamérica. Solicita tu demostración totalmente gratuita. ¡Estamos listos para ayudarte!

    Contáctanos y solicita una demostración y asesoría gratuita ¡Quiero un asesoría y demostración!

    ¡Gracias por leernos!

    12Abr, 2023
    Definiendo los requerimientos de usuario

    Una clave muy importante para la validación del software y libros de Excel es una especificación documentada de los requisitos que defina:

    – el «uso previsto» del software, libro de Excel o equipo automatizado; y

    – la medida en que el fabricante del producto depende de ese software, libro de Excel o equipo para la producción de un producto sanitario de calidad.

    El fabricante del producto (usuario) tiene que definir el entorno operativo previsto, incluyendo cualquier configuración de hardware y software necesarias, versiones de software, utilidades, etc. El usuario también debe:

    – documentar los requisitos de rendimiento del sistema, calidad, gestión de errores, puesta en marcha, apagado, seguridad, etc;

    – identificar cualquier función o característica relacionada con la seguridad, como sensores, alarmas, enclavamientos, pasos lógicos de procesamiento o secuencias de comandos; y

    – definir criterios objetivos para determinar el rendimiento aceptable.

    La validación debe realizarse de acuerdo con un protocolo documentado, y los resultados de la validación también deben documentarse. Deben documentarse los casos de prueba que pongan a prueba el rendimiento del sistema con respecto a los criterios predeterminados, especialmente para sus parámetros más críticos.

    Los casos de prueba deben abordar las condiciones de error y alarma, el arranque, el apagado, todas las funciones de usuario y controles de operador aplicables, posibles errores de operador de valores permitidos y las condiciones de estrés aplicables al uso previsto del equipo. Los casos de prueba deben ejecutarse y los resultados deben registrarse y evaluarse para determinar si los resultados permiten concluir que el programa informático está validado para el uso previsto.

    Un fabricante de productos puede llevar a cabo una validación utilizando su propio personal o puede depender de un tercero, como el fabricante del equipo/software tercero, o un consultor. En cualquier caso, el fabricante del producto conserva la responsabilidad última de garantizar que el software del sistema de producción y calidad:

    – se valide de acuerdo con un procedimiento escrito para el uso concreto previsto; y

    – funcionará según lo previsto en la aplicación elegida.

    El fabricante del producto debe disponer de documentación que incluya

    – los requisitos de usuario definidos

    – el protocolo de validación utilizado

    – los criterios de aceptación

    – casos de prueba y resultados; y

    – un resumen de validación que confirme objetivamente que el software y/o Libros de Excel está validado para el uso previsto.

    ¿Existen herramientas en el mercado que mejoren los procesos administrativos y de laboratorio?

    Como bien sabemos el desafío más grande al que se a puesto a prueba el sector farmacéutico es el relacionado con la integridad de datos. ¡Pero! ¿Por qué es tan complejo este tema? La respuesta se deriva por la gran cantidad de datos y documentos que se emiten día con día en el que se ven impactados documentos y libros de Excel. 

    Recordemos que la validación de software y libros de Excel es el primer paso. No obstante, muchos libros de Excel utilizados en el sector farmacéutico no cuentan con evidencia de validación lo cual es un riesgo que podrá derivar en un hallazgo critico ante una inspección regulatoria.

    El segundo paso y el más complejo es adherir las configuraciones necesarias que eleven la integridad de datos y favorezcan el mantenimiento tanto de software como de Libros de Excel.

    Te invitamos a mitigar el riesgo por el uso de sistemas computarizados no validados y con pobres atributos de integridad de datos. Nuestros desarrollos están estructurados bajo un sistema de gestión de calidad trazable y auditable. Tales cuales cuentan con el soporte de validación-calificación documental con base en Gamp 5 y CFR21 parte 11.

    Conoce eADMxL el cual es un software que desarrollamos para mitigar el uso de hojas de cálculo para procesos de validación de métodos analíticos. Conoce sus beneficios y alcance general aquí:  ¡Da clic aquí!

    eDocuSeed es más que un software de gestión documental ya que este es capaz de controlar y mantener libros de Excel por medio de adición de controles necesarios para: acceso, edición, trazabilidad y su mantenimiento. Conoce sus beneficios y alcance general aquí: ¡Da clic aquí!

    “No vivas con el riesgo ¡Mitígalo!” para eso nosotros de ayudamos.

    Visita nuestro sitio www.deappharma.com y solicita una demostración y asesoría gratuita.

    ¡Contáctanos! y conoce de que manera te vamos a ayudar.

    ¡Únete a nuestra comunidad en redes!

    2May, 2022
    Características de un buen SRS (Software Requirements Specification) especificación de requerimientos de software

    La especificación de requisitos de software (SRS) es una descripción completa del comportamiento del sistema que se va a desarrollar. Incluye un conjunto de casos de uso que describe todas las interacciones que tendrán los usuarios con el software. Los casos de uso también son conocidos como requisitos funcionales. Además de los casos de uso, la ERS también contiene requisitos no funcionales (complementarios). Los requisitos no funcionales son requisitos que imponen restricciones en el diseño o la implementación, como, por ejemplo, restricciones en el diseño o estándares de calidad.

    Está dirigida tanto al cliente como al equipo de desarrollo. El lenguaje utilizado para su redacción debe ser informal, de forma que sea fácilmente comprensible para todas las partes involucradas en el desarrollo.

    Las características de un buen SRS son:

    • Sin ambigüedades
    • Completa
    • Verificable
    • Coherente
    • Modificable
    • Trazable
    • Utilizable durante la fase explotación y mantenimiento

    Cada característica se aborda con mayor detalle a continuación:

    Sin ambigüedad. Una SRS es inequívoca si- y solo si- cada requisito en ella tiene una única interpretación.

    • Como mínimo, esto requiere que cada característica del producto final se describa utilizando un único termino.
    • En los casos en los que un término utilizado en un contexto particular pueda tener múltiples significados, el termino debe incluirse en un glosario donde se especifique su significado.

    Completa. Un SRS es completo si posee las siguientes cualidades:

    • Inclusión de todos los requisitos significativo, ya sean relativos a la funcionalidad, el rendimiento, las limitaciones de diseño, los atributos o las interrelaciones externas.
    • Definición de las respuestas de software a todas las clases realizables de datos de entrada en todas las clases realizables de situaciones. Obsérvese que es importante especificar la respuesta a los valores de entrada válidos y no validados.
    • Conformidad con cualquier norma del SRS que le sea aplicable. Si una sección particular de la norma no es aplicable, el SRS debe incluir el número de sección y una explicación de porque no es aplicable.

    Verificable. Un SRS es verificable si, y solo si, todos los requisitos establecidos en el son verificables. Un requisito es verificable si y solo si existe algún proceso finito y rentable con el que una persona o máquina pueda comprobar que el producto de software cumple con el requisito.

    • Ejemplos de requisitos no verificables, estas son declaraciones como: a)El producto debe funcionar bien, o el producto debe tener una buena interfaz humana. Estos requisitos no pueden verificarse porque es imposible definir los términos bueno o bien. b)El programa nunca debe entrar en un bucle infinito. Este requisito no es verificable porque la comprobación de esta cualidad es teóricamente imposible.

    Coherente. Un buen SRS es consistente si y solo si ningún conjunto de requisitos individuales descritos en ella entra en conflicto. Hay tres tipos de conflictos principales en un SRS:

    • Dos o más requisitos pueden describir el mismo objeto del mundo real, pero utilizar termino diferentes para ese objeto. Por ejemplo, la solicitud de una entrada de usuarios por parte de un programa puede denominarse “prompt” en un requisito y “cue” en otro.
    • Las características especificadas de los objetos del mundo real pueden entrar en conflicto. Por ejemplo: 1)El formato de un informe de salida puede describirse en un requisito como «tabular” pero en otro como “textual” 2) Un requisito puede establecer que todas las luces deben ser verdes mientras que otro establece que todas las luces deben ser azules. 3) Puede haber un conflicto lógico o temporal entre dos acciones específicas. Por ejemplo; a) Un requisito podría especificar que el programa sumará dos entradas y otro especificar que el programa las multiplicará. b) Un requisito puede establecer que A debe seguir a B, mientras que otros requieren que A y B ocurran simultáneamente.

    Modificable. Un SRS es modificable si su estructura y estilo son tales que cualquier cambio necesario en el requisito puede realizarse de forma fácil, completa y coherente. Los cambios en un SRS generalmente requieren:

    • Tener una organización coherente y fácil de usar, con un índice y referencias cruzada explicitas.
    • No ser redundante; es decir, el mismo requisito no debe aparecer en otras partes en el SRS.

    Trazable. Una SRS es trazable si el origen de cada uno de sus requisitos es claro y se facilita la referencia de cada requisito de la futura documentación de desarrollo o mejora. Se recomiendan dos tipos de trazabilidad:

    • La trazabilidad hacia atrás (es decir, hacia etapas anteriores de desarrollo) depende de que cada requisito haga referencia explícita a su fuente en documentos anteriores.
    • La trazabilidad hacia adelante (es decir, hacia todos los documentos generados por el SRS) depende que cada requisito del SRS tenga un nombre o número de referencia único.

    Utilizable durante la fase de operación y mantenimiento. El SRS debe atender las necesidades de la fase de operación y mantenimiento, incluyendo la eventual sustitución del software.

    • El mantenimiento suele ser realizado por personal no relacionado con el desarrollo original. Los cambios locales (correcciones) pueden aplicarse mediante un código. Si embargo, para los cambios de mayor alcance, la documentación sobre el diseño y los requisitos es esencial. Esto implica dos acciones:
    • El SRS debe ser modificable
    • El SRS debe contener un registro de todas las disposiciones especiales que aplican a los componentes individuales, tales como:
    • Su criticidad
    • Su relación con las necesidades sólo temporales.
    • Su origen
    • Este tipo de conocimiento se da por sentado en la organización de desarrollo, pero a menudo falta en la organización de mantenimiento. Si no se entiende la razón o el origen de una función, a menudo es imposible realizar un mantenimiento adecuado del software.

    No olvides que todas nuestras soluciones son liberadas bajo un sistema de calidad robusto. En caso de ser necesario, puedes contactarnos para mejorar el proceso de laboratorio y administrativo de tu organización a través software 100% confiable y seguro. Recuerda que en deappharma contamos  con una suite de herramientas que te ayudaran a mejorar tus procesos con un enfoque en integridad de datos. Somos expertos en la materia, por lo que procesos complejos no representa un reto para nosotros, debido a que tenemos en mente los aspectos relevantes de cumplimiento.

    Referencias

    • FDA, Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices

    • GAMP 5 Guide: Compliant GxP Computerized Systems

    • Guía del IEEE sobre especificaciones de requisitos de software ANSI/IEEE std 1984.

    ¡Contáctanos! y conoce de que manera te vamos a ayudar.

    ¡Únete a nuestra comunidad en redes!