Listado de la etiqueta: Reglas de clasificación de producto sanitario

FACTORES PARA LA CARACTERIZACIÓN DE RIESGO DEL SOFTWARE

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

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.