Entradas

CÓDIGO UDI A SOFTWARE MDSW

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

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.

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 del 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.

Se trata de una relación que debe ser documentada y sustentada por información clínica o científica suficiente para, junto con otros aspectos, 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, 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

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

Conforme a 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 ser utilizado, 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ía 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