Apps Salud

Regulación y Normativa del Software Médico y las Apps Sanitarias

17/01/2023

Una de las cosas más importantes que deben tener en cuenta los desarrolladores de software médico y apps sanitarias son las regulaciones europeas de software médico que les son de aplicación, así como las leyes de protección de datos. En el presente artículo nos centramos en los requerimientos legales que tiene el software de salud en europa, y en este otro artículo encontrarás información respecto al Reglamento General de Protección de Datos (RGPD), la Ley Orgánica de Protección de datos y Garantía de Derechos Digitales (LOPD-GDD) y la Ley de Autonomía del Paciente.

 

proteccion-de-datos-cta

 

Regulación del Software Médico en Europa

Podemos definir el software médico como el proceso de diseño y desarrollo de tecnologías médicas, que suele darse cuando los investigadores encuentran la posibilidad de desarrollar una tecnología para una necesidad no cubierta. Hallado el nicho, la idea se conceptualiza en uno o diferentes productos.

En una fase temprana del desarrollo de software sanitario suelen buscarse la soluciones más funcionales. ¿La solución es mejor que esta otra tecnología? ¿Quizás es mejor que esta otra solución terapéutica? ¿Tal vez es más rápida?

Una vez está definido el concepto de producto o productos, el objetivo final será producir el software para que sea lanzado al mercado. Si bien no es el objetivo de esta entrada, en este otro artículo encontrarás una guía paso a paso para desarrollar software sanitario que pueda ser exitoso en la industria de la salud.

 

software-medico-cta

 

Desde la conceptualización del producto ya resulta necesario tener en cuenta las regulaciones del software médico. Hay que asegurarse de que el producto que se pretende desarrollar, tal y como se está definiendo, quede bien enmarcado según las normativas y las regulaciones del software sanitario. ¿Qué requisitos legales le aplican, y a qué marco legal hay que someterse? ¿Cuál es el alcance regulatorio del producto que tenemos entre manos?

 

¿Es mi software un producto sanitario?

Lo primero que debemos preguntarnos es si el software que planeamos desarrollar realmente se enmarca como un producto sanitario, ya ue no todos los softwares y apps de salud quedan enmarcados bajo la categoría de software médico.

Simplificando, para que el software pueda ser considerado como médico debe haber un beneficio para un individuo concreto, es decir, que el software médico tome una decisión terapéutica para una persona a nivel individual. Además, para que sea considerado software médico, tiene que estar realizando funciones complejas sobre los datos que se han recabado.

  • Un sistema de archivo y comunicación de imágenes (PACS), que sólo muestra y guarda imagenes, no será considerado software médico.
  • Un sistema de Registro Electrónico de Pacientes (EPR), que sólo reemplaza archivos en papel, no será considerado software médico.

 

Marcado CE – Proceso regulatorio en la Unión Europea

El Marcado CE significa “Conformidad Europea” y es una marca europea que se utiliza para determinados productos industriales, entre otros los productos médicos. Está amparada bajo la Directiva 93/68/CEE.

El proceso regulatorio del software médico debe realizarse a través de los siguientes pasos:

  1. Clasificación MDR-IVDR
  2. Clasificación (Clase de Riesgo)
  3. Requerimientos regulatorios y normas técnicas
  4. Desarrollo del software médico
  5. Documentación técnica
  6. Sistemos de gestión de calidad
  7. Procedimiento de evaluación de la conformidad

proceso-regulatorio-de-un-producto-sanitario

1. Clasificación MDR-IVDR

El principal objetivo de las normativas y regulaciones europeas es garantizar que los productos sean seguros para usuarios y/o pacientes, y en segundo plano, que sean funcionales. Por este motivo, se categorizan en función del riesgo que entrañan los posibles errores que puedan derivarse de su uso.

Hay una serie de reglas de clasificación que deben ser revisadas de forma sistemática, según el uso previsto que tiene el producto que estamos desarrollando. En este sentido, existen dos regulaciones europeas principales de aplicación en los productos médicos. Hablamos de la Medical Devices Regulation (EU) 2017/745 (MDR), además de la In Vitro Medical Devices Regulation (EU) 2017/746 (IVDR).

¿Qué diferencia hay entre MDR e IVDR?

Un producto sanitario para diagnóstico in vitro según la 2017/746 (IVDR) es cualquier producto sanitario que consista en un reactivo, producto reactivo, calibrador, material de control, estuche de instrumental y materiales, instrumento, aparato, equipo o sistema, utilizado solo o en combinación con otros, destinado por el fabricante a ser utilizado in vitro para el estudio de muestras procedentes del cuerpo humano, incluidas las donaciones de sangre y tejidos, sólo o principalmente con el fin de proporcionar información relativa a:

  • un estado fisiológico o patológico
  • deficiencias físicas o mentales congénitas
  • predisposición a una dolencia o enfermedad
  • para determinar la seguridad y compatibilidad con receptores
  • para predecir la respuesta o reacción al tratamiento
  • para establecer o supervisar medidas terapéuticas.

Por lo tanto, un producto sanitario que esté en contacto con el cuerpo humano, como puede ser el caso de un wearable, no entra en la categoría de IVDR. Para que sea un IVDR tiene que estar trabajando con muestras de forma ex vivo.

 

2. Clasificación (Clase de Riesgo)

Una vez determinada la categoría del software médico desarrollado (MDR o IVDR), determinaremos su clasificación en cuanto a la clase de riesgo que le resulta de aplicación. Esta clase de riesgo viene determinada por las consecuencias que pueden tener los posibles errores del producto desarrollado. 

clasificacion-de-riesgo-de-un-producto-sanitario

 

Regla 11 de clasificación de MDSW (MDR)

Los programas informáticos destinados a proporcionar información que se utiliza para tomar decisiones con fines terapéuticos o de diagnóstico se clasifican en la 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.

Los programas informáticos destinados a observar procesos fisiológicos se clasifican en la clase IIa, salvo si se destinan a observar parámetros fisiológicos vitales, cuando la índole de las variaciones de dichos parámetros sea tal que pudiera dar lugar a un peligro inmediato para el paciente, en cuyo caso se clasifican en la clase IIb.

Todos los demás programas informáticos se clasifican en la clase I.

Teniendo en cuenta el uso previsto de un producto, y en el caso de que puedan aplicar varias reglas o si, para una misma regla, son aplicables diferentes subreglas, siempre aplicarán la regla y subregla más estrictas que den lugar a la clasificación más elevada.

Ejemplo de clasificación: Software de monitorización fisiológica (no vital)

En el caso de un software que monitorice fisiológicamente un paciente, pero que no sea vital, aplicará la clase IIa

“Los programas informáticos destinados a observar procesos fisiológicos se clasifican en la clase IIa”

Ejemplo de clasificación: Software de atención de emergencia

En el caso de un software que se utilice en la atención de emergencia, en procesos de gestión de la anestesia, o en cuidados intensivos, aplicarán la clases IIb / III.

“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”

Ejemplo de clasificación: Aplicación de apoyo a la concepción

En el caso de un software que se utilice para apoyar a la concepción, realizando recomendaciones o asistiendo en la detección del embarazo, aplicará la clase I.

“Todos los demás programas informáticos se clasifican en la clase I”

 

3. Requerimientos regulatorios y normas técnicas

Una vez tenemos identificados los riesgos que aplican al software de salud que estamos desarrollando y su clasificación, el equipo de investigadores y desarrolladores deben determinar por un lado los requisitos de ciberseguridad y de usabilidad que les son de aplicación. Deberá de trazarse un plan para verificar que no hayan puntos que dificulten la usabilidad en ningún aspecto de la interfaz, los cuales puedan llevar a errores de uso que potencialmente afecten a la seguridad de su producto y su funcionamiento.

Por otro lado, el equipo de investigadores y de desarrolladores deberán determinar todos los otros requisitos regulatorios que aplican al software de salud desarrollado. Estos pueden ser los relacionados con la gestión de riesgos, de gestión de calidad, de ciclo de vida del software, así como de evaluación clínica. Habrá que planificar y realizar estudios para demostrar a las autoridades que se han cumplido con los objetivos regulatorios de forma objetiva. 

Teóricamente, la regulación no obliga a realzar estos estudios de una forma determinada. A la práctica, siempre que exista una norma técnica (comunmente denominada estándar), esta deberá de seguirse. Las normas técnicas o ISOs se publican de forma recurrente y pueden llegar a quedar armonizadas al marco legal europeo. Esto sucede cuando la comisión europea emite un mandato para que los organismos de estandarización europeos (CEN y CENELEC) revisen los estandares para garantizar que quedan cubiertos.

 

Normas y guías de referencia

Requerimiento Estándar Título
Quality Management System (QMS) EN ISO 13485:2016 / AC:2018 Medical Devices – Quality Management Systems – Requirements for regulatory purposes
Risk Management System (RMS) EN ISO 14971:2019 Medical Devices – Application of risk management to medical devices
IEC / TR 80002.1 Medical device software – Part 1: Guidance on the application of ISO 14971 to medical devices
Software Lifecycle EN 62304:2006 / AC:2008 Medical device software – Software life-cycle processes
IEC 82304-1:2016 Health software – Part 1: General Requirements for product safety
ISO / IEC 14764:2006 Software Engineering – Software Life Cycle Processes – Maintenance
Clinical Evaluation MDCG 202-1 Guidance on clinical evaluation (MDR) / Performance evaluation (IVDR) of medical device
IMDRF / SaMD WG / N41 FINAL:2017 Software as a Medical Device (SaMD): Clinical Evaluation
Cybersecurity ISO / IEC 27000:2018 (en) (series) Information Technology – Security techniques – Information security management systems
MDCG 2019-16 rev.1 Guidance on cybersecurity for medical devices
IMDRF / CYBER WG /N60FINAL:2020 Principles and Practices for Medical Device Cybersecurity
Usability IEC 62366-1:2015 Medical devices – Application of usability engineering to medical devices
ISO 9241-210:2010 Ergonomics of human-system interaction – Human-centered design for interactive systems

 

Ciberseguridad

La normativa aplicable es la MDCG 2019-16, sobre la cual aplicarán también diferentes legislaciones. Estas giran principalmente entorno a la protección de datos y otras ciber-amenazas. Además, las medidas de mitigación de riesgos de seguridad cibernética pueden crear riesgos de seguridad adicionales. En dicho caso, estos también deben tenerse en cuenta en la gestión de riesgos de seguridad. Encontrarás mucha más información relacionada con la ciberseguridad y las leyes aplicables en este otro artículo.

 

proteccion-de-datos-cta

 

Gestión del Ciclo de Vida del Software Médico – IEC 62304

IEC 62304 identifica tres clases de seguridad para el software de dispositivos médicos, en función de la posibilidad de lesiones o daños para sus usuarios:

Será importante alinear el plan de desarrollo entorno a esta norma, la cual ofrece un marco de buenas prácticas para el desarrollo de software médico. Si el software a desarrollar es de clase C, entonces tendremos que cumplirla de forma estricta. Resultará esencial documentar todos los procesos en base a la norma IEC 62304.

 

gestion-ciclo-de-vida-software-medico

 

Gestión de Riesgos para el Software Médico

Otro requisito regulatorio imprescindible a tener en cuenta para el software médico es la gestión de riesgos. Comprende todo lo relacionado con el análisis, la evaluación y el control de los riesgos que pueden derivar del desarrollo de software de salud. Estos requisitos regulatorios vienen recogidos principalmente en la ISO 14971 y la IEC 62304.

 

4. Desarrollo del software médico

Este paso supondrá la puesta en desarrollo y producción del software médico. En este artículo encontrarás mucha más información al respecto y una guía paso a paso de cómo desarrollar software de salud.

 

software-medico-cta2

 

5. Documentación técnica

Llegados a este punto, habremos realizado todo el desarrollo de software médico teniendo en cuenta todas las regulaciones que le eran de aplicación. En caso de que existieran normas técnicas, las debemos haber comprado, estudiado y aplicado.

Realizaremos entonces todas las verificaciones y validaciones correspondientes para posteriormente redactar la documentación técnica con los siguientes puntos:

  • Información administrativa
  • Descripción y especificaciones del dispositivo: ¿Cómo es el software sanitario desarrollado? ¿Cuál es su uso previsto? ¿Por qué mecanismo de acción cumple sus funciones?
  • Información de diseño y fabricación ¿Cómo ha sido su proceso de diseño? ¿Cuál ha sido su proceso de fabricación?
  • Lista de verificación de GSPR: Requisitos de Rendimiento y Seguridad Generales. Gestión de riesgos, controles de diseño y fabricación.
  • Análisis de riesgo: ¿Es un MDR o un IVDR? ¿Qué clase de riesgo aplica?
  • Datos de prueba del dispositivo
  • Evaluación clínica / Desempeño: ¿Cómo se ha realizado el proceso de verificación y de validación clínica?
  • Sistemas de vigilancia y vigilancia post-mercado: ¿Cómo se garantizará la seguridad de manera recurrente?
  • IFU y etiquetas: Instrucciones de uso.

 

6. Sistemas de gestión de calidad

Deberemos de establecer procesos a través de los cuales podamos asegurarnos de que cumplimos con los criterios de gestión de calidad. Esto lo haremos trazando roadmaps y revisiones críticas de los planes de desarrollo. 

Una buena estrategia será realizarnos constantemente la pregunta ¿Qué me estoy dejando? De este modo, nos estaremos asegurando de estar cumpiendo la normativa técnica y los requisitos regultarorios, evitando perder así tiempo y dinero.

 

7. Procedimiento de evaluación de la conformidad

Último paso del proceso en el que recogeremos toda la documentación técnica y de gestión de calidad para enviársela al organismo notificado. Se realizará entonces el procedimiento de evaluación de la conformidad de nuestro software médico.

 

Preguntas Frecuentes (F.A.Q.)

¿Es necesario hacer estudios clínicos antes de comercializar el software médico?

Depende. Si te planteas no hacer estudios propios tienes que poder argumentar que hay suficiente evidencia clínica de la misma tecnología de la que está hecha el producto. Es decir, para el mismo grado de complejidad, para su mismo uso previsto, y con las mismas reivindicaciones de uso clínico. 

Para productos innovadores será difícil poder apoyarte en evidencias clínicas existentes, ya que tiene poco sentido desarrollar un producto que no esté diferenciado de la competencia. Esto será particularmente crítico para productos de clase III, aunque incluso para un caso I tendrás que hacer estudios propios.

 

¿Qué número de pacientes son necesarios para validar software médico?

No está tabulado. Se debe diseñar un estudio clínico en el que se plantean unas variables primarias y secundarias para refutar la hipótesis.  En función del intervalo de confianza que se suponga mínimo se van a requerir más o menos volumen de pruebas para demostrar científica y clínicamente el uso previsto. Una referencia serán publicaciones de otros softwares que estén en la literatura para determinar si resulta suficiente con 50, 100 o 1000 pacientes.

 

¿Un software que recoge datos de un paciente pero no los procesa es software médico?

En este caso no estaríamos hablando de software médico, ya que para que sea considerado como tal debe procesar los datos de algún modo.

 

¿Si el software médico está basado en inteligencia artificial, la aplicación de regulaciones es la misma?

La inteligencia artificial implica una serie de procesos de entrenamiento y de evolución del software con un cierto grado de libertad. Habrá que poder demostrar al organismo notificado que el software cumple con la normativa a medida que va evolucionando, ya que se exigirá un control sobre la evolución del software que garantice su perfil beneficio-riesgo.

 

GooApps, especialistas en el desarrollo de Software Médico

El equipo de desarrolladores de GooApps es especialista en el desarrollo de software médico y apps de salud. Te ayudamos a determinar la n0rmativa y regulaciones que aplican al producto que se quiere lanzar al mercado, acompañándote en todo el proceso. Trabajamos siguiendo la norma EN 62304:2006 / AC:2008, así como la norma ISO / IEC 14764:2006 en proyectos con mantenimiento. ¡Contacta con nosotros si tienes cualquier duda!

Da el siguiente paso

Completa el formulario y GooApps® te ayudará a encontrar la mejor solución para tu organización. ¡Contactaremos contigo muy pronto!

CONTACTAR

Al dar OK aceptas nuestra política de privacidad.