La salud digital se topa con la burocracia: Lo que la industria farmacéutica puede aprender del Software como Dispositivo Médico

Pharma se apresura a añadir componentes digitales a los medicamentos — aplicaciones complementarias, plataformas de datos, soporte de decisiones habilitado por IA — pero el software no sigue la misma lógica regulatoria que las tabletas e inyectables. En muchos proyectos, la porción de software cruza al ámbito de los dispositivos médicos regulados (Software como Dispositivo Médico, o SaMD). Los equipos que tratan el software como una función secundaria descubren tarde que conlleva su propia clasificación, calidad y obligaciones postcomercialización. Este artículo traduce el manual de SaMD para líderes farmacéuticos para que puedan planificar la evidencia, los plazos y el riesgo desde el día uno.

Panorama del mercado 2025: por qué esto importa ahora

La lista pública de la FDA ahora incluye más de 1,000 dispositivos médicos habilitados por AI/ML autorizados, aprobados o con clearance en EE. UU. — un aumento pronunciado que indica la rapidez con que los productos impulsados por software están entrando en las rutas de atención.

Las herramientas de salud digital siguen proliferando, con cientos de miles de apps en circulación; cada vez más, la biofarmacia las usa para recopilar datos del mundo real y apoyar la adherencia, la monitorización de seguridad y los resultados.

1) ¿Qué es SaMD — y por qué debería importarle a la industria farmacéutica?

SaMD es software destinado a un propósito médico sin formar parte de un dispositivo hardware. Los ejemplos incluyen algoritmos de IA para diagnóstico, apps dirigidas al paciente que guían la terapia y herramientas de soporte a la decisión para clínicos. La industria farmacéutica se relaciona con SaMD cuando:

• Las apps complementarias se emparejan con terapias.
• Las plataformas de datos del mundo real respaldan expedientes regulatorios o de HTA.
• Se integran algoritmos en combinaciones fármaco‑dispositivo (p. ej., inhaladores o jeringas conectadas).

Si entra en SaMD, hereda las reglas de dispositivo — clasificación, documentación del ciclo de vida del software, ingeniería de usabilidad, gestión de riesgos y vigilancia postcomercialización.

2) SaMD no es “solo software” — es un producto regulado

Las expectativas clave incluyen:

• Calidad y ciclo de vida: ISO 13485 para el SGC y IEC 62304 para el ciclo de vida del software.
• Usabilidad: evidencia de factores humanos según IEC 62366 cuando pacientes o profesionales sanitarios interactúan con la IU.
• Riesgo: gestión de riesgos ISO 14971 ligada al uso previsto y al daño.
• Especificidades del mercado: vías previas a la comercialización basadas en el riesgo de la FDA (510(k), De Novo, PMA) y clasificación del MDR de la UE (en particular la Regla 11 para software). Planee esto desde el principio — añadirlo a posteriori es lo que provoca retrasos y retrabajo.

3) Perspectiva regulatoria global de un vistazo

Estados Unidos (FDA):Vías previas a la comercialización basadas en el riesgo. Para SaMD habilitado por AI/ML, la FDA finalizó la orientación sobre Predetermined Change Control Plans (PCCPs), que permiten a los patrocinadores acordar de antemano cómo pueden actualizarse los modelos tras el clearance/aprobación. La agencia también ha publicado Good Machine Learning Practice (GMLP) y principios de transparencia para gestionar el sesgo, el rendimiento y la comunicación a los usuarios.

Unión Europea (MDR):La Regla 11 empuja mucho software de decisión clínica hacia clase IIa/IIb/III, lo que desencadena revisión por un organismo notificado y evidencia clínica robusta. La guía actualizada de MDCG aclara la cualificación y clasificación del software bajo MDR/IVDR.

Ley de IA de la UE:La IA usada en dispositivos médicos generalmente se considerará de “alto riesgo”, superponiendo requisitos específicos de IA (gobernanza de datos, transparencia, gestión de riesgos, supervisión humana) además del MDR/IVDR, que se implementarán por fases tras la entrada en vigor.

Específico para pharma (PDURS):La guía borrador de la FDA sobre Prescription Drug Use‑Related Software (PDURS) explica cómo las salidas de software difundidas por un patrocinador de medicamentos pueden ser reguladas como etiquetado del fármaco — relevante cuando su software está vinculado a un medicamento en lugar de regularse como dispositivo.

4) Notas de caso: emparejamientos pharma‑digital en la práctica

Respiratorio conectado:Los sensores y apps de Propeller Health se han emparejado con importantes marcas de inhaladores para apoyar la adherencia y el seguimiento de síntomas.

Ecosistemas de diabetes:La adquisición de mySugr por Roche integró la gestión de la diabetes centrada en la app en un amplio portafolio pharma/dispositivo, mezclando software, medidores y servicios.

Lecciones de la píldora digital:ABILIFY MYCITE (Otsuka + Proteus) mostró cómo las combinaciones fármaco‑dispositivo‑software pueden obtener aprobación pero aun así enfrentarse a desafíos de adopción, privacidad y valoración.

Terapéuticas digitales con prescripción:Las asociaciones alrededor de tratamientos por software (p. ej., reSET/reSET‑O) ilustraron tanto la viabilidad regulatoria como los obstáculos comerciales.

5) Cinco lecciones prácticas que la industria farmacéutica debería tomar del desarrollo de SaMD

1. Clasifique temprano. Aplique los criterios de la FDA y la Regla 11 del MDR en la fase conceptual; documente el uso previsto y las decisiones clínicas que su software influye.

2. Construya la columna vertebral del SGC. Establezca controles de diseño, expedientes de riesgos y procesos del ciclo de vida del software antes de programar más allá de un prototipo.

3. Trate la usabilidad como seguridad. Planifique pruebas formativas y sumativas; vincule las decisiones de la IU a controles de riesgo y riesgos residuales en su expediente ISO 14971.

4. Valide su canal de datos. Documente las fuentes de datos, la calidad, la representatividad y las salvaguardas de privacidad; esto sustenta tanto la seguridad de la IA como la confianza.

5. Diseñe para actualizaciones. Para AI/ML, anticipe actualizaciones de modelos con protocolos claros de cambio (p. ej., PCCP en EE. UU.) y un plan de monitorización postcomercialización.

6) IA/ML: Los modos de fallo para prever

Deriva del algoritmo: El rendimiento en el mundo real puede degradarse a medida que las poblaciones, los patrones de práctica o los sensores cambian. Monitorice y reentrene según un plan controlado.

Sesgo y representatividad: Datos de entrenamiento no representativos pueden perjudicar a subpoblaciones. Establezca métricas de sesgo, prespecifique mitigaciones y sea transparente sobre los límites.

Explicabilidad y transparencia: Proporcione información clara a los usuarios sobre el uso previsto, las entradas, las salidas y los modos de fallo conocidos; alinee con los principios de transparencia publicados.

Trabajo en equipo Humano‑IA: Defina qué decide el humano frente a lo que sugiere el software; diseñe interfaces que reduzcan, no aumenten, la carga cognitiva.

7) Después del lanzamiento: Ciclo de vida, ciberseguridad y vigilancia

• Post‑comercialización UE MDR: Mantenga un plan de PMS; para clase IIa/IIb/III, prepare Periodic Safety Update Reports (PSURs) que sinteticen datos de seguridad y rendimiento.

• Expectativas en EE. UU.: Monitorice el rendimiento en el mundo real; para dispositivos con componentes cyber, aborde el diseño seguro, la gestión de vulnerabilidades, la divulgación coordinada y proporcione una software bill of materials (SBOM) conforme a las expectativas vigentes de la FDA.

• Gestión de actualizaciones: Vincule parches de software y actualizaciones de modelos a la evaluación de riesgos, verificación/validación y comunicaciones al usuario. Documente todo.

8) Ética, privacidad y confianza del paciente

Sea explícito sobre qué datos recopila, por qué y cómo se protegen. Asegure conformidad con GDPR/HIPAA, minimice los datos cuando sea posible y comunique beneficios y riesgos con claridad. La confianza es una decisión de diseño: incorpórela en la incorporación, los flujos de consentimiento y el etiquetado.

9) Lista de verificación para equipos farmacéuticos que entran en SaMD

Conclusión

El software ahora forma parte de la terapia. Los equipos que traten el SaMD como un producto regulado desde el principio —con clasificación clara, evidencia adecuada para el propósito y un plan para actualizaciones y vigilancia— lanzarán más rápido y con menos sorpresas.

Referencias

1. FDA: lista de dispositivos médicos con AI/ML habilitada; orientación PCCP; GMLP y principios de transparencia.

2. UE – MDR Rule 11 and MDCG guidance on software; EU AI Act (obligaciones de alto riesgo).

3. Notas de casos – Otsuka/Proteus ABILIFY MYCITE; Propeller Health partnerships; Roche acquisition of mySugr; análisis de mercado sobre la adopción de la salud digital.