20, May 2022
Linealidad del sistema
Es la capacidad del método analítico para obtener resultados directamente proporcionales a la concentración o cantidad del analito en un rango definido.
La linealidad puede demostrarse directamente en la sustancia farmacológica (mediante dilución de una solución madre estándar) y/o pesadas separadas de mezclas sintéticas de los componentes del producto farmacéutico, utilizando el procedimiento propuesto. Este último aspecto puede estudiarse durante la investigación en el rango definido. La linealidad debe evaluarse mediante la inspección visual de un gráfico de señales en función de la concentración o el contenido del analito. Si existe una relación lineal, los resultados del ensayo deben evaluarse mediante métodos estadísticos apropiados, por ejemplo, mediante el cálculo de una línea de regresión por el método de los mínimos cuadrados. En algunos casos, para obtener la linealidad entre los ensayos y las concentraciones de la muestra, puede ser necesario someter los datos del ensayo a una transformación matemática antes del análisis de regresión. Los datos de la línea de regresión pueden ser útiles para proporcionar estimaciones matemáticas del grado de linealidad.
Deben presentarse valores tales como:
Coeficiente de correlación (r). Muchos autores planteanque para que el método se considere lineal, el coeficiente de correlación debe ser mayor que 0,999. Sin embargo, la mejor forma de indicar la linealidad del método estudiado será realizar una prueba estadística de t (t de Student), en la cual se calculará la correlación lineal significativa (tr) a partir de la hipótesis nula de no correlación entre las magnitudes estudiadas («x» y «y«).
Pendiente (conocida también como coeficiente de regresión). Indica la sensibilidad de calibración o del método y se expresa en unidades de respuesta sobre unidades de concentración o cantidad del analito. La sensibilidad analítica relaciona la aleatoriedad de la respuesta con la aleatoriedad debida a la variación de la concentración, es inversamente proporcional a la capacidad de detectar pequeñas diferencias en la concentración del analito, y se obtiene dividiendo la pendiente de la curva de calibración por la desviación estándar de las respuestas en cada punto o concentración. Se considera que, a mayor pendiente, mayor sensibilidad y que mientras más pequeño sea el coeficiente de variación de la pendiente mayor será la linealidad (coeficientes de variación de la pendiente mayores que el 5,0 % indican falta de linealidad).
Intercepto. Es el estimador que se relaciona con la presencia de interferencias o errores sistemáticos. El intervalo de confianza del intercepto debe incluir al cero para cumplir con el requisito de proporcionalidad (como se exige para el cumplimiento de la ley de Lambert-Beer en los métodos espectrofotométricos). Se determinará la prueba de proporcionalidad mediante una prueba t considerando como hipótesis nula que el intercepto tiene que ser cero.
La intersección y la pendiente de la línea de regresión, así como la suma residual de los cuadrados. Debe incluirse un gráfico de los datos (reporte). Además, deberá presentarse un análisis de la desviación de los puntos de datos reales con respecto a la línea de regresión puede ser útil para evaluar la linealidad.
Algunos procedimientos analíticos, como los inmunoensayos, no demuestran linealidad
después de cualquier transformación. En este caso, la respuesta analítica debe describirse mediante una función apropiada de la concentración (cantidad) de un analito en una muestra. Para establecer la linealidad, se recomienda un mínimo de 5 concentraciones. Deberán justificarse otros enfoques.
Proceso de linealidad del sistema controlado y gestionado con eADMxL.
No olvides que, 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 un software que te ayudara a controlar tu proceso de validación de métodos analíticos. 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
- Rampazoo P. Standardisation and validation of analytical methods in the pharmaceutical industry. Il Farmaco 1990; 45:807-15.
- Comellas L. Desarrollo de métodos en HPLC. Barcelona: Instituto Químico de Sarria, 1994:68.
- VALIDATION OF ANALYTICAL PROCEDURES: TEXT AND METHODOLOGY Q2(R1)
¡Contáctanos! y conoce de que manera te vamos a ayudar.
¡Únete a nuestra comunidad en redes!
- 0
- Por Team deappharma
15, May 2022
Idoneidad del sistema (HPLC, MS-HPLC)
Las pruebas de idoneidad del sistema son una parte integral de muchos procedimientos analíticos. Las pruebas se basan en el concepto de que el equipo, la electrónica, las operaciones analíticas y las muestras a analizar constituyen un sistema integral que puede ser evaluado como tal. Los parámetros de las pruebas de idoneidad del sistema que deben establecerse para un procedimiento concreto dependen del tipo de procedimiento que se valide.
La evaluación de la aptitud del sistema se recomienda para todos los métodos analíticos, ya que permite verificar que el sistema de medición funciona apropiadamente, independientemente de las condiciones ambientales. Es conveniente que antes de llevar a cabo la validación del método analítico, se establezcan los criterios apropiados para la operación del sistema de medición, para ser evaluados en la validación y verificados de manera rutinaria al emplear el método analítico.
Métodos cromatográficos
La solución de aptitud del sistema se establece en el desarrollo del método y puede ser una solución del analito al 100 % del rango de linealidad o más concentrado. Puede ser una mezcla del analito con otro componente para verificar la resolución del analito y su(s) compuesto(s) de degradación o relacionados (ya sea agregándolos o degradando la muestra).
Metodología
La evaluación se recomienda con la inyección por sextuplicado la solución de aptitud del sistema. Calcular el Coeficiente de Variación (CV) del analito y se procede reportar.
- Factor de capacidad (K’)
- Resolución (R)
- Tailing ( T )
- Platos teóricos (N)
- Factor de coleo
Los valores mínimos y/o máximos para cada uno de los parámetros anteriores, son los siguientes:
- Factor de capacidad (K’) > 10 (recomendable)
- Coeficiente de variación (CV) ≤ 2% para proceso de valoración, disolución y ≤ 20% para procesos de evaluación de impurezas individuales.
- Resolución (R) > 1.5 (recomendable si se observa la presencia de productos de degradación y/o impurezas)
- Tailing ( T ) <1>
- Factor de coleo >2.5
Actualmente los procesos y evaluación de métodos analíticos por cromatografía liquida (HPLC, MS-HPLC etc..) establecen como parámetro de evaluación la idoneidad del sistema. Sin embargo como proceso integral de la validación de métodos analíticos esta prueba debe formar parte evaluada de este. De esta manera podemos obtener de manera verificable el inicio de las condiciones de validación.
Las pruebas de idoneidad del sistema son pruebas que deben ser evaluadas previamente a lanzar alguna corrida analítica, con el objetivo de verificar que las condiciones del sistema son optimas para llevar a cabo el análisis. La idoneidad del sistema siempre debe ser evaluada con soluciones de referencias, es decir estándares. No es sugerible que la idoneidad incluya la inyección y previsualización de resultados (áreas) de muestras. Ya que esta acción de inyección de muestras previamente a lanzar la corrida analítica, son consideradas actualmente malas practicas de laboratorio en lo asociado a integridad de datos.
Recordemos que la idoneidad del sistema debe formar parte integral del proceso de validación de manera inicial ya que esta es una buena referncias para determinar el momento de fallo y establecer limites de especificaciones vinculadas a este parametro de desempeño.
Proceso de idoneidad controlado y gestionado con eADMxL.
No olvides que, 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 un software que te ayudara a controlar tu proceso de validación de métodos analíticos. 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
- VALIDATION OF ANALYTICAL PROCEDURES: TEXT AND METHODOLOGY Q2(R1)
¡Contáctanos! y conoce de que manera te vamos a ayudar.
¡Únete a nuestra comunidad en redes!
2, May 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!
