El software médico es considerado un dispositivo médico que puede causar daño a las personas. En USA o en Europa se requiere una certificación por la FDA o por la Comisión Europea (CE).
Los dispositivos (y también el software) son clasificados según el riesgo en
Clasificación USA
Clase
Riesgo
Controles
Certificación
Clase 1
Bajo
Generales
FDA clase 1 o FDA 510(k)
Clase 2
Moderado
Generales y especiales
FDA 510(k)
Clase 3
Alto
Generales y especiales, y aprobación premercado
FDA PMA
Los dispositivos de Clase 2 generalmente se someten a una revisión 510(k), que se enfoca en determinar si el nuevo dispositivo es “sustancialmente equivalente” a un dispositivo existente. Las revisiones 510(k), por lo general, no requieren ensayos clínicos para demostrar esta equivalencia sustancial. En cada certificación se presenta contra qué otro software se comparó para mostrar su “equivalencia”. Si el dispositivo/software no tiene comparador hay otra certificación, FDA de novo.
Logo de Aprobado por la FDA
Clasificación Europea
Clase
Riesgo
Tipos
Clase I
Bajo
Dispositivos no estériles y sin función de medición
Clase IIa
Medio
Clase IIb
Medio/alto
Clase III
Alto
Al certificarse un dispositivo, la Comisión Europea permite que se utilice el logo de CE MARK en el dispositivo
¿Cuál es el objetivo de la certificación de dispositivos médicos?
Asegurarse de que los dispositivos médicos sean “razonablemente” seguros y eficaces.
HealthScouts recopila un listado de todas las APPS móviles que están certificadas, tanto por la FDA como por la CE.
También me gustaría añadir la clasificación chilena de los dispositivos médicos:
Clase
Nivel de riesgo
Ejemplos
Clase I
muy bajo
Camas clínicas, estetoscopios
Clase II
moderado
Guantes quirúrgicos, lentes de contacto
Clase III
elevado potencial
Maquinas de anestesia, equipos de diálisis
Clase IV
más crítico
Válvulas cardíacas, implantes
Fuentes:
Más información en la página web del Instituto de Salud Pública, incluso las responsabilidades de ellos con respeto al tema: http://www.ispch.cl/dispositivos-medicos.
Una advertencia de la FDA alertó a los diabéticos hace 3 días.
Las bombas de insulina y los sensores de glucosa utilizan algoritmos para procesar los datos. Estos algoritmos son los que terminan presentando, en una pantalla la información al usuario. Hoy existen bombas de insulina automatizadas, donde el sensor le entrega a la bomba la glicemia y la bomba administra la insulina correspondiente.
Un caso de una hipoglicemia severa (que debe de haber terminado en un coma) en un paciente diabético despertó las alertas de la FDA. Un sensor de glucosa aprobado por la FDA envió datos de glicemia elevada a un algoritmo (no aprobado) que se comunicó con una bomba de insulina que administró una dosis incorrecta de insulina al paciente.
Además, a partir del próximo 26 de mayo 2020 entrará en plena vigencia el nuevo reglamento europeo sobre dispositivos médicos (UE 2017/745) y junto con lo establecido también a raíz del fallo de la Corte de Justicia Europea del 7.12.2017 (Procedimiento prejudicial — Productos sanitarios — Directiva 93/42/CEE — Ámbito de aplicación —Concepto de «producto sanitario»), que según el siguiente extracto de la sentencia misma declara:
“…un programa informático con una funcionalidad que permite la explotación de datos propios de un paciente, con el fin, en particular, de detectar las contraindicaciones, las interacciones de medicamentos y las posologías excesivas constituye, por lo que respecta a esa funcionalidad, un producto sanitario en el sentido de tales disposiciones, aun cuando ese programa informático no actúe directamente en el interior o en la superficie del cuerpo humano.”
Las conclusiones derivadas de algunos expertos a partir de todo lo anterior, según las reflexiones de Massimo Mangia en su blog, llevaría a que incluso todo aquel software utilizado para propósitos médicos distinto a aquello cuyo único propósito es guardar y transmitir datos (sin realizar ninguna elaboración con ellos), tendría necesariamente que ser Certificado como Dispositivo Médico (DM) Clase IIA (riesgo medio). Es decir, por ejemplo - no solamente todo sistema de prescripción de un cierto nivel (como el citado en el fallo) - sino que también fichas clínicas electrónicas que incorporen funcionalidades que hacen más cosas con la información, desde visualizaciones avanzadas hasta Sistemas de Apoyo a la Toma de Decisiones clínicas propiamente tales, tendrían que ser certificados como DM IIA. Esto sería lo que se viene.
Que también nuestro mercado de innovadores y otros actores que desarrollan software en salud en Chile capten las “señales” que vienen tanto de los USA como de la EU. La Calidad del Software en Salud no es una opción y hay que prepararse a certificarlo.
