Listado de la etiqueta: Software como producto sanitario

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.

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.

Nuevas tecnologías según en Reglamento de producto sanitario MDR

/en , , , /por

Según el nuevo Reglamento MDR, el producto sanitario deberá disponer de una evaluación clínica, como un proceso de análisis y documentación de su seguridad y funcionamiento. Ocurre también con las nuevas tecnologías.

Evaluación clínica como un proceso iterativo de análisis y documentación

En lo referido al software como producto sanitario, MDCG ha publicado una guía técnica como soporte a su evaluación clínica.

Se considera la evaluación clínica como un medio para la evidencia clínica de cumplimiento los requisitos establecidos por dicho Reglamento.

Aclara la directriz 2019-11 de MDCG, que el software será considerado producto sanitario, componente o accesorio cuando esté implicado en el funcionamiento de otro dispositivo médico o influencia su uso.

De esta manera se diferencia el software con finalidad prevista independiente y que reivindica un beneficio clínico. Por otro lado el software que con una finalidad prevista y una reivindicación relacionada con otro dispositivo médico y finalidad prevista clínica y propia. Como tercera categoría se destaca aquel software capaz de influir en el funcionamiento de un dispositivo médico, con independencia de su finalidad prevista.

Asociación clínica válida

Describe el MDCG 2020-1 la figura del «Valid clinical association» como la validez de la salida del software. En relación con sus entradas y el algoritmo aplicado y el objetivo clínico perseguido.

Esta es una relación que debemos documentar y sustentar por información clínica o científica suficiente; para poder sentenciar la seguridad y funcionamiento del software.

Validación del funcionamiento

Se trata esta de otra figura importante como base de la evaluación clínica del software producto sanitario. Representa una confirmación de la suficiencia técnica del software en térmicos cuantitativos (precisión, funcionamiento y confiabilidad de la medida o parámetros analizados).

Será basada en la verificación y validación del software conforme al testeo en base a la normativa armonizada que sea de aplicación y análisis del estado del arte y de la ciencia actual.

Funcionamiento clínico

La demostración del funcionamiento clínico es la demostración de la precisión y, en general, cualquier especificación requerida por el software, como nuevas tecnologías, generada por su salida prevista en relación con sus entradas; esto es, que la imagen, cálculo o lo que venga generado por el software se corresponda con lo esperado conforme a las entradas que recibe.

Esta salida tiene impacto positivo en:

  • La salud individual del paciente, evaluada en unidades medibles, incluyendo diagnóstico, predicción del riesgo o anticipando el resultado del tratamiento que se aplicará al paciente.
  • La monitorización, visualización, diagnóstico o control de pacientes.

La evidencia necesaria para soportar este hecho estará basada en testeo del software o de un dispositivo equivalente, en condiciones de finalidad prevista con los usuarios previstos, siendo necesario que la metodología sea conforme y apropiada con respecto a las propias características del producto: tests pre-clínicos en laboratorio, ensayos clínicos y/o estudios de funcionamiento clínico.

El software como producto sanitario

/en , , /por

Conforme a la definición de producto sanitario, el software como producto sanitario queda específicamente incluido en la propia definición recogida en el MDR.

Producto sanitario

De acuerdo con lo establecido en el MDR es producto sanitario: todo aquel instrumento, aparato, dispositivo, máquina, equipo, implante, reactivo para uso in-vitro, programa informático, material u otro artículo similar o relacionado, destinado por el fabricante a utilizarse, solo o en combinación, en seres humanos con una o más finalidad/es sanitaria/s específicas/s de:

  • diagnóstico, prevención, control, tratamiento o alivio de una enfermedad;
  • diagnóstico, control, tratamiento, alivio o compensación de una lesión;
  • investigación, sustitución, modificación o soporte de la anatomía o de un proceso fisiológico;
  • mantenimiento o prolongación de la vida;
  • regulación de la concepción;
  • desinfección de productos sanitarios;
  • proporcionar información mediante exámenes in-vitro de muestras procedentes el cuerpo humano;

y no ejerza la acción primaria que se desee obtener en el interior o en la superficie del cuerpo humano por medios farmacológicos, inmunológicos o metabólicos, pero a cuya función prevista puedan contribuir tales medios.

Finalidad prevista

Se define como el uso al que se destina un producto según los datos facilitados por el fabricante en el etiquetado, en las instrucciones de uso o en el material o las declaraciones de promoción o venta, y según lo indicado por el fabricante en la Evaluación clínica.

Es por tanto, el uso para el que el fabricante desarrolla, fabrica y comercializa el producto sanitario, concretamente, en el caso del software, todo programa informático o software implicado en el proceso de diagnóstico, prevención, control, tratamiento o alivio de una enfermedad deberá ser considerado como producto sanitario en base a su definición y a su finalidad prevista.

Requisitos generales

Los programas informáticos o software, considerados producto sanitario, quedarán automáticamente sometidos a los requisitos generales de seguridad y funcionamiento requeridos para cualquier producto.

Adicionalmente al análisis de riesgos, y como parte de la gestión de los mismos, deberá controlarse por el fabricante los procesos del ciclo de vida del software, así como la usabilidad de la aplicación, haciendo uso de la normativa armonizada de aplicación.

Como siempre, os ofrecemos nuestra ayuda para todo lo relacionado con el producto sanitario: info@productosanitario.es | www.productosanitario.es