Listado de la etiqueta: MDSW

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.

CLASIFICACIÓN DEL SOFTWARE

/en , , , , , /por

La clasificación de software según la regla 11 del anexo VIII del Reglamento de producto sanitario MDR 2017/745 describe y categoriza la importancia de la información proporcionada por el producto activo para la toma de decisiones de la atención médica (manejo del paciente) en combinación con la situación sanitaria (estado del paciente).

La Regla 11 se introdujo en el MDR y está destinada a abordar los riesgos relacionados con la información proporcionada por un producto activo, como MDSW.

El IMDRF (International Medical Device Regulators Forum) desarrolló una tabla para ayudar a los operadores a identificar el riesgo apropiado y la categoría para su propio producto.

El texto de la Regla 11 se puede dividir en tres subreglas que se aplican según el uso previsto del MDSW:

  • MDSW  destinado a proporcionar información que se utiliza para tomar decisiones con fines diagnósticos o terapéuticos;
  • el MDSW destinado a monitorear procesos o parámetros fisiológicos;
  • MDSW destinado a todos los demás usos.

MDSW  destinado a proporcionar información

Los primeros párrafos de la regla 11 establece que el MDSW que está destinado a proporcionar información que se utiliza para tomar decisiones con fines diagnósticos o terapéuticos se clasifica como clase IIa, salvo si estas decisiones tienen un impacto que pueda causar:

  • la muerte o un deterioro irreversible del estado de salud de una persona, en cuyo caso se clasifican en la clase III, o
  • un deterioro grave del estado de salud de una persona o una intervención quirúrgica, en cuyo caso se clasifican en la clase IIb.

MDSW destinado a monitorear procesos o parámetros fisiológicos

El MDSW que está destinado a monitorear procesos fisiológicos, en la mayoría de las circunstancias, proporcionará «información que se utiliza para tomar decisiones con fines diagnósticos o terapéuticos» y, por lo tanto, se clasifica como IIa.

Si los parámetros a monitorear son parámetros fisiológicos vitales se clasificará como IIb. Los procesos y parámetros fisiológicos vitales incluyen, por ejemplo, respiración, frecuencia cardíaca, funciones cerebrales, gases en sangre, presión arterial y temperatura corporal.

MDSW destinado a todos los demás usos

Es este caso la clasificación de software será como clase I.

SOFTWARE PRODUCTO SANITARIO

/en , , , /por

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

El software puede:

  1. controlar directamente un producto sanitario (hardware),
  2. puede proporcionar información inmediata que impulsa la toma de decisiones
  3. puede proporcionar apoyo a los profesionales sanitarios.

Cuando un producto dado no entra dentro de la definición de un producto sanitario, o está excluido por el alcance de la Reglamentación de productos sanitarios, otra legislación comunitaria y / o nacional puede ser aplicable. Software que no es MDSW, pero que el fabricante pretende ser un accesorio para un producto sanitario, o un producto sanitario de diagnóstico in vitro, entran respectivamente en el ámbito del Reglamento (UE) 2017/745 MDR o Reglamento (UE) 2017/746 IVDR.

El software puede calificarse como MDSW independientemente de su ubicación. Puede estar operando en la nube, en una computadora, en un teléfono móvil o como una funcionalidad adicional en un producto sanitario (hardware).

El MDSW puede estar destinado a ser utilizado por:

  • profesionales sanitarios
  • personas no profesionales (por ejemplo, pacientes u otros usuarios).

CLASIFICACIÓN DE MDSW

Se considerarán todas las normas de ejecución del anexo VIII del Reglamento (UE) 2017/745.

El software que impulsa o influye en el uso de un producto debe pertenecer a la misma clase que el producto. Si el software es independiente de cualquier otro dispositivo, se clasificará por derecho propio, según la regla que le aplique.

Si varias reglas, o si, dentro de la misma regla, varias subreglas se aplican al mismo software, se aplicará la regla y subregla más estricta. Resultará en una clasificación más alta.

Dado que el software se define como un producto activo, se debe de tener en cuenta las reglas , 10, 11, 12, 13, 15 y 22 del Anexo VIII MDR 2017/745 para la clasificación de productos activos (hardware) incluyendo los MDSW que proporcionan información para el manejo del paciente. Como se menciona anteriormente, debe aplicarse la regla o subregla más estricta.

Próximamente iremos explicando mas detalladamente las reglas que suelen aplicar a los software producto sanitario.

CÓDIGO UDI A SOFTWARE MDSW

/en , , , , /por

Cualquier software o programa informático 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. A este software se le tendrá que asignar un código UDI.

SISTEMA DE IDENTIFICACIÓN ÚNICA

Identificador único de los productos (UDI), consiste en una serie de caracteres numéricos o alfanuméricos. Se crea mediante una norma de codificación e identificación de productos mundialmente aceptada. Permite la identificación inequívoca de un producto específico en el mercado. La identificación única UDI se compone de dos partes:

  • UDI-DI: Código numérico o alfanumérico único de un modelo de producto que también se usa como «clave de acceso» a información almacenada en una base de datos de identificación única
  • UDI-PI: Código numérico o alfanumérico que identifica la unidad de producción del producto. Entre los distintos tipos de UDI-PI se incluyen el número de serie, el número de lote, la identificación del programa informático y/o la fecha de fabricación y/o la fecha de caducidad, o ambos tipos de fechas.

LOCALIZACIÓN DEL UDI

El soporte del UDI deberá figurar en la etiqueta del producto o en el propio producto, y en todos los niveles superiores de embalaje. Se identifica mediante la imagen en formato ICAD y un formato legible para el usuario HRI.

  • ICAD: la identificación y captura automáticas de datos. Las tecnologías de ICAD incluyen los códigos de barras, tarjetas inteligentes, biometría e identificación por radiofrecuencia (RFID).
  • HRI: Interpretación para lectura humana. La HRI es la interpretación legible por las personas de los caracteres codificados en el soporte de la identificación única.

ASIGNACIÓN DE CÓDIGO UDI A SOFTWARE MDSW

El código UDI se asignará a nivel del sistema del programa informático. Solo estarán sujetos a este requisito el software que esté comercialmente disponible de forma individual y el software que sea producto por sí mismo. La identificación del software se considerará el mecanismo de control de fabricación y figurará en el UDI-PI.

Se requerirá un nuevo UDI-DI cada vez que se produzca algún cambio que modifique:

  • el funcionamiento original,
  • la seguridad o uso previsto del programa informático.
  • la interpretación de los datos.

Estos cambios pueden incluir algoritmos nuevos o modificados, las estructuras de bases de datos, la plataforma operativa, la arquitectura o nuevas interfaces de usuarios o nuevos canales de interoperabilidad.

Las revisiones menores del programa informático requerirán un nuevo UDI-PI y no un nuevo UDI-DI. Se entiende como revisiones menores a ajustes relativos a errores de programación, mejoras de la manejabilidad que no se efectúan a efectos de seguridad, refuerzos de la seguridad o la eficacia operativa.

CRITERIOS DE COLOCACIÓN DE CÓDIGO UDI EN SOFTWARE MDSW

Se tendrán en cuenta los siguientes criterios para la colocación del UDI para programas informáticos

  • En caso de que el software se suministre en un medio físico, como un CD o un DVD, cada uno de los niveles de embalaje deberá llevar el UDI completo en formato ICAD y para lectura humana. Este será igual al UDI asignado al programa informático al nivel de sistema,
  • El UDI se suministrará en una pantalla fácilmente accesible para el usuario en un formato de texto fácilmente legible, como por ejemplo en un fichero de información del producto o incluido en la pantalla de inicio,
  • Un programa informático que carezca de interfaz de usuario, como por ejemplo un soporte intermedio para conversión de imágenes, deberá poder transmitir el UDI mediante una interfaz de programador de aplicaciones (API),
  • En los indicadores visuales electrónicos del programa informático solo será necesario que figure la parte del UDI en formato para lectura humana. No será necesario que en los indicadores visuales electrónicos figure el marcado del UDI en formato de ICAD,
  • El formato de lectura humana del UDI del programa informático deberá incluir los identificadores de aplicación de la norma utilizada por las entidades emisoras, para ayudar al usuario a identificar el UDI y determinar qué norma se ha utilizado para crearlo.