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.

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.

Transición a MDR e IVDR

/en , , , /por

Nos encontramos en un momento de transición a MDR e IVDR. No sin complicaciones e imprevistos. El proceso se está alargando, complicando y enredando. Los fabricantes de producto sanitario están en un triángulo entre la transición, la dificultad de acceso a Organismos notificados y un aumento de las exigencias, en ocasiones, irracional.

MDCG 2022-14 para la transición a MDR e IVDR

Recién publicado por el Grupo MDCG, el texto MDCG 2022-14 aborda uno de los mayores problemas manifiestos en la transición a MDR e IVDR. La capacidad de los Organismos notificados y la disponibilidad en el mercado de los productos sanitarios, especialmente IVD.

El grupo de trabajo ha empezado reconociendo las tareas urgente y significativas todavía pendientes, para garantizar la capacidad de certificación de productos sanitarios a los nuevos reglamentos, MDR e IVR.

La autoridades han urgido al MDCG a proponer soluciones a la situación. Las principales, bajo nuestro punto de vista, son:

Incremento de la capacidad de los organismos notificados

  • La realización por los organismos notificados de auditorías híbridas, buscando la eficiencia en términos de tiempos.
  • Búsqueda de eficacia en el reconocimiento de las tareas de evaluación realizadas anteriormente en base a las antiguas Directivas.
  • En relación con los «legacy devices», aprovechas la flexibilidad para atajar auditorías híbridas entre Directivas y Reglamentos, desfocalizar la atención al Art. 120 y directivas e ir chequeando requisitos propios de los Reglamentos.
  • Reducir la tarea administrativa a los Organismos notificados.
  • Agilizar EUDAMED como herramienta imprescindible.
  • Incrementar la capacidad para crear nuevos organismos notificados, mediante formación y preparación de personal.
  • Aplazamiento, o distanciamiento, de las re-evaluaciones a los Organismos notificados.
  • Agilizar el proceso de designación.
  • Agilizar los relacionado con el personal «empleado o interno» de los organismos notificados.
  • La aplicación lógicas, y responsable, de nuevas normativas armonizadas o especificaciones comunes, para documentaciones técnicas que ya han empezado la tramitación (aspecto necesario y totalmente lógico).

Acceso a los organismos notificados

  • La necesidad de hacer públicas las nuevas tarifas y fáciles de entender y comparar.
  • Reconsiderar el esquema a seguir para las empresas que pretender ser certificadas por primera vez.
  • Recordar a los fabricantes de producto sanitario lo apremiante del proceso y del cumplimiento de los nuevos requisitos.
  • Pide diálogo entre fabricantes y organismos notificados.
  • Incrementar la preparación y capacidades de fabricantes, especialmente de «novatos» en el proceso.
  • Aumentar el pragmatismo y facilitar la transición a productos legacy.
  • Dar soporte a fabricantes y organismos notificados en las evaluaciones clínicas de legacy devices o heredados, en base a sus procesos PMCF/PMFP.

Destaca la llamada, o recuerdo, de la capacidad de brindar evaluaciones de conformidad excepcionales en atención a razones de salud pública o interés general.

Resumen

Nos parece una demostración de intenciones y golpe de autoridad para invitar a fabricantes y organismos notificados para acelerar el proceso. Destacamos el nuevo enfoque que permite validar clínicamente el producto sanitario con una adecuada justificación basada en el seguimiento PMCF. Como siempre dijimos: la transición a MDR e IVDR está un poquito más cerca del control de los fabricantes con una muy buena evaluación clínica de producto sanitario.

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.

Ciberseguridad para productos sanitarios (II)

/en , , , , , /por

Seguimos con el análisis de los requisitos de ciberseguridad para producto sanitario software. Desarrollamos a continuación los principales hilos que afectan a este riesgo posible que es necesario atajar en el software como producto sanitario.

Requisitos mínimos de las comunicaciones IT, en relación con la ciberseguridad para productos sanitarios

Es necesario determinar, por el fabricante, los requisitos que son necesarios prever en las comunicaciones. Estos requisitos dependerán de cada producto, pero irán desde el protocolo seleccionado hasta las herramientas seleccionadas en el desarrollo, o el interface del usuario.

Incluidos en ellos, se han de tener presentes los riesgos relacionados con la falta de experiencia o conocimiento del usuario, para lo que usaremos la normativa armonizada de Usabilidad, ISO 62366.

Otros requisitos y aspectos a tener presentes

Otros requisitos o fuentes de información que deberemos tener en cuenta son:

  • Protección de datos e informaciones de carácter personal (incluso su normativa y legislación de desarrollo).
  • La información procedente del seguimiento post-comercialización.
  • El informe periódico de seguridad.
  • Los incidentes graves reportados a las autoridades.
  • Los informes de tendencia.
  • La adecuación de la documentación técnica de producto.
  • La relación beneficio/riesgo y sus evidencias.

Funcionamiento seguro

Se define el funcionamiento seguro como la protección contra la corrupción malintencionada del producto software capaz de causar comportamientos no intencionados por los usuarios, fabricantes o desarrolladores, se abordan incluso de forma directa los parámetros de la seguridad operativa de la infraestructura. Se trata este de un aspecto que deberá ser analizado en detalle con el avance del estado de la ciencia y tecnología.

Seguridad de la información

Cita MDR explícitamente la necesidad de garantizar la seguridad de la información (o ciberseguridad para productos sanitarios), donde se citan, o recomienda, los principios del estado del arte y de ciclos de vida de desarrollo software (véase ISO 62304).

Seguridad y eficacia

De este modo, los requisitos generales de seguridad y funcionamiento, citan directamente la seguridad y eficacia del producto sanitario software. En este ámbito relaciona los riesgos de seguridad con impacto en la propia seguridad.

Esto es:

  • La seguridad debe evitar vulnerabilidades y ataques malintencionados, pero
  • Que las medidas de seguridad garanticen que el software es usable y será capaz de proporcionar el suficiente beneficio clínico, en relación con su propio riesgo.

El software se debe proteger contra ataques, sin penalizar por ello su usabilidad!

Ciberseguridad para productos sanitarios (I)

/en , , , , , /por

La ciberseguridad del producto sanitario

Venimos diciendo que la seguridad y funcionamiento clínico del producto sanitario son objetivos principales para MDR. Si bien, en un entorno Software, la seguridad de la información, su funcionamiento y estabilidad y la ciberseguridad del producto sanitario, son elementos imprescindibles.

Prueba de ello es la publicación del MDCG 2019-16, especificación y guía técnica creada especialmente por el Grupo de coordinación creado por la Comisión europea.

Análisis de riesgos

Esta deberá ser la manera de abordar los peligros, o situaciones peligrosas, relacionadas con la seguridad cibernética de un producto sanitario software. Conforme a la normativa armonizada, se deben analizar todos peligros conocidos, así como las situaciones relacionadas, que pudieran representar un riesgo.

El fabricante deberá mantener «vivo» este análisis durante todo el ciclo de vida del producto, desde la fase pre-comercialización como la post-comercialización.

Este análisis cuantificará la probabilidad y severidad del daño en el caso de que el riesgo terminara por aparecer, poniendo medidas (llamadas de mitigación y de reducción) para evitar que finalmente se represente o para reducir al mínimo posible sus consecuencias cuando así fuera.

Requisitos generales de seguridad y funcionamiento

Son las exigencias que se aplican a todo producto sanitario para que, en condiciones normales de uso, sean aptos para desempeñar su finalidad prevista.

En el caso del producto sanitario software, es exigible y necesario que el producto garantice la repetibilidad, la fiabilidad y el funcionamiento y seguridad de la información. Un riesgo relacionado con la ausencia de estos requisitos es, precisamente, la ciberseguridad.

En este aspecto, la guía invita a observar el estado actual de la técnica y generar un proceso de control del riesgo que permita mantener bajo condiciones aceptables este riesgo.

La verificación y la validación

Las figuras de la verificación y la validación, exigibles por la normativa armonizada ISO 13485, en relación con el sistema de gestión de calidad aplicable, se convierten en necesarias para comprobar (y evidenciar) la capacidad de cumplir estos requisitos.

Una estrategia adecuada de desarrollo se basará en la selección de normativa armonizada adecuada que nos permita identificar los requisitos y finalmente, evidenciarlos.

Una norma aplicable en este aspecto para productos software será la ISO 62304.

MDCG GRUPO DE COORDINACIÓN DE PRODUCTO SANITARIO

/en , , , /por

En anteriores publicaciones hemos mencionado el  MDCG y hoy explicamos qué significan estas siglas. MDCG, de la traducción del inglés de “Medical Device Coordination Group”. es un grupo de coordinación de producto sanitario formado por un miembro titular y uno suplente de cada uno de los Estados miembros de la Unión Europea.

Los miembros del MDCG o grupo de coordinación de producto sanitario, son nombrados por los propios Estados, en función de su papel y experiencia en el ámbito de los productos sanitarios. Proporcionarán asesoramiento y ayuda a la Comisión y a los Estados miembros para garantizar una aplicación armonizada de los Reglamentos UE 2017/745 Y 2017/746.

Estos, serán expertos en materia de producto sanitario y no podrán tener intereses económicos o de otra índole en esta industria. Se comprometerán a actuar de forma independiente y siempre trabajarán en interés público.

FUNCIONES DEL GRUPO DE COORDINACIÓN DE PRODUCTO SANITARIO

El MDCG se reunirá periódicamente, a petición de algún Estado miembro o a petición de la Comisión. Como resultado, publican nuevas guías y/o actualizan las existentes, como ayuda a las partes interesadas para implementar las regulaciones de productos sanitarios.

Algunas de las funciones del Grupo de Coordinación de Producto Sanitario serán:

  • Contribuir a evaluar los organismos de evaluación de la conformidad solicitantes y los organismos notificados
  • Asesorar a la Comisión en cuestiones relacionadas con el grupo de coordinación de los organismos notificados
  • Contribuir a elaborar orientaciones para una aplicación eficaz y armonizada del  Reglamento MDR
  • Contribuir al seguimiento continuo de los avances técnicos y a la evaluación de si los requisitos generales en materia de seguridad y funcionamiento son adecuados
  • Asesorar a la Comisión en la evaluación de cualquier cuestión relacionada con la aplicación del Reglamento MDR

El MDCG debe poder establecer subgrupos para tener acceso a los conocimientos técnicos necesarios en el ámbito de los productos sanitarios teniendo en cuenta que cabe la posibilidad de que en ellos participen grupos existentes a escala de la Unión en el  sector de los productos sanitarios.

Quedamos a su disposición para cualquier duda o consulta sobre producto sanitario en info@productosanitario.es | www.productosanitario.es