Cualquier evaluación de integridad de datos dentro de una operación de laboratorio manual o electrónica debe basarse sobre un análisis de riesgo vs. las características detalladas en la tabla adjunta y utilizando el ciclo de vida de los datos (recolección, procesamiento, revisión y reporte de los datos).

imagen12_integridad-de-datos

Característica Definición
Atribuible ¿Quién adquirió los datos o realizó una acción y cuándo? Si un registro es modificado por quién y porqué.

Esto debería ser claro quien crea un registro y cuando. De todos modos, debería ser claro quien hace una enmienda en un registro, cuando y porqué.

Legible Los datos deben ser registrados de forma permanente en una forma duradera y fácil de leer.
Contemporáneo Los datos deben ser registrados al mismo tiempo que el trabajo es efectuado con marca de fecha y hora.

Esto significa que la evidencia o los resultados de los tests son registrados como son observados, de esta forma permite la reconstrucción de los eventos alrededor de los datos.

Original La información registrada deben ser datos originales (datos crudos) o una copia certificada del proceso.

Los datos NO deben ser transcritos de u a fuente a otra sin justificación y control certificado del proceso in place.

Exacto Sin errores o ediciones efectuadas sin enmiendas en los documentos.

La información registrada es correcta.

El análisis de riesgo es el proceso de identificar los peligros y los modos de falla y evaluar las consecuencias potenciales de esos peligros. Esto es críticamente dependiente de que la gente con el correcto conocimiento sea involucrada.

Los análisis de riesgos de calidad comienzan con una descripción bien definida del problema, una pregunta de riesgo o un análisis de un área de riesgo particular. En el caso de integridad de datos el proceso de laboratorio individual debe ser mapeado en detalle, comenzando por la preparación de la muestra, a través de los resultados de verificación / aprobación y finalizando con el archivo y recuperación de los datos.

Una vez que el proceso fue analizado para las áreas de riesgo crítico de integridad de datos, por ej. cuál es el riesgo y que impacto podría tener sobre la calidad del producto y la seguridad del paciente, entonces pueden ser asignadas etapas de mitigación.

El proceso de análisis debe seguir las siguientes preguntas (por ejemplo):

  • ¿Qué podría salir mal?
    • Datos han sido perdidos
    • Los sistemas fallan y no hay un plan de business continuity (continuidad del negocio) in place
    • Los datos no están siendo registrados
    • Los datos no están siendo verificados
    • El audit trail no está siendo revisado
    • El audit trail no está encendido
    • El entrenamiento y la concientización del instrumento es inadecuado
    • Los passwords están siendo compartidos
    • Los resultados no son atribuibles, etc.
  • ¿Cuál es la probabilidad de que esto salga mal?
  • ¿Cuáles son las consecuencias (severidad) para la calidad del producto o la seguridad del paciente?
  • La falla ¿Será detectada? ¿Cómo?

Hay muchas herramientas y técnicas que pueden ser usadas para ayudar a identificar peligros y /o modos de fallas y evaluar los riesgos. No hay una sola herramienta o técnica que cumpla con todos los requerimientos.

Kintsugi es el arte japonés de arreglar las roturas de la cerámica, con barniz espolvoreado con polvo de oro, plata o platino, de modo de resaltar las cicatrices. Forma parte de una filosofía que plantea que las roturas y reparaciones son parte de la historia de un objeto y deben mostrarse en lugar de ocultarse. Esto mejora el objeto, poniendo de manifiesto su transformación e historia.

kintsugi

El  kintsugi (en japonés carpintería de oro) se remonta a finales del siglo XV cuando el shōgun, Ashikaga Yoshimasa envió a China, para ser reparados, dos de sus tazones de té favoritos. El resultado no fue de su agrado, así que buscó artesanos japoneses que hicieran una mejor reparación, dando así con una nueva forma de reparar cerámicas, convertida en arte. De esa manera se da el caso de que antiguas piezas reparadas mediante este método sean más valoradas que piezas que nunca se rompieron.

Si queremos que la documentación le agregue valor a nuestras actividades, esta debe exponer lo ocurrido, sólo así será el soporte de lo realizado cuando necesitemos apelar a ella.

Control de cambios es un término común para describir el proceso del manejo de cómo los cambios son introducidos dentro de un sistema controlado.

La mayoría de los problemas de los softwares y sistemas computarizados son introducidos cuando son efectuados cambios durante el uso de los mismos. El control de cambios es requerido para asegurar que los sistemas validados permanecen bajo control aun cuando son sometidos a cambios.

La falta de documentación y pobres testeos después de los cambios son unas de las principales observaciones de las auditorías. De ahí la importancia de disponer de un sistema de control de cambios robusto.

El proceso de control de cambios

cambio

Los sistemas computarizados no son estáticos y requieren un programa de mantenimiento robusto luego de la validación inicial. Un procedimiento de control de cambios es crítico para asegurar que los cambios son evaluados, documentados, efectuados y seguidos consistentemente a lo largo de su ciclo de vida. Este procedimiento define el proceso a seguir para evaluar la implementación de los cambios.

El proceso de control de cambios está típicamente definido por medio de la propuesta de necesidad de un cambio, la aprobación del mismo, la ejecución del cambio y la aprobación final de todas las actividades y el cierre del control de cambio.

Veamos cada una de las etapas:

  1. Cambio propuesto: el solicitante del cambio efectúa el requerimiento formal del mismo, el cual necesita ser evaluado para asegurar que es apropiado y que el cambio propuesto no impactará negativamente sobre otros aspectos o capacidades del sistema.

El cambio debe ser clasificado, por ej. de emergencia, de rutina, etc. Algunos cambios no esenciales pueden ser reunidos y ejecutados de manera conjunta. Esta clasificación indicará el ritmo de implementación y las actividades asociadas. Es esencial que el procedimiento de control de cambios provea una vía expeditiva para los cambios de emergencia. Estos cambios, frecuentemente son necesarios para corregir problemas en el software o reestablecer operaciones del proceso rápidamente. Si bien los cambios deben ser completados en un período de tiempo muy corto, deben ser implementados de forma controlada. Los cambios de emergencia deben estar sujetos a controles similares a los cambios de rutina. Sin embargo el proceso puede ser relativamente abreviado para el requerimiento del cambio, su evaluación y aprobación para asegurar que los cambios queden hechos rápidamente.

Siempre que sea posible, los cambios de emergencia deben ser testeados antes de la implementación.

Si IT no está plenamente disponible para testear las modificaciones de emergencia antes de su instalación, es crítico que se disponga de apropiados back up de archivos y programas, como también tener un plan de back out in place.

  1. Aprobación y planeamiento: Un equipo multifuncional debe determinar como el cambio podría afectar al sistema antes que el cambio sea efectuado. Este equipo debe incluir al menos al Propietario del sistema, Aseguramiento de Calidad e IT. Dependiendo del análisis de riesgo del cambio, el nivel y rigor de la documentación y los testeos a efectuar.

La aprobación para avanzar con el cambio debe ocurrir antes que cualquier cambio en el sistema sea efectuado.

En el caso de cambio de emergencia (situación urgente) un cambio podría ser aceptado antes de completar el proceso formal del control de cambio. Sin embargo, el mismo debe ser documentado de la misma forma de acuerdo a lo indicado en el procedimiento de control de cambios.

La decisión sobre si aceptar o rechazar un cambio podría ser basada en una serie de preguntas:

  • El cambio es inevitable?
  • El cambio aumenta el beneficio general de la organización?
  • El equipo está disponible para hacer tal cambio?
  • Es mejor hacer el cambio ahora o puede ser mejor diferirlo?
  • El cambio impactará otras áreas o sistemas?

La determinación del impacto ayudará a definir el nivel de testeos requeridos para el sistema.

Adicionalmente la matriz de trazabilidad (MT) es un documento que vincula formalmente los requerimientos de diseño y los testeos a través del proceso de validación.

El análisis de regresión podría indicar la funcionalidad que requiere testeos de regresión así como también un racional sólido para excluir aquellas funciones que no son impactadas por el cambio.

Los siguientes documentos deben ser evaluados para el impacto potencial debido al cambio y sus actualizaciones deberían ser planeadas si son requeridas;

  • Paquete de validación incluyendo URS, especificación de requerimiento técnico (TRS), TM, DQ, IQ, OQ, PQ y plan y reporte de validación
  • Procedimientos para el uso y mantenimiento del sistema

Los cambios deben ser planeados y ejecutados mínimamente involucrando a IT y QA y al propietario del sistema o del negocio. Los cambios deben ser comunicados a todas las áreas y funciones afectadas.

  1. Ejecución del cambio: el cambio es en esta etapa efectuado en un entorno de testeo de manera que puede ser testeado antes de la implementación en productivo. El cambio (y otros aspectos del sistema que pueden haber sido afectados) es testeado para asegurar la exactitud del sistema, confianza y asegurar una performance consistente acorde a su propósito.

El ensayo debe ser documentado y los resultados deben conducir a correcciones y testeos adicionales o confirmar que los resultados finales después del cambio son lo que se pretendía. La documentación asociada con el cambio debe ser además completada.

Los cambios deben ser inicialmente implementados lejos del entorno de producción del sistema validado. Esto asegurará que no son efectuados cambios en el entorno de producción hasta que ellos han sido completamente validados y funcionan bien.

En relación a los sistemas computarizados es recomendable tener algunos entornos virtuales como por ejemplo:

  • Entorno de desarrollo (a veces se lo llaman “sandbox” o arenero), un entorno virtual donde un código / configuración experimental toma lugar, como el configurador / desarrollador está probando diferentes soluciones haciendo testeos preliminares, etc.
  • Sistema de testeo, un entorno virtual usado para testear preliminares del sistema conducidos por IT.
  • Validación, un entorno virtual que está congelado y es representativo de producción, seteado para el testeo de validación y controlado y NO modificable a lo largo de los testeos de validación.
  • Entrenamiento, no siempre usado por todos las compañías para todos los sistemas, un entorno virtual usado para manejar entrenamientos sobre un sistema nuevo o revisado.
  • Producción, es el entorno del negocio vivo o “instancia” del sistema.

El testeo debe verificar lo siguiente:

  • La performance del sistema luego que los cambios son efectuados y que los nuevos cambios no introducen errores que mantienen el sistema fuera de la performance buscada.
  1. Aprobación final / implementación del cambio: la aprobación final para liberar la nueva versión a productivo es concedida basada sobre los resultados de testeos exitosos y luego de disponer del paquete documental completo.

Si es requerido entrenamiento, el personal afectado (por ej. Usuarios, super-users, soporte de IT) deben ser entrenados antes que ellos estén notificados para el uso del sistema o antes de la implementación del sistema en el entorno productivo.

La aprobación final es típicamente concedida por medio del propietario del sistema y aprobada por personal autorizado de QA e IT.

La nueva versión del sistema es entonces liberada para el entorno productivo.

Cuando en una auditoría es incluida la inspección de cualquier sistema computarizado utilizado para un propósito regulado, los inspectores revisan típicamente la documentación del sistema, incluyendo los registros de los cambios, como fueron evaluados y la documentación de los mismos.

Resumiendo:

El proceso de control de cambios es importante para asegurar y evitar potenciales riesgos del negocio. Un proceso de toma de decisión objetivo debe ser usado para determinar el nivel y la complejidad de los cambios propuestos. El nivel del impacto que el cambio podría tener debe ser además determinado y esto nos indicará la profundidad de los testeos y  documentación requerida.

Un proceso de control de cambios es necesario para prevenir inapropiadas modificaciones o modificaciones que conducirán a efectos adversos. Un control de cambio efectivo es un aspecto importante para mantener el estado validado de los sistemas, permitiendo continuas mejoras y previniendo gaps de compliance.

  1. Hay una separación clara de responsabilidades y cooperación entre todo el personal relevante tal como propietario del proceso de negocios, propietario del sistema, una persona calificada de QA e IT?
  2. Hay un Análisis de riesgo documentado efectuado a lo largo del ciclo de vida del sistema computarizado, teniendo en cuenta la justificación para la validación, seguridad del paciente, integridad de datos y la calidad del producto?
  3. La documentación de validación incluye los registros de Controles de Cambios (si los hay) y los reportes sobre cualquier desvío observado durante el proceso de validación?
  4. Hay una URS para cada sistema, donde se describen las funciones esperadas por los usuarios y estas son trazables a lo largo del ciclo de vida de los documentos?
  5. Para la validación de SC customizados / categoría 5 GAMP5, hay un proceso “in place” para asegurar el análisis formal y el reporte de calidad y medidas de la performance para todas las etapas del ciclo de vida del SC?
  6. En el caso que sean transferidos datos a otro formato de datos o sistema. La validación incluye la verificación que los datos no han sido alterados en valor y/o significado durante el proceso de migración?
  7. En el caso que el SC intercambie datos electrónicamente con otros sistemas. Hay chequeos incorporados apropiados para verificar el correcto y seguro ingreso y proceso de los datos, de manera de minimizar los riesgos?
  8. En el caso que sean ingresados datos de forma manual. Hay una verificación adicional efectuada por una segunda persona o medio electrónico validado para asegurar la exactitud de los mismos? La criticidad y las consecuencias potenciales de potenciales errores o datos ingresados de forma incorrecta debería ser cubierta por la gestión de riesgo.
  9. Cómo es la seguridad de los datos frente al daño (tanto física como electrónica)? Los datos almacenados deberían ser chequeados para su accesibilidad, lectura y exactitud. El acceso a los datos debe ser asegurado a lo largo del período de retención.
  10. Es efectuado un back up de los datos de forma regular? La integridad y exactitud del back up de datos y la capacidad para recuperar datos debe ser verificada durante la validación y el monitoreo periódico.
  11. Es posible obtener copias impresas de datos almacenados electrónicamente de forma clara?
  12. Para registros que soportan la liberación del lote, es posible generar impresiones indicando si alguno de los datos ha sido cambiado desde la entrada original?
  13. Hay un “Audit Trail” diseñado dentro del sistema el cual registra todo cambio GMP relevante y las eliminaciones?
  14. Todos los cambios y eliminaciones de datos GMP relevantes son documentadas con una justificación?
  15. Los audit trails están disponibles y convertibles a un formulario comprensible?
  16. Los cambios a un SC son incluidos en un sistema de configuración hecho en una forma controlada de acuerdo a un procedimiento definido?
  17. Todos los SC son periódicamente evaluados para confirmar que ellos se mantienen en un estado validado y están en cumplimiento de las GMP? Las evaluaciones deberían incluir, si es apropiado, el rango actual de funcionalidad, el registro de los desvíos, incidentes, problemas, historial de las actualizaciones, performance, confiabilidad y reportes de estatus de validación.
  18. Hay controles físicos y lógicos, “In Place” para restringir el acceso a los SC a las personas autorizadas? Por ejemplo, uso de claves, tarjetas, código personal con contraseñas, biométricas, para restringir el acceso a áreas del equipamiento computarizado y almacenamiento de datos.
  19. Los sistemas de gestión de datos y documentos están diseñados para registrar la identidad de los operadores que ingresan, cambian, confirman o borran datos incluyendo la fecha y la hora?
  20. Cómo son reportados y evaluados los incidentes? La causa raíz del incidente debe ser identificada y debe ser la base de la acción correctiva (CAPA).
  21. Ha sido efectuada la evaluación de la parte 11 para los sistemas relevantes?
  22. Hay un procedimiento que confirma que la firma electrónica tiene el mismo impacto que las formas manuscritas dentro de los límites de la compañía?
  23. Las firmas electrónicas permanecen relacionadas a sus respectivos registros electrónicos?
  24. Cuando el sistema computarizado es usado para la certificación y liberación de lotes, el sistema permite solo personas calificadas para certificar la liberación de los lotes y claramente identificada y registra la persona que libera y certifica los lotes? Esto podría ser efectuado utilizando una firma electrónica.
  25. Los datos han sido chequeados para su accesibilidad, disponibilidad e integridad?

CSV

El objetivo de la Revisión de Batch Record (BRR) no es simplemente identificar excepciones (errores, olvidos, entradas ilegibles, etc.), tener el registro corregido oportunamente provee una documentación exacta de las etapas que comprenden la manufactura o el empaque del lote en cuestión.

El BR puede ser requerido semanas, meses o incluso años después, para buscar información. Además puede ser solicitado por parte de la agencia, por lo tanto necesitan ser corregidos y ser claros antes de ser archivados.

Si bien la importancia de la Revisión de BR es indiscutible, hay desafíos logísticos en el proceso de corrección. Esto surge desde la necesidad de controlar la BRR y la disponibilidad del personal requerido para hacer las correcciones. Idealmente, todos los errores ingresados deben ser identificados en el departamento revisor antes que el BR vuelva a Aseguramiento de Calidad (QA) para la revisión de calidad.

La revisión debe ser para identificar cualquier información faltante y que las entradas sean correctas y están dentro de los parámetros establecidos.

documentin

Asumiendo sin embargo, que hay una pregunta o corrección requerida a nivel de la revisión de QA, la persona que hizo la entrada original (o falla al hacer la entrada) sobre el BR, cumple con el revisor que identificó la excepción. Esta pregunta o corrección requerida será asentada en el BR para permitir cualquier persona subsecuente entienda el problema.

Cuando una corrección inmediata nos es posible debido a un tema de turno, persona de vacaciones, licencia, etc. entonces el revisor debe informar al supervisor o jefe de la situación para la resolución de la misma.

Hay ocasiones donde falta información vital, la cual no puede ser corroborada a través de registros electrónicos u otros registros. El revisor entonces tiene la responsabilidad de informar esto a quienes son responsables del desvío y la investigación interna. Esta etapa debe ser anotada o remarcada en el BR (debe ser indicada una referencia a la investigación). La terminación de la revisión del BR se demorará hasta que la investigación sea completada y la disposición de la desviación es determinada. La revisión debería ser completada y firmada aún si el batch será retrabajado (si está permitido) o destruido. El BR y el check list y la planilla de correcciones, debe entonces ser enviada al área de QA y el estatus de revisión actualizado en el log o base de datos.

Revisión periódica de los BR revisados

De acuerdo a nuestra experiencia, es de mucha utilidad efectuar una revisión periódica por medio de la supervisión o jefatura o gerencia, dentro de la unidad de calidad para determinar que se está alcanzando la consistencia deseada en el proceso de revisión. Una revisión de las planillas de corrección provenientes de varios revisores proveerá una perspectiva útil sobre el número de excepciones citadas y / o correcciones requeridas, los tipos de excepciones citadas o las correcciones procuradas, y una comparación de los hallazgos de los distintos revisores. La tendencia de los resultados de producción es una herramienta muy útil para detectar desvíos en el proceso de manufactura y a partir de ellos identificar etapas de corrección para ser tomadas. Si el número de correcciones es elevado, entonces uno debe cuestionarse si el personal de manufactura y los revisores de los BR tienen el mismo conocimiento o entendimiento de que constituye una documentación de BR exacta y suficientemente completa. Si existe un desentendimiento, tal vez el entrenamiento inicial para el personal de manufactura, personal calificado, o ambos no fue lo suficientemente detallado, o el lenguaje del BR es ambiguo y debido a esto, puede ser malinterpretado. El objetivo es asegurar que el personal de manufactura y los revisores están trabajando hacia el mismo objetivo de buena documentación.

Desde una perspectiva ligeramente diferente, si el tipo de excepciones o correcciones requeridas es alto para un BR particular, entonces el lenguaje de dicho MBR debería ser cuidadosamente examinado. Si el lenguaje aparentemente es claro, entonces la documentación en cuestión debería ser revisada con el personal de manufactura. La variación es observada principalmente en un turno? Es requerido un entrenamiento adicional? Si el lenguaje es ambiguo, tal vez la próxima etapa es siguiendo los lineamientos del SOP de control de cambios modificar el BR y luego reentrenar el personal.

Finalmente, hay una discrepancia entre los revisores individuales sobre el número y los tipos de excepciones o correcciones observadas? Esta determinación puede llevar a una discusión muy útil y de fina sintonía para hacer el proceso de revisión más consistente entre los revisores.

A continuación les voy a describir 3 situaciones de inconsistencias en el proceso de revisión, las cuales pueden ser detectadas por medio del proceso de análisis periódico y corregido por medio de la intervención de los supervisores.

  • Conveniencia vs exactitud

Si alguna vez han revisado BR, saben que es una tarea tediosa, repetitiva, y demandante. Las etapas requeridas para obtener correcciones de documentos requiere tiempo adicional y seguimiento, un revisor puede caer en el hábito de minimizar el número de correcciones requeridas de un documento como una forma de cerrarlos más rápidamente. Esta es una peligrosa tendencia porque los atajos tienden a convertirse en hábitos, y la inconsistencia introducida por medio de la no revisión de todas las partes del BR puede llevar a dos situaciones indeseables: primero, la exactitud del registro y la información que provee se convierte en sospechosa y segundo, el personal de manufactura se priva de la oportunidad de aprender de los errores o equivocaciones que podría conducir a mejoras.

  • Desvío no intencional

Aquí un revisor bien entrenado y experimentado ha revisado muchos BRs que tienen desvíos no intencionales respecto del estándar interno. Mientras el revisor tiene acceso al SOP y al check list para la revisión de los BRs, esos documentos de guía no son para él necesarios, a pesar que el check list es firmado. El proceso de revisión ha tomado una actividad robótica durante la cual el proceso mental no está completamente comprometido, pudiendo haber ausencia de datos o ingresos de datos incorrectos.  Esta inconsistencia puede emerger cuando auditorias periódicas de las revisiones conducidas por varios revisores muestran muy diferentes hallazgos.

  • Exageración (exceso)

Mientras la falta de plena atención en el proceso de revisión es una fuente de inconsistencia, así también es una inconsistencia el revisor que va mucho más allá del estándar interno. En este escenario, el revisor insiste en que cada detalle, incluso lo que no tiene impacto, sea corregido de acuerdo a su estándar. Esto puede incluso incluir desafíos a la gramática o la ortografía de aquellos que han escrito un comentario satisfactorio o que han corregido en el BR. Algunos revisores pueden indicar algo como: “si Ud. Quiere que yo firma este registro, el mismo debe estar completamente correcto” o “No estoy completamente conforme con este registro”.

Esto no solo consume mas esfuerzos adicionales del personal de manufactura, sino también envía un  mensaje desafortunado para aquellos que hacen el producto. La aceptabilidad de un registro aparentemente depende más sobre quien revisa el BR que sobre como el mismo fue completado.

Cualquier inconsistencia en el proceso de revisión de BR desafía la reputación de la unidad de calidad y su gestión, porque demuestra una falta de la vigilancia adecuada de su equipo. La vigilancia es uno de los roles claves de la unidad de calidad en las organizaciones. La gestión de la unidad de calidad asegura que su personal además cumple consistentemente con los estándares establecidos.

Los tipos de controles y los registros y reportes que soportan la manufactura de productos terminados están bien definidos ambos en términos de requerimientos regulatorios y en la práctica de la industria. La revisión adecuada de los BR ejecutados sirve al menos para dos propósitos importantes. El proceso satisface los requerimientos regulatorios y el proceso provee feedback útil para el grupo funcional responsable de manufactura.

Como indicamos, una alta tasa de error puede indicar inadecuado entrenamiento o supervisión pobre, pero además podría indicar un procedimiento escrito pobre. Apropiados revisores y aprobadores de BRs entrenados proveen un valor de servicio de la unidad de QA a la organización de manufactura. Su entrenamiento debe incluir un objetivo de consistencia en el proceso de revisión en adición a la exactitud y minuciosidad, esto puede ser mejor determinado por medio de la revisión periódica de los hallazgos de los revisores.

Espero que les resulte útil.

Novedades

21 de julio de 2016

La ANMAT aplica la Ciencia Reguladora para tomar decisiones sobre temas vinculados al cuidado de la salud, basadas en la mejor evidencia científica disponible y considerando la oportunidad y pertinencia para cada caso.
20 de julio de 2016
Se realizará el próximo jueves 21 de julio, a partir de las 14 hs, en la sede de la Dirección Nacional de Productos Médicos de la ANMAT (Av. Belgrano 1480, CABA), y a su vez, se transmitirá a todo el país en forma virtual. Se requiere inscripción previa.
18 de julio de 2016
La ANMAT sólo reconoce a representantes de empresas importadoras una vez que dichas empresas han registrado sus productos ante esta Administración Nacional.
12 de julio de 2016
Por las razones expuestas en la norma, la ANMAT ha dispuesto prorrogar el pago del mantenimiento anual de los productos médicos aprobados como reactivos de diagnóstico de uso “in vitro”.
12 de julio de 2016
Información que deberán agregar los titulares de certificados de productos inscriptos en el REM, en las declaraciones juradas establecidas por la Disposición N° 5039/14 y la Circular ANMAT N° 5/2014.

in-company-qrm

Novedades

06 de julio de 2016
La ANMAT dispondrá a la brevedad las medidas administrativas pertinentes para facilitar la importación de dichos productos.
04 de julio de 2016
Por medio de la Disp. 6766/2016, la ANMAT ha establecido que dichas presentaciones deberán realizarse en lo sucesivo de acuerdo a la guía elaborada a tal efecto.

Novedades

30 de junio de 2016
Se encuentra abierta la preinscripción a FOPEVISA Federal, un programa de actualización profesional en vigilancia sanitaria, dirigido a agentes fiscalizadores en medicamentos y productos médicos en los ministerios de salud provinciales.
24 de junio de 2016
El día 22 de junio, se llevó adelante una reunión de trabajo bilateral entre funcionarios de la ANMAT y de la Administración de Alimentos y Medicamentos de los Estados Unidos de América (FDA, por sus siglas en inglés).

15 de junio: Día del Bioquímico!!!

 

bioquimico1

 

Este 15 de Junio se celebra en Argentina el Día del Bioquímico, en conmemoración del nacimiento del Dr. Juan Antonio Sánchez, creador de la Carrera de Bioquímica de la Universidad de Buenos Aires (UBA).

Desde cGMPdoc, les deseamos muchas felicidades a nuestros colegas.