El software como dispositivo médico (SaMD) es cualquier programa que realiza una tarea médica por sí solo, sin formar parte de una máquina física. Una app que analiza la foto de un lunar y señala un posible melanoma encaja en la definición. El código que hace funcionar un equipo de resonancia magnética no cuenta, porque forma parte del hardware.
Esa distinción determina mucho más de tu producto de lo que imaginas. Define los registros que debes conservar, las pruebas que tienes que demostrar que hiciste y, en algunos mercados, si puedes vender siquiera. Muchos equipos no se plantean la pregunta por su cuenta. La oyen por primera vez de un inversor, de un comprador hospitalario o de un abogado.
Una aclaración antes de seguir: este artículo no ofrece asesoramiento legal ni regulatorio. Redwerk se encarga del desarrollo de software para el sector sanitario, mientras que clasificar tu producto y presentarlo ante la FDA corresponde a un consultor cualificado. Lo que hacemos es construir la solución y acompañarte en cada revisión y auditoría, trabajando codo con codo con tu equipo para garantizar el cumplimiento total. A lo largo del texto enlazamos los documentos oficiales, para que leas la fuente en lugar de fiarte de nuestro resumen.
Lo que sigue es la mitad de ingeniería del asunto. Verás qué entra en la definición, cómo se construyen las categorías de riesgo y qué exige de verdad un desarrollo conforme a quienes escriben el código.
Qué cuenta como software como dispositivo médico
La FDA y el International Medical Device Regulators Forum, abreviado normalmente como IMDRF, definen el término como “software destinado a usarse con uno o varios fines médicos que cumple esos fines sin formar parte de un dispositivo médico de hardware”.
Si lo desglosas, salen dos preguntas:
- ¿El producto responde a un fin médico, es decir, ayuda a diagnosticar, tratar, prevenir o monitorizar una enfermedad o una dolencia?
- ¿Hace ese trabajo de forma independiente, y no como componente dentro de un equipo?
Si la respuesta a las dos es sí, estás dentro del alcance.
Dentro de la definición encajan tres grupos conocidos:
- Herramientas de análisis de imagen que miden o interpretan una prueba y devuelven un hallazgo al radiólogo
- Sistemas de apoyo a la decisión clínica que sugieren un diagnóstico, una dosis o una pauta de tratamiento
- Ciertas apps de monitorización de la salud, sobre todo las que leen datos de sensores y avisan al usuario de una dolencia concreta
Ese tercer grupo es el que sorprende. Una lectura de frecuencia cardiaca por sí sola es solo un número. Pero en cuanto un producto interpreta el patrón y le dice a alguien que puede tener un ritmo irregular, ha entrado en terreno médico.
Dos tipos de software sanitario quedan fuera de la definición, y los dos importan a nivel comercial. El primero es todo lo integrado en la función principal de un dispositivo. El firmware de una bomba de infusión entra en las normas como parte de ese hardware, no como producto por sí mismo. El segundo es la tecnología administrativa: motores de facturación, gestión de citas, planificación de turnos y gestión de historiales tocan datos de pacientes sin hacer ninguna afirmación clínica. Esas herramientas siguen teniendo obligaciones de privacidad. También son un objetivo habitual de la automatización robótica de procesos en el sector sanitario, que tratamos por separado.
Cuándo una app de bienestar pasa a ser un dispositivo médico
El límite se ve mejor en un producto que está justo al lado. Redwerk reconstruyó y mantiene hoy Pridefit, una app de fitness por suscripción para la comunidad LGBTQIA+ que gestiona planes de entrenamiento, retos personales y seguimiento del rendimiento. Maneja datos de salud a diario y cambia el comportamiento del usuario por diseño.
Nada de eso la convierte en un producto regulado. Pridefit no afirma diagnosticar ni tratar nada, así que se queda del lado del bienestar general. Añade a esa misma app una función que lea los datos de entrenamiento y avise al usuario de un posible problema cardiaco, y la conversación cambia al instante. La distancia entre una herramienta de bienestar y un producto regulado puede ser una sola frase de tu texto de marketing.
Cómo funciona la clasificación SaMD
La clasificación SaMD no empieza por tu stack tecnológico ni por el tamaño de tu empresa. Empieza por dos preguntas sobre consecuencias, y las respuestas se combinan en una categoría de riesgo.
La primera es cuánto peso tiene el resultado de tu producto en una decisión clínica:
- Informa la gestión clínica, es decir, el clínico usa el resultado como una entrada más entre varias
- Orienta la gestión clínica, es decir, el resultado determina el siguiente paso asistencial
- Trata o diagnostica, es decir, el propio producto entrega el hallazgo o la terapia
La segunda es cuánto riesgo corre ya el paciente:
- Situación no grave, donde una respuesta equivocada difícilmente causará un daño duradero
- Situación grave, donde un retraso o un error podría causar una lesión real
- Situación crítica, donde un resultado erróneo podría contribuir a la muerte o a un daño irreversible
Junta las dos respuestas y caes en una de las cuatro categorías IMDRF, desde I, la más baja, hasta IV, la más alta. La escala describe cuánto riesgo conlleva tu producto, y nada más.
Informa la gestión clínica
I
I
II
Orienta la gestión clínica
I
II
III
Trata o diagnostica
II
III
IV
Fíjate en cómo la misma capacidad se mueve por la tabla según el contexto. Una herramienta que orienta la gestión clínica queda en I en una situación menor y en III en una emergencia con riesgo vital. Tu lista de funciones nunca te dirá por sí sola dónde te sitúas.
Clases de la FDA frente a categorías IMDRF: qué decide cada una
Dos sistemas distintos de clasificación SaMD usan números parecidos, y cada uno responde a una pregunta diferente. Confundirlos es el error más habitual de los equipos.
Ya has visto arriba las categorías IMDRF. Los requisitos de la FDA para SaMD van por otra vía, construida sobre tres clases que reflejan cuánta supervisión necesita un dispositivo:
- La clase I cubre los dispositivos de menor riesgo, y la mayoría no necesita ninguna presentación previa a la comercialización.
- La clase II queda en medio, y suele exigir una notificación 510(k) que demuestre que tu producto es equivalente a otro ya autorizado.
- La clase III conlleva el riesgo más alto y afronta la revisión más exigente de la agencia.
Algo realmente nuevo, sin equivalente existente, sigue su propia ruta, porque no hay nada con lo que compararlo. La clase de tu producto sale de para qué está destinado y de cuánto daño podría causar, no de cómo se construyó.
Así se comparan los dos sistemas de un vistazo:
Qué es
Una forma internacional de describir cuánto riesgo conlleva el software
La clasificación regulatoria estadounidense de un dispositivo médico
Qué decide
Sin fuerza legal por sí misma. Da a reguladores y desarrolladores un lenguaje común para hablar de riesgo
Qué debes presentar ante la FDA antes de vender en Estados Unidos
De dónde viene
El grupo de trabajo del IMDRF, que preside la FDA
La legislación estadounidense de dispositivos médicos
Ninguna de las dos escalas es algo que debas resolver por tu cuenta. Usa las categorías para entender tu riesgo y deja que un especialista regulatorio confirme la clasificación estadounidense. El Digital Health Policy Navigator de la FDA es un buen punto de partida para leer antes de esa conversación. Los requisitos también cambian según el mercado y con el tiempo, así que compruébalos en lugar de darlos por hechos.
Qué implica desarrollar software SaMD conforme a la normativa
Esto es lo que recae en un equipo de ingeniería que desarrolla software como dispositivo médico, y donde un socio de desarrollo se gana o pierde su sitio. Casi todo es buena práctica en cualquier proyecto serio, pero el trabajo regulado lo vuelve obligatorio y te obliga a demostrarlo. La FDA espera que todo el esfuerzo se apoye en un sistema de gestión de la calidad (QMS): procesos documentados, más la evidencia de que los seguiste cada vez. Su guía sobre evaluación clínica explica cómo demostrar que el producto hace lo que afirmas.
Cuatro prácticas soportan el peso en el desarrollo de software SaMD:
- Trazabilidad. Cualquiera debería poder tomar una línea de tu especificación y seguirla hasta la decisión de diseño que la resolvió, el código que la implementa y la prueba que demuestra que funciona, y luego recorrer ese camino a la inversa desde un resultado de prueba. La trazabilidad es casi gratis cuando la incorporas desde el primer sprint, y brutalmente cara de reconstruir después, que es el problema en torno al cual se escribió IEC 62304.
- Documentación escrita durante el trabajo. Los proyectos regulados necesitan una especificación clara desde el principio, porque todo lo que se monta al final describe lo que el equipo desearía haber construido. Escribir los requisitos primero también saca a la luz los desacuerdos cuando aún son baratos de resolver, la misma razón por la que existen nuestros servicios de especificación funcional para clientes no regulados.
- Un registro, no solo pruebas. Todo equipo serio prueba. Lo difícil es guardar constancia de qué pasó cada vez: qué versión se revisó, quién la ejecutó, qué requisito cubría y cuál fue el resultado. Ese registro es lo que pide un revisor, y nadie puede recrearlo meses después de memoria. Mantenerlo mientras construyes es la razón de ser de nuestros servicios de consultoría en aseguramiento de la calidad, y hay que planificarlo desde el inicio.
- Privacidad y seguridad, además de las normas de dispositivo. Cualquier producto que toque información de pacientes asume obligaciones que corren en paralelo a las normas de dispositivo, no las sustituyen. En Estados Unidos eso suele significar HIPAA. Los pasos son los de siempre: cifrar los datos en tránsito y en reposo, restringir el acceso por rol, registrar quién vio qué y exigir el mismo estándar a tus proveedores. Nuestra checklist de cumplimiento de HIPAA para software sanitario repasa cada uno de ellos. Planifica también la seguridad como una obligación continua, con una forma de detectar vulnerabilidades y publicar correcciones durante toda la vida del producto, en lugar de una única revisión antes del lanzamiento.
Una auditoría de desarrollo de software es donde descubres si esas cuatro prácticas se siguieron de verdad. Cuando Redwerk revisó el código detrás de Adoorabelle, un marketplace móvil, la evaluación sacó 80 problemas. Dos importan especialmente en el trabajo regulado: el proyecto no tenía pruebas de desarrollador y no guardaba registros de actividad. Fallar en ambas cosas sale caro en software comercial ordinario. En uno regulado, sin embargo, puede impedir que el producto llegue a los pacientes. No puedes mostrar para qué requisito se escribió una parte del código, y no puedes demostrar que funciona.
Ejemplos habituales de SaMD por categoría de riesgo
Las categorías abstractas cuestan de retener, así que aquí van ejemplos de SaMD ordenados de menor a mayor riesgo. Tómalos como ilustraciones del patrón, no como dictámenes sobre ningún producto concreto:
- Riesgo bajo: herramientas que informan una decisión en una situación que no es urgente. Una app de consulta de síntomas que ayuda a un paciente a describir una erupción antes de la cita informa sin decidir nada. Sal del marco por completo y un rastreador de actividad física general no está regulado en absoluto, ya que no hace ninguna afirmación clínica.
- Riesgo moderado: productos cuyo resultado configura de verdad la asistencia. Entra aquí el software que revisa la lista de medicación de un paciente y señala una interacción peligrosa, orientando el siguiente paso clínico. Lo mismo ocurre con una herramienta que hace triaje de los casos entrantes y adelanta los urgentes en la cola, donde su gravedad la empuja más arriba en la tabla.
- Riesgo alto: productos que diagnostican o tratan directamente, sobre todo en situaciones críticas. El software de imagen que identifica un posible ictus y avisa al equipo de guardia es un caso conocido. También lo es cualquier aplicación que calcula una dosis de radioterapia, donde un error tiene consecuencias irreversibles.
El patrón es el mismo en los tres niveles. El riesgo sube cuando la respuesta del producto sustituye el juicio humano en lugar de apoyarlo, y sube otra vez cuando el paciente tiene menos margen para sobrevivir a un error.
Dónde encaja un socio de desarrollo y dónde no
Si tu producto cuenta como software como dispositivo médico, en qué categoría cae y qué tienes que presentar son preguntas regulatorias. Esas preguntas debe responderlas un consultor cualificado. Como empresa de desarrollo, no podemos categorizar tu producto, y conviene desconfiar de cualquier proveedor que afirme lo contrario.
Sin embargo, si tu producto puede aportar la evidencia que quiere un regulador es una pregunta de ingeniería, y ahí sí podemos ayudarte. La respuesta sale de leer el código, las pruebas y la documentación que ya tienes. Una auditoría de software hace justo eso, y suele ser el primer paso más barato.
La mayoría de los equipos que se meten en problemas no empezaron con un plan regulatorio. Lanzaron rápido un producto sanitario, encontraron clientes y luego oyeron la pregunta de la clasificación de boca de un comprador. Si esto se parece a tu empresa, habla con nosotros sobre tu proyecto de software sanitario y averigua dónde están de verdad tu código y tu documentación.
Preguntas frecuentes
¿Cuál es la diferencia entre SaMD y el software dentro de un dispositivo médico?
El software como dispositivo médico funciona por sí solo. El software dentro de un dispositivo médico está integrado en el hardware y hace que ese hardware funcione, como el firmware de una bomba de infusión. Los dos están regulados, pero el segundo se evalúa como parte del equipo al que pertenece y no como producto independiente.
¿Una app de fitness o de bienestar es software como dispositivo médico?
Normalmente no. Registrar entrenamientos, pasos o sueño no afirma nada sobre diagnosticar ni tratar, así que las apps de bienestar general quedan fuera de las normas. El factor decisivo es el uso previsto, es decir, para qué dices que sirve tu producto. Añade una función que señale un posible problema médico y la respuesta puede cambiar.
¿Hace falta la autorización de la FDA para vender software sanitario?
No siempre. Las herramientas administrativas, como la facturación y la gestión de citas, no la necesitan, y las apps de bienestar general tampoco suelen necesitarla. El software que diagnostica, trata u orienta una decisión clínica normalmente sí. Como la respuesta depende de lo que afirmes que hace tu producto, resuelve esa cuestión con un consultor regulatorio mucho antes del lanzamiento.
¿Qué pasa si descubres que tu producto es SaMD después del lanzamiento?
Es habitual, y suele salir a la luz cuando lo pregunta un inversor o un comprador hospitalario. Empieza por un consultor regulatorio, que puede decirte dónde estás realmente. En paralelo, una auditoría de tu código, tus pruebas y tus registros muestra cuánta de la evidencia exigida ya existe y cuánta hay que reconstruir.
Descubra cómo auditamos el software Project Science de Complete Network y logramos un aumento del 80 % en la mantenibilidad del código
