Software como dispositivo médico: definición, documentación, validación y riesgos (INVIMA)
- David Dimate
- 23 feb
- 6 Min. de lectura
En la interpretación de INVIMA, software como dispositivo médico se determina por su finalidad prevista: si impacta diagnóstico, monitoreo o decisiones clínicas, aplica el marco regulatorio; si es administrativo, no. Puede evaluarse como SaMD autónomo o como accesorio, y su riesgo depende de la función y el contexto (e incluso puede heredarse si influye en un equipo). Por eso el expediente debe sostener seguridad y desempeño con evidencia trazable, mantener coherencia entre lo declarado y lo publicado, y gobernar cambios con criterio (correcciones, nuevas funciones/indicaciones o cambio de uso previsto). Esta guía resume documentación, validación/verificación y errores comunes en expedientes.
Software como dispositivo médico: inclusión expresa en la definición y ámbito de aplicación
Conforme al Decreto 4725 de 2005, el régimen aplica a dispositivos médicos para uso humano y, dentro de su definición legal, se incluye de manera expresa el software. En consecuencia, cuando el producto encaja en la definición normativa y se comercializa con finalidad médica, se somete al régimen de registro sanitario/permiso de comercialización y a la vigilancia sanitaria prevista en el decreto. El DP INVIMA 20252002945 reitera esta regla y fundamenta el análisis de software en el Decreto 4725, remitiendo directamente a su artículo de definiciones.
Requisitos para solicitar software como dispositivo médico ante INVIMA (estructura legal de la solicitud)
En el marco del Decreto 4725, la obtención del registro sanitario se materializa mediante radicación de solicitud y anexos, donde el interesado debe aportar la documentación técnica y legal exigida para el tipo de producto y su clase, en los términos del decreto. En esta lógica, la solicitud no se reduce a “describir un software”: exige soportar
(i) La clasificación del dispositivo
(ii) La evaluación técnica con la documentación correspondiente
(iii) La coherencia entre lo que se declara y lo que se presenta como información oficial del producto.
El INVIMA, al responder sobre software, insiste en que el estudio se define por el uso, aplicación y finalidad prevista, y se evalúa con base en las reglas del Decreto 4725 y los requisitos técnico-legales aplicables al caso concreto.
Aunque se trate de un producto intangible, se deben aportar todos los requisitos de un producto físico, incluyendo CCAA
Clasificación del software como dispositivo médico: reglas y criterios del Decreto 4725
El Decreto 4725 establece un sistema de clasificación por riesgo y define reglas para asignar clase. Por tanto, el punto crítico no es el tipo de tecnología (software), sino el uso previsto y el nivel de riesgo asociado a su función en salud. En términos regulatorios, la clase determina el nivel de exigencia del expediente y el alcance de la evaluación técnica. El INVIMA enfatiza que no existe un “criterio único” para todos los software: la determinación depende de la indicación de uso, los parámetros del producto y su encaje en las reglas de clasificación previstas en el decreto.
Documentación técnica exigible: coherencia regulatoria del expediente
Desde una perspectiva jurídica, el expediente debe sostener una cadena de coherencia entre:
(i) Lo que el titular declara en solicitud
(ii) La documentación técnica aportada para evaluación
(iii) La información oficial del producto que se entrega al usuario y se usa en comercialización.
Para software como dispositivo médico, esto se traduce en soportar documentalmente: finalidad prevista, alcance funcional, limitaciones, condiciones de uso, desempeño esperado y gestión de riesgos del producto. El estándar legal no es “tener documentos”, sino que estos sean idóneos, consistentes y verificables frente al uso previsto y la clase.
Información al usuario, etiquetado e inserto: aplicación al software como dispositivo médico
El Decreto 4725 regula el etiquetado/rotulado y la información que debe acompañar al dispositivo (incluido inserto, cuando aplica). Para software, la obligación se materializa en la información equivalente que el usuario recibe (interfaz, manual, instrucciones, advertencias, identificación del responsable, condiciones y restricciones). El INVIMA remite expresamente a los artículos de etiquetado del Decreto 4725 al discutir cómo debe evidenciarse la información del producto (por ejemplo, información visible o demostrable asociada a la aplicación), lo cual refuerza que la trazabilidad de la información oficial es un componente regulatorio, no un detalle editorial.
Cambios y actualizaciones del software: cuándo se vuelven un asunto regulatorio
El Decreto 4725 y 582 contemplan el régimen de modificaciones y delimitan escenarios donde ciertos cambios no son procedentes como simples modificaciones si comprometen seguridad/efectividad o constituyen cambios significativos según los criterios del decreto. En software como dispositivo médico, el principio es jurídico: si la actualización altera el uso previsto, el desempeño clínico, las condiciones de seguridad o los elementos esenciales soportados en el expediente, deja de ser un cambio neutro y debe tratarse bajo la vía regulatoria correspondiente (según aplique: anexo, modificación o una nueva evaluación del producto).
Vigilancia sanitaria, tecnovigilancia y responsabilidad: deberes del titular y cadena de cumplimiento
El Decreto 4725 estructura deberes de vigilancia sanitaria y asigna responsabilidades a titulares, fabricantes e importadores respecto de la veracidad de la información y el cumplimiento del régimen sanitario. En software como dispositivo médico, esta responsabilidad se concreta en: consistencia de lo declarado, control de versiones que impacten seguridad/desempeño, soporte documental que permita verificación, y capacidad de respuesta ante hallazgos de vigilancia o requerimientos de autoridad sanitaria. El régimen no trata el software como “servicio” fuera del control sanitario, sino como producto sujeto a deberes y responsabilidades dentro del marco del decreto cuando encaja en la definición normativa.
Errores jurídicamente relevantes en expedientes de software como dispositivo médico
Definir finalidad prevista de forma indeterminada o incompatible con la clase y el riesgo.
Clasificar sin sustento en las reglas del Decreto 4725 y sin coherencia con el uso previsto.
Aportar documentación técnica que no soporte la evaluación (incompleta o inconexa con lo declarado).
Inconsistencias entre información oficial al usuario (interfaz/IFU/manual) y lo radicado en expediente.
Gestionar actualizaciones como cambios menores cuando impactan seguridad/efectividad o uso previsto.
Marco normativo relacionado
Decreto 4725 de 2005.
Preguntas frecuentes
¿Qué criterio usa INVIMA para determinar cuándo un software es dispositivo médico bajo el Decreto 4725?
El criterio es jurídico y se centra en la finalidad prevista: conforme al Decreto 4725, el software queda comprendido dentro de la definición de dispositivo médico cuando se destina a finalidades médicas (por ejemplo diagnóstico, prevención, supervisión, tratamiento o alivio de una enfermedad), y por tanto entra al régimen de registro sanitario/permiso y vigilancia sanitaria. En consecuencia, la calificación no depende del “tipo de software” sino de lo que el producto pretende hacer en salud y de cómo se declara su uso previsto.
¿Qué documentación técnica y legal debe anexarse para solicitar el registro sanitario de un software como dispositivo médico?
La estructura de la solicitud bajo el Decreto 4725 es de radicación con anexos, en la cual el interesado aporta la documentación técnica y legal exigida. Para software, esto implica soportar (i) la clasificación por riesgo conforme a las reglas del decreto, (ii) la documentación técnica suficiente para evaluación (finalidad prevista, alcance funcional, limitaciones, desempeño y gestión de riesgos), y (iii) coherencia entre lo declarado y la información oficial del producto. Aunque el producto sea intangible, el estándar es el mismo: debe aportarse la totalidad de soportes exigibles para demostrar cumplimiento, incluyendo lo que aplique a la operación (p. ej., CCAA, etiquetado).
¿Cómo se define la clasificación por riesgo del software como dispositivo médico según el Decreto 4725?
El Decreto 4725 establece un sistema de clasificación por riesgo y reglas para asignar clase. En software, el punto determinante no es la tecnología sino el uso previsto y el nivel de riesgo asociado a su función en salud. En la práctica regulatoria, la clasificación define el nivel de exigencia del expediente y el alcance de evaluación técnica: por eso debe justificarse con base en la indicación de uso, el contexto y el impacto del software en el proceso clínico.
¿Cómo aplica el etiquetado/rotulado y el inserto del Decreto 4725 a un producto como un software?
El Decreto 4725 regula el etiquetado/rotulado e inserto como obligaciones de información oficial que acompaña al dispositivo. Para software, la obligación se materializa en su equivalente funcional: información identificable y controlada que el usuario recibe (interfaz, manual, instrucciones, advertencias, identificación del responsable, condiciones y restricciones), y que debe ser coherente con lo radicado en el expediente. En otras palabras, el software no “elimina” la obligación: la traslada a los medios mediante los cuales el usuario accede a la información oficial del producto.
¿Cuándo una actualización de software se convierte en un trámite regulatorio (anexo/modificación/nueva evaluación)?
El criterio es jurídico: cuando la actualización altera elementos esenciales soportados en el expediente —como uso previsto, desempeño clínico, condiciones de seguridad o componentes que pueden afectar seguridad/efectividad— deja de ser un cambio neutro. Bajo el régimen del Decreto 4725 y el marco de modificaciones, la ruta depende de la naturaleza del cambio: cambios menores pueden gestionarse como ajustes documentales, mientras que nuevas funciones/alcance o cambios significativos exigen la vía regulatoria correspondiente (modificación o una nueva evaluación del producto, según aplique).
¿Qué deberes de vigilancia sanitaria y tecnovigilancia se vuelven críticos en software como dispositivo médico?
El Decreto 4725 estructura obligaciones de vigilancia sanitaria y asigna responsabilidades a los actores respecto de veracidad de información y cumplimiento del régimen. En software, estos deberes se vuelven críticos en la gestión de versiones (control de cambios que afecten seguridad/desempeño), trazabilidad documental para verificación, coherencia de información oficial al usuario y capacidad de respuesta ante requerimientos o hallazgos. La tecnovigilancia se conecta con el seguimiento de incidentes/fallas y con la adopción de medidas cuando se identifican riesgos asociados al desempeño del producto.
Comentarios