Documentación del software de la FDA para dispositivos médicos

0

Autónomo redactor de normativas Shreya Chenni ofrece una guía sobre la documentación de software de la FDA para dispositivos médicos, que incluye un desglose de los requisitos según la clasificación. 

El sector de los dispositivos médicos está experimentando un rápido avance tecnológico y un alto índice de innovación. Hoy en día, muchos dispositivos están habilitados para la IA, lo que permite la detección temprana de enfermedades, la identificación de diferentes patrones de una actividad biológica y la mejora de la precisión del diagnóstico. Algunos ejemplos de aplicaciones o dispositivos con IA son la aplicación Arterys, Philips WSI y QuantX de Quantitative Insights. El software tiene que ser verificado y validado, para garantizar su seguridad y eficacia. 

Para cualquier dispositivo que contenga software que pase por la vía del 510(k), hay que presentar documentos específicos relacionados con el software. En este artículo hablamos de los documentos necesarios para Presentaciones de 510(k) y entender cómo redactarlas en función de su clasificación de software.  

¿Cómo clasificar su software de dispositivos médicos? 

Identifique el nivel de preocupación aplicable (LoC). Hay tres niveles: 

  • Mayor: un fallo o defecto latente podría provocar directamente la muerte o lesiones graves al paciente o al operador 

 un fallo o defecto latente podría provocar indirectamente la muerte o una lesión grave del paciente o del operador por una información incorrecta o tardía o por la acción de un proveedor de asistencia.

  • Moderado: un fallo o defecto de diseño latente podría provocar directamente lesiones leves al paciente o al operador

 O 

un fallo o defecto latente podría provocar indirectamente una lesión leve al paciente o al operador a través de una información incorrecta o tardía o a través de la acción de un proveedor de atención. 

  • Menor: si es poco probable que los fallos o defectos de diseño latentes causen alguna lesión al paciente o al operador. 

Utilice la Tabla 1 y la Tabla 2 del Guía de la FDA para el contenido de las presentaciones previas a la comercialización de los programas informáticos contenidos en los productos sanitarios para responder a las preguntas y determinar su nivel de preocupación por el software. 

Documentos de software de la FDA para dispositivos médicos

¿Qué documentos hay que presentar?

Los programas informáticos de nivel de preocupación moderado y mayor tienen que presentar 11 documentos diferentes. Por su parte, los programas informáticos con un nivel de preocupación menor requieren siete documentos diferentes. El alcance y el grado de detalle de estos documentos varía en función de su RdC.

La siguiente tabla identifica los documentos necesarios para cada uno de los niveles de preocupación: 

Menor Moderado Mayor
Nivel de preocupación Nivel de preocupación Nivel de preocupación
Descripción del software Descripción del software Descripción del software
Análisis de riesgos de los dispositivos Análisis de riesgos de los dispositivos Análisis de riesgos de los dispositivos
Especificación de requisitos de software (SRS) Especificación de requisitos de software (SRS) Especificación de requisitos de software (SRS)
Análisis de trazabilidad Análisis de trazabilidad Análisis de trazabilidad
Documentación de verificación y validación  Documentación de verificación y validación  Documentación de verificación y validación 
Historial del nivel de revisión  Historial del nivel de revisión  Historial del nivel de revisión 
———— Cuadro de diseño arquitectónico Cuadro de diseño arquitectónico
———— Documento de especificación del diseño del software Documento de especificación del diseño del software
———— Descripción del entorno de desarrollo de software  Descripción del entorno de desarrollo de software 
———— Anomalías no resueltas (errores o defectos) Anomalías no resueltas (errores o defectos)

 

Descripción de los documentos 

1. Nivel de preocupación 

Anote las respuestas a las preguntas de la Tabla 1 y la Tabla 2 del Guía de la FDA para el contenido de las presentaciones previas a la comercialización de los programas informáticos contenidos en los productos sanitarios  en este documento. Incluya una justificación para el nivel de preocupación determinado. 

2. Descripción del software

Este documento presenta el software del dispositivo y, por lo tanto, debe proporcionar una visión general de las características, las funcionalidades y el uso previsto. Incluye el lenguaje de programación, la plataforma de hardware, el sistema operativo y el uso de software estándar, si procede. Deben incluirse figuras y diagramas, según proceda. 

En el caso de que el dispositivo utilice software estándar, consulte el documento de orientación de la FDA "Guía para el uso de software estándar en productos sanitarios." 

3. Análisis de riesgos de los dispositivos 

 Es imprescindible realizar un análisis de riesgos del dispositivo. Deben recogerse todos los peligros previsibles asociados al uso previsto del dispositivo (software y hardware). El análisis de riesgos debe realizarse de acuerdo con la norma ISO 14971. El análisis de riesgos debe identificar el peligro, el riesgo, la gravedad del peligro, la causa del peligro, la medida de control del riesgo y la verificación de la medida de control. 

4. Especificación de los requisitos del software

La Especificación de Requisitos del Software (SRS) documenta todos los requisitos del software. Básicamente, los requisitos describen lo que debe hacer el software. Los requisitos pueden clasificarse en diferentes categorías, como funcionalidad, rendimiento, interfaz de usuario y normativa. 

En el caso de las RdC menores, el SRS puede ser un resumen de los requisitos funcionales; sin embargo, en el caso de las moderadas y mayores, los requisitos deben ser detallados y, por lo general, enumerados. Asegúrese de que cada requisito enumerado tenga un ID de requisito asignado, como SRS-01, SRS-02, etc. 

Estos son algunos ejemplos del SRS: 

Requisitos de hardware: Incluya los requisitos sobre -  

  • microprocesadores 
  • dispositivos de memoria
  • sensores 
  • fuentes de energía 
  • características de seguridad
  • comunicaciones

Requisitos de programación: Incluya los requisitos de tamaño del programa, las restricciones, etc. 

Requisitos de la interfaz: Incluye los requisitos que describen la comunicación entre el software y los dispositivos de hardware, como impresoras o monitores. Otros requisitos, como el sistema operativo con el que es compatible el software, etc. 

Rendimiento del software y requisitos funcionales El rendimiento del software y los requisitos funcionales incluyen algoritmos o características de control para la terapia, el diagnóstico, la supervisión, las alarmas, el análisis y la interpretación con referencias de texto completo o datos clínicos de apoyo, si es necesario. 

Los requisitos funcionales y de rendimiento del software también pueden incluir:

  • Limitaciones del dispositivo debidas al software 
  • Pruebas y comprobaciones internas del software
  • Gestión de errores e interrupciones 
  • Características de detección, tolerancia y recuperación de fallos 12 Contiene recomendaciones no vinculantes 
  • Requisitos de seguridad
  • Requisitos de tiempo y memoria 
  • Identificación de programas informáticos disponibles en el mercado, si procede. 

5. Cuadro de diseño de la arquitectura

 Este documento presenta claramente la relación, el flujo de datos y la interacción entre los principales componentes o bloques funcionales del software. Suele representarse en forma de diagrama de flujo, diagramas de bloques y otras formas, según convenga. En el caso de los programas informáticos de nivel moderado y principal, el diagrama de diseño puede incluir diagramas de estado. 

6. Especificaciones de diseño de software (SDS)

La aplicación de los requisitos se detalla en este documento. Cada SDS deberá estar numerada, como SDS-01, de forma similar al SRS. Cada requisito incluido en el SRS debe tener una especificación de diseño correspondiente. Sin embargo, también es posible que una única especificación de diseño se corresponda con un grupo de requisitos. 

7. Análisis de trazabilidad

Este documento vincula los requisitos, la especificación del diseño, los peligros y las pruebas de V&V. La matriz de trazabilidad puede redactarse como se indica a continuación, y pueden añadirse detalles según convenga: 

Necesidad del usuario (opcional) SRS SDS Riesgos Casos de prueba V&V
UND-001 SRS-001

SRS-002

SDS-001 Haz-001 TC-001
UND-002 SRS-002 SDS-001

SDS-002

Haz-002 TC-002

TC-004

 

8. Descripción del entorno de desarrollo de software (SDED)

Los programas informáticos de nivel moderado y principal deben presentar una DEA que describa el plan del ciclo de vida del desarrollo del programa informático, el mantenimiento y las actividades del programa informático. El nivel de detalle difiere para el nivel moderado y el mayor. Consulte la EN 62304 Tabla 1: Tabla A.1 - Resumen de los requisitos por clase de seguridad del software. Puede utilizarse para identificar los elementos que deben incluirse y las actividades que deben documentarse por su clase. Las tres clases A, B y C coinciden con el nivel de preocupación de la FDA.  

9. Documentación de verificación y validación

RdC menor: Documentar las pruebas a nivel de dispositivo y las pruebas de integración (si procede). Asegúrese de que los casos de prueba tienen un criterio de aceptación y un resumen de los resultados de las pruebas. 

RdC moderado: Documentar la lista resumida de las actividades de validación y verificación y sus resultados. Incluir los criterios de aceptación. Asegúrese de que el análisis de trazabilidad hace referencia a los ID de los casos de prueba. 

RdC mayor: Además de la información anterior (RdC moderada), se debe documentar la descripción de las pruebas fallidas y los cambios realizados en respuesta a las mismas. 

10. Historial del nivel de revisión

Documente los principales cambios en el software asegurándose de que la última línea de tiempo/entrada es la última versión del software. Identifique el número de versión, la fecha y describa los cambios con respecto a la versión anterior. 

11. Anomalías no resueltas 

Documente los errores no resueltos que existen en el software que se está publicando. Capture lo siguiente para cada error: 

  • El problema
  • Impacto en el rendimiento del dispositivo 
  • Plazos previstos para corregir estos fallos (si procede) 

Los once documentos anteriores cubren toda la documentación necesaria para el software del dispositivo. Además, la FDA requiere documentación de ciberseguridad como el plan de ciberseguridad, la gestión de riesgos y las pruebas de V&V y sus resultados. Para obtener más información sobre estas directrices de la FDA sobre los requisitos de ciberseguridad, consulte: Contenido de las presentaciones previas a la comercialización para la gestión de la ciberseguridad en los productos sanitarios

Referencias: 

¿Necesita ayuda con la documentación del software de la FDA para dispositivos médicos? Póngase en contacto con los redactores de normativas autónomos y Expertos en presentaciones a la FDA en Kolabtree.


Kolabtree ayuda a las empresas de todo el mundo a contratar expertos bajo demanda. Nuestros freelancers han ayudado a las empresas a publicar artículos de investigación, desarrollar productos, analizar datos y mucho más. Sólo se necesita un minuto para decirnos lo que necesita hacer y obtener presupuestos de expertos de forma gratuita.


Comparte.

Sobre el autor

Shreya Chenni es una profesional de la reglamentación y tiene una gran experiencia en la presentación de solicitudes de reglamentación como 510 (k), Pre-Sub y el expediente técnico de la UE. También ha trabajado en la creación de prototipos de dispositivos médicos. Actualmente, está cursando un máster en Ingeniería Biomédica Reguladora en la Universidad George Washington, D.C.

Dejar una respuesta

Expertos autónomos de confianza, listos para ayudarle con su proyecto


La mayor plataforma mundial de científicos autónomos  

No gracias, no estoy buscando contratar en este momento