¿La trampa indetectable? La caja negra de los nuevos requisitos de DiGA
En medXteam, los datos clínicos son nuestra prioridad. Como CRO, no solo realizamos ensayos clínicos con dispositivos médicos de acuerdo con el MDR y la norma ISO 14155, sino que también ofrecemos todas las demás opciones y formas de recopilación de datos. En esta ocasión, nos centramos nuevamente en las Aplicaciones de Salud Digital (DiGA). Aquí también se recopilan datos. Pero esta vez, la pregunta central es: ¿Qué posibles desafíos plantean los requisitos de DiGA a los fabricantes?
Abreviaturas
BSI Oficina Federal de Seguridad de la Información
Aplicación de Salud Digital DiGA
Registro electrónico del paciente ePA
KBV Asociación Nacional de Médicos de Seguros de Salud Estatutarios
Reglamento de dispositivos médicos MDR; Reglamento UE 2017/745
Sistema de Gestión de Calidad QMS
Regulaciones subyacentes
Reglamento UE 2017/745 (MDR)
Ley de Implementación de Dispositivos Médicos (MPDG)
ISO 14155
ISO 27001
Directriz DiGA V3.4
Ley de Modernización de la Asistencia Sanitaria Digital y la Atención Sanitaria (DVPMG)
Reglamento UE 2016/679 (RGPD)
Directriz Técnica TR-03161
1. Introducción
Las DiGA (Aplicaciones de Salud Digital) se han vuelto cada vez más importantes como aplicaciones digitales en la atención sanitaria en los últimos años. Pueden ayudar a mejorar la atención médica y facilitar el acceso a los servicios de salud. Brindan a los pacientes la capacidad de controlar su salud y controlar sus enfermedades, al tiempo que brindan a los médicos datos valiosos para tomar mejores decisiones.
Sin embargo, el contexto regulatorio de las aplicaciones de salud digital (DiGAs) presenta no solo oportunidades para los pacientes y el personal médico, sino también desafíos para los fabricantes de estos productos. Ya se han definido numerosos requisitos que los fabricantes deben implementar y documentar en plazos específicos. Estos requisitos, que examinaremos con más detalle en este artículo, enfrentan a los fabricantes a la cuestión fundamental de clasificar sus productos de software médico. Si bien la mayoría de las DiGAs se clasifican actualmente como productos de Clase I, la implementación de los nuevos requisitos podría resultar en una clasificación más alta. Esto no es solo una cuestión regulatoria fundamental; la certificación del sistema de gestión de la calidad (SGC), las consiguientes consideraciones de costo y tiempo, y la necesidad de presentar el caso a los inversores también son aspectos importantes de este análisis.
Teniendo en cuenta el debate en nuestra última entrada del blog sobre por qué los médicos se muestran reacios a recetar DiGAs, surge la pregunta de cómo se relacionarán los inmensos desafíos con los beneficios potenciales de las aplicaciones digitales en el futuro.
2. Requisitos reglamentarios para los fabricantes de DiGA
Incluso ahora, como fabricante de DiGA, debe implementar ciertos requisitos en el desarrollo de productos y en los procesos internos de la empresa. El siguiente capítulo examina los requisitos actuales y futuros, que se basan principalmente en las directrices de DiGA.
2.1 Requisitos aplicables
Actualmente, todos los fabricantes deben contar con un sistema de gestión de la seguridad de la información. Tanto su implementación como su certificación como prueba de cumplimiento son obligatorias. Existen dos opciones: según la norma ISO 27001 o "ISO 27001 basada en la protección de la línea base de TI (Norma BSI 200-2: Metodología de protección de la línea base de TI)".
La Ley de Modernización de la Atención Sanitaria Digital (DVPMG) también estipula que, independientemente de los requisitos de seguridad de la aplicación de salud digital (DiGA), se debe realizar una prueba de penetración en todos los componentes. Las pruebas de penetración se encuentran entre los "requisitos básicos aplicables a todas las aplicaciones de salud digital" enumerados en el Anexo 1. El concepto de implementación de pruebas de penetración de la BSI y los 10 principales riesgos de seguridad actuales de OWASP deben utilizarse como base para el diseño de las pruebas. Se debe proporcionar al BfArM la prueba de la ejecución de las pruebas correspondientes si se solicita.
2.2 ¿Qué nuevas características se añadirán y cuándo?
La autenticación segura de las personas aseguradas mediante identidad digital debe implementarse a más tardar el 1 de enero de 2024. Originalmente, este requisito debía implementarse el 1 de enero de 2023. Sin embargo, las compañías de seguros de salud tienen hasta el 1 de enero de 2024 para crear la identidad digital.
"Código Social (SGB) Libro Quinto (V) - Seguro de Salud Obligatorio - (Artículo 1 de la Ley de 20 de diciembre de 1988, Boletín Oficial Federal I, pág. 2477)
Artículo 291 Tarjeta Sanitaria Electrónica:
(8) A más tardar el 1 de enero de 2024, las entidades de seguro de salud deberán, previa solicitud, proporcionar a las personas aseguradas una identidad digital segura para el sistema de salud, además de la tarjeta sanitaria electrónica, que cumpla con los requisitos del párrafo 2, números 1 y 2, y permita el suministro de datos de conformidad con el artículo 291a, párrafos 2 y 3, por parte de las entidades de seguro de salud."
A partir del 1 de enero de 2024 , deberá garantizarse la exportación regular y automatizada de los datos recopilados por las aplicaciones de salud digital (DiGA) al expediente electrónico del paciente (ePA). La Asociación Nacional de Médicos de Seguros de Salud Obligatorios (KBV) define los requisitos correspondientes para la interoperabilidad semántica y sintáctica.
A partir del 1 de agosto de 2024 , deberá estar disponible un certificado que acredite el cumplimiento de los requisitos de protección de datos, de conformidad con el artículo 42 del RGPD (Reglamento (UE) 2016/679)
"Código Social (SGB) Libro Quinto (V) - Seguro de Salud Obligatorio - (Artículo 1 de la Ley de 20 de diciembre de 1988, Boletín Oficial Federal I, pág. 2477)
Sección 139e Lista de aplicaciones de salud digital; Autorización para emitir reglamentos:
(11) El Instituto Federal de Medicamentos y Dispositivos Médicos, de acuerdo con el Comisionado Federal para la Protección de Datos y la Libertad de Información y en consulta con la Oficina Federal de Seguridad de la Información, establecerá, por primera vez antes del 31 de marzo de 2022 y posteriormente de forma general anual, los criterios de prueba para los requisitos de protección de datos que deben demostrar las aplicaciones de salud digital de conformidad con el párrafo 2, frase 2, número 2. A partir del 1 de agosto de 2024, el fabricante deberá aportar prueba de cumplimiento de los requisitos de protección de datos mediante la presentación de un certificado emitido sobre la base de los criterios de prueba de conformidad con la frase 1, de acuerdo con el artículo 42 del Reglamento (UE) 2016/679."
La directriz técnica TR-03161 engloba los requisitos para aplicaciones sanitarias definidos por la Oficina Federal de Seguridad de la Información (BSI) y forma parte de los requisitos de seguridad de datos para una DiGA (Aplicación de Salud Digital) según el artículo 139e, apartado 10, del Código Social Alemán, Libro V (SGB V). El certificado correspondiente deberá presentarse a partir del 1 de enero de 2025
"Código Social (SGB) Libro Quinto (V) - Seguro de Salud Obligatorio - (Artículo 1 de la Ley de 20 de diciembre de 1988, Boletín Oficial Federal I pág. 2477)
Sección 139e Lista de Aplicaciones de Salud Digital; Autorización para Emitir Reglamentos:
(10) La Oficina Federal de Seguridad de la Información, de acuerdo con el Instituto Federal de Medicamentos y Dispositivos Médicos y en consulta con el Comisionado Federal de Protección de Datos y Libertad de Información, establecerá, por primera vez antes del 1 de enero de 2024 y posteriormente de forma general anual, los requisitos de seguridad de datos que deben demostrar las aplicaciones de salud digital de conformidad con el párrafo 2, frase 2, número 2. A partir del 1 de junio de 2024, la Oficina Federal de Seguridad de la Información ofrecerá procedimientos para verificar el cumplimiento de los requisitos de conformidad con la frase 1, así como procedimientos para confirmar el cumplimiento de los requisitos de conformidad con la frase 1 mediante los certificados correspondientes. La prueba del cumplimiento de los requisitos de seguridad de datos por parte del fabricante deberá proporcionarse mediante la presentación de un certificado de conformidad con la frase 2 a más tardar el 1 de enero 2025." lidera."
3. Requisitos adicionales
En principio, todos los requisitos reglamentarios que se aplican generalmente a todos los dispositivos médicos también se aplican a las aplicaciones de salud digital. Esto significa que se debe preparar la documentación técnica para que una aplicación de salud digital demuestre el cumplimiento de los requisitos esenciales de seguridad y rendimiento del MDR. Todo fabricante de dispositivos médicos requiere un sistema de gestión de la calidad (SGC) basado en la norma ISO 13485, de conformidad con la normativa aplicable. Desde la entrada en vigor del MDR, esto también se aplica a los fabricantes de dispositivos de Clase I.
Sin embargo, la gama de requisitos en el entorno digital sigue creciendo. Por ejemplo, ahora surge la pregunta adicional de si debería introducirse un derecho de retorno de 14 días para los pacientes tras la prescripción inicial de la DiGA (Aplicación de Salud Digital).
4. Consecuencias de estos nuevos requisitos
¿Qué consecuencias podrían acarrear estos requisitos adicionales? Cabe señalar que los plazos aún están por venir, lo que significa que la gestión real de las posibles consecuencias para los fabricantes sigue siendo hipotética. La experiencia práctica solo se obtendrá en los próximos meses. No obstante, un aspecto de los requisitos resulta especialmente crítico: la clasificación. La clasificación del software se basa fundamentalmente en las normas de clasificación del Anexo VIII del MDR. Sin embargo, también existen documentos de orientación válidos que pueden servir de apoyo. La norma 11 estipula que «el software destinado a proporcionar información utilizada para la toma de decisiones con fines diagnósticos o terapéuticos se clasifica como Clase IIa».
Imagine ahora el siguiente escenario hipotético: Como fabricante, ha implementado con éxito todas las funcionalidades de exportación y los requisitos de interoperabilidad necesarios. Ahora es posible exportar de forma regular y automatizada los datos recopilados con su DiGA (Aplicación de Salud Digital) al historial clínico electrónico (ePA) del paciente, así como exportar cierta información del DiGA como paciente. Su concepto de DiGA incluye, entre otras cosas, proporcionar materiales para ejercicios que los pacientes deben realizar en casa. Supongamos que a la Sra. Müller se le prescribe su DiGA y la utiliza diligentemente. Los datos recopilados se transfieren al ePA de la Sra. Müller y, por lo tanto, su médico tratante tiene acceso a ellos. Además, la Sra. Müller exporta el contenido genérico proporcionado por usted como fabricante, que también contiene datos relacionados con su uso individual del DiGA. En la siguiente cita médica de la Sra. Müller, se discute el uso de la DiGA (tanto la exportación de la Sra. Müller como los datos de su ePA están disponibles), tras lo cual su médico tratante le aconseja suspender el ejercicio número 5 en su caso específico. Por lo tanto, de acuerdo con la Regla 11, teóricamente llegamos a un escenario en el que la DiGA (Aplicación de Salud Digital) proporcionó información que motivó al médico a recomendarle terapia a la Sra. Müller. El resultado de este escenario: mediante la implementación de los requisitos, un producto de Clase I se convirtió en un producto de Clase IIa.
En los siguientes capítulos se examinarán en detalle las posibles consecuencias de dicha clasificación.
4.1 Certificación
Ya hemos explicado que, desde la entrada en vigor del Reglamento de Dispositivos Médicos (MDR), todo fabricante de dispositivos médicos debe contar con un Sistema de Gestión de la Calidad (SGC). Sin embargo, solo los fabricantes de productos de Clase IIa o superior están obligados a certificar su SGC. Para los fabricantes de Clase I, basta con establecer y mantener una estructura de procesos adecuada. Si, como consecuencia de los requisitos, se produce una clasificación superior, su SGC deberá estar certificado para garantizar que usted, como fabricante, siga cumpliendo con la normativa aplicable. Teniendo en cuenta los plazos de transición del MDR, este aspecto es, sin duda, el más crítico en cuanto al tiempo y requiere atención inmediata a las posibles consecuencias de la clasificación para su producto.
4.2 Problema de costes/Inversores
Los requisitos existentes ya suponen altos costes para los fabricantes. No solo deben completar con éxito una auditoría de la implementación de su Sistema de Gestión de Seguridad de la Información (SGSI), sino que el proceso de recopilación de datos que lleva al registro exitoso de sus aplicaciones de salud digital (DiGA) también es largo y costoso. Los requisitos adicionales suponen ahora una carga adicional para los fabricantes, cuya viabilidad económica a menudo depende de la disposición de sus inversores a invertir.
4.3 Documentación técnica
La documentación técnica sirve como prueba del cumplimiento de los requisitos fundamentales de seguridad y rendimiento del MDR para cada dispositivo médico. Los componentes clave de esta documentación técnica incluyen la gestión de riesgos y el archivo de usabilidad con las pruebas correspondientes para la aplicación del producto. En el caso del software, el archivo de software también constituye una parte importante de la documentación. Esto abarca tanto la definición de los requisitos como su implementación real en forma de arquitectura, así como otra documentación de proceso relevante para verificar y validar el éxito del desarrollo. El nivel de detalle de esta documentación técnica, en particular en lo que respecta al archivo de software, depende, entre otros factores, de la clasificación del producto de software. Si se obtiene una clasificación superior, la documentación técnica también debe revisarse en consecuencia, lo que genera costes y puede inmovilizar temporalmente los recursos de la empresa. Además, debe ser certificada por un organismo notificado; el fabricante ya no puede emitir la Declaración UE de Conformidad por sí mismo.
5. Relación con la última entrada del blog
En nuestra última entrada del blog, analizamos en detalle la reticencia de los médicos a recetar aplicaciones de salud digital (DiGAs). A pesar de sus numerosas ventajas, muchos médicos dudan en prescribirlas. Una de las razones es la incertidumbre sobre su eficacia. También existe preocupación por la seguridad y la protección de los datos de las DiGAs. Otro factor es la falta de tiempo y recursos para apoyar a los pacientes en su uso. Además, a muchos médicos les preocupa la carga de trabajo adicional que supone la prescripción y el seguimiento de las DiGAs. Y, por último, existe la preocupación de si el reembolso por parte de las aseguradoras médicas está realmente garantizado o si una receta podría dar lugar a una reclamación de reembolso.
Los requisitos descritos anteriormente para las aplicaciones de salud digital (DiGA) se relacionan principalmente con la seguridad y, sobre todo, con la protección de los datos de las aplicaciones comercializadas, abordando así al menos un aspecto de la reticencia a prescribirlas. Sin embargo, la implementación de estos requisitos también conlleva un riesgo comercial significativo para los fabricantes. Considerando los costos adicionales que implica implementar todos estos aspectos, y considerando también la posibilidad de que las prescripciones de DiGA que se registren con éxito solo avancen lentamente, el punto de equilibrio se aleja cada vez más, y la viabilidad económica del desarrollo de dichas DiGA debe cuestionarse seriamente.
6. Conclusión
Las aplicaciones de salud digital (DiGAs) tienen el potencial de mejorar la atención médica y facilitar el acceso de los pacientes a ellas. Sin embargo, las enormes oportunidades que ofrecen estos productos se ven contrarrestadas por enormes desafíos, especialmente para los fabricantes.
Como consecuencia clave de la implementación de los requisitos identificados, pudimos determinar la clasificación resultante de la DiGA (Aplicación de Salud Digital). Esto afecta tanto a los fabricantes que aún se encuentran en la fase inicial de desarrollo de su producto como a aquellos que ya han obtenido el listado preliminar o final de su DiGA. Una posible clasificación más alta tiene consecuencias de gran alcance, que incluyen la certificación del sistema de gestión de calidad y la documentación técnica, así como todos los aspectos comerciales (p. ej., costos, tiempo e inversión). Por lo tanto, los fabricantes deben abordar primero la correcta clasificación futura de su dispositivo médico para poder tomar las medidas necesarias.
La pregunta inicial sobre cómo se relacionarán los inmensos desafíos con los beneficios potenciales de las aplicaciones digitales en el futuro no tiene una respuesta definitiva. Los requisitos deben implementarse dentro de los plazos establecidos, por lo que las consecuencias para los fabricantes solo se conocerán en los próximos meses. Sin embargo, la multitud de requisitos demuestra claramente que la estricta regulación de este tipo particular de producto de software médico necesita ser reevaluada urgentemente. En última instancia, el objetivo es ofrecer valor añadido a los pacientes y apoyarlos y guiarlos en la gestión de sus enfermedades en su vida diaria.
7. Cómo podemos ayudarle
Estaremos encantados de ayudarle a conseguir un listado exitoso de su DiGA mediante una evaluación temprana de la clasificación del producto en función de las características planificadas.
En medXteam aclaramos si y en caso afirmativo, qué ensayo clínico debe realizarse, en qué condiciones y según qué requisitos durante la fase previa al estudio: en 3 pasos determinamos la estrategia correcta y rentable en relación con el ensayo clínico requerido. en su caso Recopilación de datos.
Si se va a realizar un ensayo clínico, primero se deben cumplir requisitos básicos de seguridad y rendimiento. Los datos del ensayo clínico luego se incorporan a la evaluación clínica, que a su vez forma la base para las actividades de seguimiento clínico poscomercialización (PMCF) (incluido un estudio PMCF).
Además, todos los fabricantes de dispositivos médicos requieren un sistema de gestión de calidad (QMS), incluso cuando desarrollan productos de Clase I.
Le acompañamos durante todo el proyecto con su dispositivo médico, empezando por una consulta inicial gratuita, le ayudamos con la introducción de un sistema de gestión de calidad, la planificación e implementación del estudio hasta la documentación técnica, siempre con referencia principal a los datos clínicos del producto: desde el principio hasta el final Fin.
¿Tienes ya algunas preguntas iniciales?
Puede obtener una consulta inicial gratuita aquí: consulta inicial gratuita