El software como dispositivo médico se encuentra en una posición regulatoria inusual: el producto cambia más rápido de lo que fueron diseñados para manejar los procesos de documentación creados originalmente para los dispositivos de hardware. Un archivo técnico de SaMD debe capturar no sólo lo que hace el software, sino también cómo se desarrolló, verificó y mantuvo a lo largo de un ciclo de lanzamiento que podría medirse en semanas en lugar de años. Esa diferencia es donde muchos equipos subestiman lo que realmente se requiere.
Lo que un archivo técnico SaMD debe demostrar
Más allá de la descripción general del dispositivo y el uso previsto, un archivo SaMD generalmente necesita mostrar:
Una clasificación de seguridad de software definida basada en la importancia de la información proporcionada por el software y el estado de la situación o condición de atención médica que aborda
Especificaciones de requisitos de software, diseño de arquitectura y documentación de diseño detallada que rastrear claramente las actividades de verificación y validación
Documentación de gestión de riesgos específica del software, que cubre tanto el riesgo clínico de la función del software como el riesgo de ciberseguridad del software en sí
Registros de verificación y validación para cada versión, no solo el envío inicial, ya que se espera que SaMD se mantenga como un producto vivo
Registros de control de cambios que muestran cómo se evaluó cada actualización de software por su impacto en la seguridad y eficacia, y si era necesaria una nueva presentación regulatoria
Donde los equipos tienen problemas
La brecha más común no es la falta de documentación. Es documentación que existe pero que no está lo suficientemente bien organizada para demostrar la trazabilidad que los reguladores esperan entre un requisito, su implementación de diseño, su prueba de verificación y cualquier defecto o cambio relacionado con él. Cuando esa trazabilidad tiene que reconstruirse manualmente en el momento del envío, posiblemente en docenas de versiones de software, se convierte en la mayor fuente de retraso.
Una segunda brecha común es la desviación del control de versiones entre la documentación de desarrollo y lo que realmente se hace referencia en el archivo técnico, particularmente cuando los equipos de software iteran más rápido de lo que se actualiza la documentación regulatoria.
Cómo ayuda un sistema de gestión de documentos validado
A sistema de gestión de documentos creado para industrias reguladas aborda ambos problemas directamente. Los flujos de trabajo de control y aprobación de versiones mantienen cada documento vinculado a una revisión específica y rastreable, de modo que el archivo técnico refleja el estado actual del software en lugar de una instantánea de meses antes. Las referencias cruzadas entre documentos relacionados, desde los requisitos desde el diseño hasta la verificación, mantienen la cadena de trazabilidad intacta automáticamente a medida que el software evoluciona, en lugar de requerir que se reconstruya a mano para cada envío o auditoría.
Tratar el archivo técnico como un documento vivo, no como un entregable de una sola vez
Los equipos que administran la documentación de SaMD de manera más fluida tienden a tratar el archivo técnico de la misma manera que tratan el software en sí: mantenido continuamente, controlado por versiones y listo para auditoría en cualquier momento. no reunidos retroactivamente cuando corresponde una presentación o inspección. Ese cambio de enfoque es lo que realmente cierra la brecha entre el rápido desarrollo de software y el rigor de la documentación que exigen los reguladores.
Si la trazabilidad de los documentos entre versiones es lo que dificulta su proceso de documentación de SaMD, página del sistema de gestión de documentos cubre cómo funcionan el control de versiones y las referencias cruzadas en un entorno compatible con 21 CFR Parte 11.
