Un mensaje que a menudo queda flotando en los foros en los que se habla de mHealth es la necesidad de definir un marco legislativo para la certificación de apps de salud, que sirva para filtrar las que alcanzan unos estándares de efectividad y seguridad mínimos.

La buena noticia es que ese marco ya existe: es la directiva Directiva 93/42/CE sobre productos sanitarios, que en España se traspone en el Real Decreto 1591/2009, aunque si revisas cualquiera de los dos textos es probable que no estés muy de acuerdo con eso de la “buena noticia”, ya que el ejercicio de interpretación que es necesario realizar no es banal. Por si fuera poco, la Comisión Europea (CE) está a punto de publicar un nuevo reglamento para productos sanitarios que incorpora nuevos requisitos y revisa algunos de los ya existentes.

Por lo tanto, más que un problema de vacío normativo, lo que hay es una dificultad de interpretación de la legislación vigente desde la perspectiva de las apps de salud, máxime cuando el abanico es tan amplio y la casuística tan diversa.

No obstante, haciendo un ejercicio de conceptualización sobre los requerimientos normativos, es posible identificar una serie de pautas que facilitan la orientación del proceso de certificación de una aplicación móvil de salud. Vamos a ello:

Segmentación de apps

Analizando el enfoque que plantea la CE para los procesos de certificación se pueden diferenciar tres grupos de apps de salud:
1.Las que NO se consideran productos sanitarios.
2.Las que SI se asimilan a productos sanitarios, pero suponen un riesgo bajo para el usuario.
3.Las que SI se consideran productos sanitarios y además se asocian con un riesgo medio-alto para el usuario.

El primer paso, por tanto, es saber si la app entra o no dentro del ámbito de los productos sanitarios. Para ello se puede utilizar una sencilla guía basada en estas cuatro preguntas, cuyo origen y explicación la puedes encontrar en la entrada “4 preguntas para saber si una app es un dispositivo médico”
◾¿Es un programa informático?
◾¿Genera o modifica datos?
◾¿Está pensaba para beneficiar a pacientes individuales?
◾¿Está diseñada para ser usada como un producto sanitario?

Si la respuesta es afirmativa en los cuatro casos, la app se considera un producto sanitario y por tanto pertenece al grupo 2 o 3. Además, al estar diseñada para beneficiar a pacientes individuales, lo más probable es que también le aplique la legislación sobre protección de datos de carácter personal.

Procesos de certificación ajustados al nivel de riesgo

Una vez que se ha categorizado la aplicación móvil como producto sanitario, el siguiente paso es clasificarla en función del riesgo para el usuario. Para ello la CE ofrece la guía MedDev 2.4 que contiene una serie de reglas y diagramas de decisión.

No obstante, siguiendo con este enfoque de simplificación (sé que las generalizaciones son peligrosas) podríamos decir que si la app no implementa una función de medida, no usa accesorios invasivos, ni controla otros dispositivos de más riesgo como tensiómetros, bombas de insulina, etc … se asocia con un riesgo bajo o de clase I.

Para este tipo de aplicaciones la Directiva contempla un proceso de autocertificación en el que el desarrollador declara la conformidad con los requisitos establecidos para este tipo de aplicaciones e incorpora el marcado CE en la app.

Para la certificación de las aplicaciones de riesgo medio o alto, la Directiva exige la participación de los denominados Organizamos Notificados, que son organizaciones acreditadas por la autoridad nacional competente (en España la AEMPS), en un grado de exigencia acorde con el riesgo de la aplicación. En estos casos, son los Organismos Notificados los que emiten la declaración de conformidad y asignan un número de certificación que debe ir colocado junto al marcado CE.

Requisitos a cumplir

En este apartado vamos a hacer un repaso, no exhaustivo, de los principales requisitos que debe cumplir una app de salud considerada como producto sanitario, aunque para ser preciso debería decir el desarrollador, ya que, como se puede apreciar a continuación, los requisitos se centran más en el proceso de gestión del ciclo de vida de la app que en la propia aplicación.

1.- Sistema de gestión de la calidad

El desarrollador debe definir, implantar y mantener un sistema de gestión de la calidad proporcionado a la clase de riesgo de sus aplicaciones. Se pueden tomar como referencia estándares generales de calidad como ISO 9.001 o específicos del ámbito sanitario como ISO 13.485.

La estructura organizativa debe contemplar la figura de responsable del cumplimiento de la normativa, cuya formación y experiencia debe ser acorde con el riesgo de las aplicaciones generadas.

2.- Gestión del ciclo de vida de la app

Los procesos de diseño, desarrollo y mantenimiento de la aplicación deben estar sistematizados, incluyendo las etapas de verificación y validación de los requisitos antes de la liberación del software, y con evidencias de implementación en el caso de la app que se quiere certificar.

Una norma que habitualmente se toma como referencia para la gestión del ciclo de vida del software es la UNE-EN 62.304.

3.- Gestión de riesgos

Integrado con los procesos de gestión del ciclo de vida, debe haber también un proceso que sirva para identificar peligros para el usuario derivados del uso de la aplicación, que estime los riesgos asociados, que intente eliminarlos o reducirlos al mínimo mediante el diseño y que determine la información sobre riesgos residuales que deben trasladarse al usuario.

La norma referente para la definición de un proceso de gestión de riesgos es la UNE-EN-ISO 14.971.

4.- Evaluación y seguimiento clínicos

Los requisitos de efectividad y seguridad definidos para el diseño y desarrollo de la aplicación deben estar basados en datos clínicos pertinentes, obtenidos a partir de búsquedas en bibliografía científica, experiencia clínica o investigaciones clínicas.

Por otro lado, la confirmación del cumplimiento de estos requisitos, en las condiciones previstas de uso, así como la evaluación de los efectos secundarios indeseables y de la aceptabilidad de la relación beneficio/riesgo también debe basarse en datos clínicos.

5.- Plan de vigilancia poscomercialización

El objetivo es canalizar la información proveniente de profesionales, usuarios u otros grupos de interés sobre incidencias, quejas o presuntos incidentes relacionados con el uso de la aplicación. Una parte de este plan estará dedicada al seguimiento clínico poscomercialización, cuyo fin es la confirmación de la efectividad y seguridad de la aplicación, de la aceptabilidad de los riesgos identificados y la detección de riesgos emergentes sobre la base de pruebas objetivas.

Protección de datos de carácter personal

Otra fuente de requisitos normativos que hay que considerar si se manejan datos de carácter personal es la Directiva 95/46/CE, transpuesta en España en la Ley Orgánica 15/1999, conocida como la LOPD, y en el reglamento 1720/2007 que la desarrollada.

La seguridad de la información es un factor clave para el avance de la mHealth que me gustaría tratar con un cierto nivel de detalle, pero esta entrada me está quedado un tanto densa por lo que prefiero dejarlo para otro post. Prometido!


NOTA: Recuerda que en España los desarrolladores de apps consideradas como productos sanitarios deben disponer de una licencia previa de funcionamiento emitida por la Agencia Española de Medicamentos y Productos Sanitarios.