Listado de la etiqueta: mdcg

EVALUACIÓN DEL FUNCIONAMIENTO EN TEST DE COVID-19

/en , , , /por

La Comisión Europea ha preparado a lo largo de la pandemia del SARS-CoV-2 diferentes guías MDCG, entre ellas la Evaluación del Funcionamiento en test de COVID-19.

MDCG 2021-21

Según el artículo 9 del nuevo Reglamento de Productos Sanitarios para Diagnóstico In Vitro (EU 2017/746), la Comisión Europea podrá adoptar especificaciones comunes relativas a los requisitos generales de seguridad y funcionamiento, documentación técnica y/o a la evaluación del funcionamiento cuando no existan normas armonizadas o cuando sea necesario hacer frente a problemas de salud pública, como en el caso de la pandemia del SARS-CoV-2.
Por este motivo, la Guía MDCG 2021-21 desarrolla la evaluación del funcionamiento para test de diagnóstico in vitro COVID-19. En el documento se describe unas consideraciones generales a tener en cuenta, como los falsos negativos o positivos, límite de detección, reacciones cruzadas, interferencias, entre otras muchas consideraciones técnicas/clínicas.
Los productos COVID-19 al tener como finalidad prevista “la detección de la presencia de, o la exposición a, un agente transmisible causante de una enfermedad potencialmente mortal y con un riesgo elevado o supuestamente elevado de propagación” se consideran productos in vitro de Clase D. Por lo tanto, se debe realizar análisis pertinentes del producto o lotes de productos para la verificación de la conformidad del producto

Consideraciones específicas

Al final de la guía MDCG 2021-21, hay una serie de tablas que desarrollan los diferentes puntos para una evaluación del funcionamiento en test de COVID-19:

  • Primera tabla: referente a los test de “primera línea”, como los test rápidos, para anticuerpos contra el SARS-CoV-2 (anti-SARS-CoV-2): IgG, IgG combinada con IgM y/o IgA, y anticuerpos totales. Estos son los test serológicos.
  • Segunda tabla: referente a los test para la detección de IgM y/o IgA anti-SARS-CoV-2 (incluidas las pruebas rápidas).
  • Tercera tabla: referente a test confirmatorios o suplementarios para anti-SARS-CoV-2.
  • Cuarta tabla: referente a los test de antígenos SARS-CoV-2, incluidas las pruebas rápidas de antígenos.
  • Quinta tabla: referente a los test de técnicas de amplificación de ácidos nucleicos (NAT) para el ARN del SARS-CoV-2
  • Sexta y Séptima tabla: referente a los requisitos adicionales para los test de autodiagnóstico del antígeno SARS-CoV-2 y del anticuerpo, respectivamente. Están destinados a productos que ya se han sometido a una evaluación del funcionamiento para uso profesional.

FACTORES PARA LA CARACTERIZACIÓN DE RIESGO DEL SOFTWARE

/en , , /por

Una vez hemos calificado nuestro producto como producto sanitario software (Medical Device Software – MDSW) y hemos determinado su cobertura bajo el Reglamento de Productos Sanitarios (MDR) 2017/745, es hora de la caracterización de riesgo del software considerando dos factores fundamentales.

FACTORES PARA LA CARACTERIZACIÓN DE RIESGO

Como ya adelantábamos en publicaciones anteriores, la guía MDCG 2019-11 define el criterio para calificar a un software como MDSW. Además, establece la aplicabilidad de las reglas de clasificación, en mayor detalle, la Regla 11 (Anexo VIII de MDR). En esta publicación abordaremos los dos factores fundamentales para la caracterización de riesgo de un producto sanitario software.

La Regla 11 se introdujo en MDR para abordar los riesgos relacionados con la información proporcionada por un producto sanitario software. Esta regla describe y categoriza la importancia de la información proporcionada para la decisión sanitaria (gestión del paciente) en combinación con la situación sanitaria (condición del paciente). De esta forma, la Regla 11 refleja y se alinea con la guía internacional IMDRF para la categorización de riesgos de MDSW (IMDRF Risk Framework).

Existen muchos aspectos que influencian la seguridad del paciente. Se pueden agrupar en los siguientes dos factores:

IMPORTANCIA DE LA INFORMACIÓN PROPORCIONADA PARA LA DECISIÓN SANITARIA

  1. Para tratar o diagnosticar: implica que la información será utilizada para tomar una acción inmediata o a corto plazo.
  2. Para impulsar la gestión clínica: implica que la información será utilizada para guiar próximas intervenciones terapéuticas o diagnósticas.
  3. Para informar a la gestión clínica: implica que la información no desencadenará una acción inmediata o a corto plazo.

SITUACIÓN SANITARIA O CONDICIÓN DEL PACIENTE

  1. Crítica: implica que diagnósticos o tratamientos precisos y/u oportunos son vitales para evitar la muerte, una discapacidad a largo plazo u otro deterioro grave en la salud del paciente o para mitigar el impacto en la salud pública.
  2. Seria: implica que diagnósticos o tratamientos precisos son vitales para evitar intervenciones innecesarias o intervenciones oportunas son importantes para mitigar las consecuencias irreversibles a largo plazo en la salud del paciente o en la salud pública.
  3. No seria: implica que diagnósticos o tratamientos precisos son importantes, pero no críticos para mitigar las consecuencias irreversibles a largo plazo en la salud del paciente o en la salud pública.

CATEGORIZACIÓN DEL RIESGO

De la combinación de estos dos factores, resultarán cuatro categorías: I, II, III y IV. A continuación, mostramos la tabla del Anexo III de MDCG 2019-11. Esta tabla relaciona las categorías de riesgo IMDRF con las clases de riesgos de acuerdo a la Regla 11 de MDR (a excepción de la clase I).

Caracterización de riesgo de producto sanitario software.
Caracterización de riesgo de producto sanitario software.

Cabe decir que el marco para la categorización de riesgos de IMDRF no es una clasificación con base regulatoria. Además, no debe entenderse como una convergencia exacta con las reglas de clasificación de MDR. Sin embargo, sí que establece un camino común.

Como conclusión, la clasificación de un producto sanitario software se regirá por su finalidad prevista y su riesgo inherente. En base a ello, se deberá evaluar la importancia de la información proporcionada por el MDSW para la decisión sanitaria y la situación o condición del paciente.

CLASE DE SEGURIDAD DEL SOFTWARE

/en , , /por

La clasificación de riesgo de un producto sanitario software se realiza mediante la evaluación de la aplicabilidad de las reglas de clasificación del Anexo VIII del Reglamento de Productos Sanitarios (MDR) 2017/745. La particularidad de un software es que su fabricante también debe determinar su clase de seguridad mediante la norma internacional ISO 62304 Software de dispositivos médicos. Procesos del ciclo de vida del software.

CLASIFICACIÓN DE RIESGO SEGÚN MDR

En publicaciones anteriores vimos como la Regla 11 nos ayuda a describir y a categorizar la importancia de la información proporcionada por el producto sanitario software para la decisión sanitaria junto con la situación sanitaria y condición del paciente. La tabla del Anexo III de la guía MDCG 2019-11, alineada con la IMDRF Risk Framework, muestra el resultado de combinar estos dos factores. De esta forma (a excepción de la Clase I):

  • La Clase III se alinea con la Categoría IV.
  • La Clase IIb se alinea con la Categoría III.
  • La Clase IIa se alinea con la Categoría II y I.

CLASE DE SEGURIDAD SEGÚN ISO 62304

La norma internacional por excelencia del producto sanitario software es la ISO 62304. En ella se establecen las técnicas, herramientas y actividades relacionadas con el proceso de desarrollo del software a lo largo de su ciclo de vida. El primer paso será establecer la clasificación de riesgo. Ésta determinará el nivel de detalle en la documentación y evidencia para las diferentes etapas del ciclo de vida. Diferenciamos tres clases de seguridad:

  • Clase A: el software no puede contribuir a una situación peligrosa o el software puede contribuir a una situación peligrosa que no resulte en un riesgo inaceptable después de considerar las medidas externas de control del riesgo aplicadas al software.
  • Clase B: el software puede contribuir a una situación peligrosa que resulte en un riesgo inaceptable después de considerar las medidas externas de control del riesgo aplicadas al software y el posible daño resultante sea una lesión no-seria.
  • Clase C: el software puede contribuir a una situación peligrosa que resulte en un riesgo inaceptable después de considerar las medidas externas de control del riesgo aplicadas al software y el posible daño resultante sea una lesión seria.

Vemos que en las clases de seguridad el riesgo residual (riesgo que permanece después de aplicar medidas de control) del producto sanitario software es clave. Cabe mencionar que estas medidas de control externas, según la normativa, pueden ser: un hardware, un software independiente, o los procedimientos de asistencia sanitaria, entre otros.

CONCLUSIÓN

Como conclusión, recordamos que la clasificación de un producto sanitario software se regirá por su finalidad prevista y su riesgo inherente. Una vez implementadas y verificadas las medidas de control (internas y externas), debemos reevaluar los riesgos resultantes y analizar si estos riesgos residuales podrán protagonizar o contribuir a situaciones peligrosas. De esta forma, determinaremos la clase de seguridad del software.

En futuras publicaciones, presentaremos en más detalle los aspectos requeridos para documentar el ciclo de vida del software según su clase de seguridad.

Calificación de producto sanitario software

/en , , , /por

La calificación de nuestro producto como producto sanitario software (Medical Device Software – MDSW) bajo el Reglamento de Productos Sanitarios (MDR) 2017/745 y el Reglamento de Productos Sanitarios para Diagnóstico In-Vitro (IVDR) 2017/746 es fundamental. Esta definición determinará los siguientes pasos en nuestro proceso regulatorio.

MDCG 2019-11

La guía MDCG 2019-11 define el criterio para calificar un software como un producto sanitario software y, como tal, entrar dentro del alcance de MDR o IVDR. Además, establece la aplicabilidad de las reglas de clasificación sobre el producto sanitario software. En esta publicación nos centraremos en el primer aspecto.

¿Qué es un producto sanitario software?

Primero, debemos definir qué es un software. MDCG 2019-11 lo define como “un conjunto de instrucciones que procesa datos de entrada y crea datos de salida”. Los datos de entrada pueden ser dados mediante pantallas táctiles, reconocimiento de voz o documentos digitales, por ejemplo. De la misma forma, los datos de salida podrían ser mostrados mediante audio, impresión o documentos digitales, entre otros. Nuestro software, por tanto, debe cumplir con esta definición.

A continuación, nuestro software debe tener una finalidad médica en sí mismo para ser considerado un producto sanitario. Para ello, debe cumplir también con la definición de producto sanitario de acuerdo a MDR o IVDR.

Por lo tanto, un software que procese, analice, cree o modifique información médica en base a una finalidad prevista médica se considera un producto sanitario software. Cabe decir que éste sigue siendo un producto sanitario independientemente de si funciona en la nube, en un ordenador o en un teléfono móvil, por ejemplo. Por último, tanto profesionales sanitarios como pacientes u otros usuarios pueden utilizarlo.

¿Qué no es un producto sanitario software?

Un software puede utilizarse en el ámbito de la asistencia sanitaria y a su vez no considerarse producto sanitario software. Un software que permita únicamente la búsqueda de información o que sirva para la planificación o comunicación del personal sanitario no es un producto sanitario software.

Árbol de decisión de MDCG 2019-11

El árbol de decisión de la guía MDCG 2019-11 nos permitirá determinar si nuestro software puede ser calificado como producto sanitario software. Así mismo, podremos confirmar si se encuentra bajo el paraguas de MDR o IVDR.

Como conclusión, la calificación y clasificación de nuestro software como producto sanitario software es fundamental. Debemos determinar si puede ser definido como software producto sanitario según la definición de MDCG 2019-11, si su finalidad prevista se encuentra dentro de las indicadas en las definiciones de MDR o IVDR, y si proporciona algún beneficio clínico sobre los pacientes. Recordamos que esto último requerirá evidencia clínica suficiente.

Qué son los legacy devices de acuerdo con MDR e IVDR

/en , , , /por

Qué son los legacy devices o «productos heredados. Son los productos sanitarios o productos sanitarios in vitro puestos en el mercado bajo la anteriores directivas. Serán certificados bajo los nuevos Reglamentos MDR o IVDR al final de la vida útil de su anterior certificación; pero podrán basar su conformidad con los requisitos aplicables en el uso de su experiencia previa en el mercado.

Definición, qué son los legacy devices o productos herados

Los legacy devices o productos heredados son aquellos que:

  • Aquellos que, conforme al Artículo 120 (3), siendo clase I bajo directiva se haya emitido Declaración de conformidad antes de 26/05/2021 y su transición a MDR exija de la participación de Organismo Notificado. En esos casos, podrán seguir siendo comercializados hasta 26/05/2024.
    • Cuando siga cumpliendo los requisitos y
    • no sufra cambios significativos en su diseño ni en la finalidad prevista.
  • Productos sanitarios cubiertos por un certificado CE conforme y emitido con anterioridad al 26/05/2021.

Requisitos para los legacy devices

Los legacy devices deberán cumplir (haber cumplido) con los requisitos específicos definidos por MDR relativos a:

Este aspecto que parece sencillo y banal, podrá suponer problemas para los productos heredados en el momento de la transición a MDR, te animamos a que los controles si no lo están ya.

Otros requisitos aplicables

Además de los anteriores, existen otros requisitos que ya les resultan de aplicación. Se trata de las obligaciones de cada uno de los agentes económicos (o actores económicos). MDR e IVDR especifican un listado para cada uno de los tipos de agentes del mercado.

Aplicación de los requisitos a los productos heredados

A pesar que los requisitos más generales de MDR e IVDR no resultarán de aplicación a los productos heredados; los artículos 93 a 100 de MDR (y equivalentes de IVDR), abren la posibilidad a las Autoridades nacionales competentes a legislar en precisión.

Un ejemplo claro y sencillo es la notificación de incidentes de producto sanitario.

Al final del MDCG 2021-25, encuentras una tabla aclaratoria de qué requisitos aplican a los productos heredados.

Nomenclatura Europea de Producto Sanitario (EMDN)

/en , , , /por

La Nomenclatura europea de producto sanitario (EMDN), según el artículo 26 del Reglamento MDR 2017/745 sobre productos sanitarios y el artículo 23 del Reglamento 2017/746 sobre productos sanitarios para diagnóstico in vitro (IVDR), tiene como objetivo respaldar el funcionamiento de la base de datos europea sobre productos sanitarios (EUDAMED).

Entre sus diversos usos, el EMDN será utilizado por los fabricantes para el registro de productos sanitarios en EUDAMED; donde estará asociado a cada Identificador Único de Dispositivo – Identificador de Dispositivo (UDI-DI).

Dado que el EMDN sirve principalmente para fines reglamentarios para respaldar los requisitos de MDR e IVDR, también desempeña un papel clave en la documentación y documentación técnica del producto.

Está destinado a apoyar a todos los actores en sus actividades bajo el MDR / IVDR y proporciona descripciones clave de productos a los pacientes y todos los demás productos disponibles en el mercado y registrados en EUDAMED.

¿Cómo acceder a EMDN?

La totalidad de la Nomenclatura europea de producto sanitario (EMDN) es accesible para todas las partes interesadas, de forma gratuita. Por lo tanto, puede ser utilizado por una lista no exhaustiva de partes interesadas, como fabricantes, pacientes, organizaciones de investigación, médicos, hospitales, farmacias, etc.

Se puede acceder y descargar el EMDN en formato pdf y excel la página web de la Comisión Europea para documentos MDCG.

¿Cómo está estructurado el EMDN?

El EMDN se caracteriza por su estructura alfanumérica que se establece en un árbol jerárquico de siete niveles. Agrupa los productos sanitarios en tres niveles principales:

  • Categorías: el primer nivel jerárquico,
  • Grupos: el segundo nivel jerárquico,
  • Tipos: el tercer nivel jerárquico (que se expande en varios niveles de detalle (1, 2, 3, 4 y 5), cuando sea necesario.

Cada código alfanumérico comienza con una letra que hace referencia a la «CATEGORÍA» a la que pertenece el producto, seguida de dos números que indican el «GRUPO» y una serie de números que consulte el «TIPO». El número máximo de dígitos se establece en 13.

¿Qué nivel EMDN debo asignar a mi producto?

EMDN utiliza la jerarquía en forma de árbol. Los usuarios siempre deben asignar el término más granular y terminal disponible (nivel más bajo en el árbol) a su producto.

PERSONA RESPONSABLE DEL CUMPLIMIENTO DE LA NORMATIVA

/en , , , /por

Dentro de la organización de una empresa  dedicada a fabricar cualquier producto sanitario tendrá que haber, al menos, una persona responsable del cumplimiento de la normativa, PRRC.

PRRC, de su significado en ingles “Person Responsible for Regulatory Compliance” no sustituye al Responsable Técnico, figura establecida por la legislación española, pero, a priori, sí puede ser la misma persona.

La persona responsable del cumplimiento de la normativa deberá formar parte de la empresa fabricante, aunque si se trata de una pequeña o mediana empresa no tendrá que pertenecer a ella, pero si tendrá que disponer de tal persona de forma permanente y continua.

En el caso de los representantes autorizados, tendrán permanentemente y  continuamente a su disposición una persona responsable del cumplimiento de la normativa.

EXPERIENCIA REQUERIDA PARA LA PERSONA RESPONSABLE DEL CUMPLIMIENTO DE LA NORMATIVA

Como podemos encontrar en el articulo 15 del MDR, y bien se explica en la guía del MDCG 2019-7, la persona responsable del cumplimiento de la normativa, tendrá que ser una persona con la pericia necesaria en el ámbito de producto sanitario.

Esto lo demostrará mediante alguna de las siguientes cualificaciones:

  • Poseer al menos 1 año de experiencia profesional en asuntos reglamentarios o en sistemas de gestión de calidad relativos a productos sanitarios y estará en posesión de un diploma, certificado u otra prueba de cualificación profesional, obtenido por haber completado estudios universitarios o estudios equivalentes reconocidos por el Estado miembro sobre:
    • Derecho
    • Medicina
    • Farmacia
    • Ingeniería
    • Otra disciplina científica
  • Poseer 4 años de experiencia profesional en asuntos reglamentarios o sistemas de gestión de calidad relativos a productos sanitarios.

OBLIGACIONES DEL PRRC

La persona responsable del cumplimiento de la normativa se encargará de al menos:

  • Comprobar la conformidad del producto, mediante el sistema de gestión de calidad, antes de proceder a liberar el producto.
  • Preparar y actualizar la documentación técnica y la declaración UE de conformidad.
  • Cumplir, o verificar que se haga, con las obligaciones postcomercialización.
  • Cumplir, o verificar que se haga, con las obligaciones de notificación  de :
    • incidentes graves y acciones correctivas de seguridad en campo
    • Tendencias
    • Análisis de datos de vigilancia
    • Actos de ejecución

SOFTWARE DE PRODUCTO SANITARIO (MDSW)

/en , , /por

Cualquier software producto sanitario, MDSW,  es ​​aquel que está destinado a ser utilizado, solo o en combinación, para un propósito sanitario como se especifica en la definición de » producto sanitario » en el MDR.

El software puede estar asociado  con otro producto sanitario, regulando, controlando o influyendo en su funcionamiento. Estarán cubiertos por las regulaciones de productos sanitarios ya sea como parte o componente de un dispositivo o accesorio.

Los desarrolladores de software deben consultar MDCG 2019-11 para obtener orientación sobre la calificación y clasificación apropiada del software antes de que este  se introduzca en el mercado.

SOFTWARE DE PRODUCTO SANITARIO,MDSW, SEGÚN SU PROPÓSITO MÉDICO

Se pueden entender los siguientes modelos de software de producto sanitario, MDSW:

  • Software para el cual el fabricante reclama un propósito médico específico. Dicho software tiene un BENEFICIO CLÍNICO y requiere EVIDENCIA CLÍNICA dentro de su propia evaluación de conformidad.
  • Software para el cual el fabricante no reclama ningún propósito médico previsto. Dicho software está destinado a controlar o influir en un dispositivo médico. La EVIDENCIA CLÍNICA se proporciona dentro del contexto del dispositivo accionado o influenciado.

EVIDENCIA CLÍNICA DEL  MDSW

Como ya hablamos en un post anterior, se conoce como evidencia clínica a los datos clínicos y los resultados de la evaluación clínica (MDR) pertenecientes a un dispositivo. Será de una cantidad y calidad suficientes, para permitir una evaluación cualificada de si el dispositivo es seguro y logra los beneficios clínicos previstos según el fabricante.

La evidencia clínica del MDSW se genera mediante tres componentes:

  • Rendimiento clínico: se consigue a través de actividades de evaluación  o investigación según su finalidad prevista.
  • Beneficios clínicos: pueden demostrarse a través de resultados o información clínica medible, relevante y/o precisa para el paciente.
  • Evaluación clínica: debe considerar la relación beneficio-riesgo a la luz del ESTADO DEL ARTE para el diagnóstico, tratamiento o manejo del paciente

NIVEL DE EVIDENCIA CLÍNICA DEL SOFTWARE DE PRODUCTO SANITARIO

Para determinar y justificar el nivel de EVIDENCIA CLÍNICA, tanto la cantidad como la calidad de los datos de respaldo son evaluados. Esta evaluación puede guiarse por las siguientes preguntas:

  • Cantidad suficiente:
    • Los datos respaldan el uso previsto, las indicaciones, los grupos objetivo, las afirmaciones clínicas y contraindicaciones?
    • ¿Se han investigado los riesgos clínicos y el rendimiento clínico?
    • Tienen características relevantes de MDSW, como la entrada y salida de datos, los algoritmos aplicados o tipo de interconexión considerado al generar los datos para soportar el rendimiento del dispositivo?
    • ¿Cuál es el grado de innovación / historia en el mercado?
  • Calidad suficiente
    • ¿Fueron apropiados el tipo y el diseño del estudio / prueba para cumplir con los objetivos de la investigación?
    • ¿Fue el conjunto de datos apropiado y actual (estado del arte)?
    • ¿Fue apropiado el enfoque estadístico para llegar a una conclusión válida?
    • ¿Se tuvieron en cuenta todas las consideraciones / requisitos éticos, legales y reglamentarios?
    • ¿Hay algún conflicto de intereses?

Se trata este de un tema controvertido que iremos explicando en próxima entradas, como siempre quedamos a vuestra disposición para todo lo que podáis necesitar info@productosanitario.es | www.productosanitario.es