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 dispositivo médico industry is seeing rapid technological advancement and a high rate of innovation. Nowadays, many devices are AI-enabled, which allows early detection of disease, identification of different patterns of a biological activity, and improved diagnostic accuracy. Some examples of AI-enabled applications or devices include Arterys Application, Philips WSI and QuantX by Quantitative Insights. The software has to be verified and validated, to ensure its safety and effectiveness.
Para cualquier dispositivo que contenga software que pase por el Ruta 510(k)En el caso de las solicitudes de visado, 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
O
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 |
| ———— | Software Development Environment Description | 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 conformidad con la norma ISO 14971. El análisis de peligros 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.
Software Performance and Functional Requirements Software performance and functional requirements include algorithms or control characteristics for therapy, diagnosis, monitoring, alarms, analysis, and interpretation with full text references or supporting clinical data, if necessary.
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)
The above eleven documents cover the entire documentation necessary for the device software. Additionally, FDA requires Ciberseguridad Documentation such as cybersecurity plan, risk management and V&V tests and their results. For more information on this FDA guidelines on Cybersecurity requirements refer to: 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 helps businesses worldwide hire freelance scientists and industry experts on demand. Our freelancers have helped companies publish research papers, develop products, analyze data, and more. It only takes a minute to tell us what you need done and get quotes from experts for free.
Unlock Corporate Benefits
• Secure Payment Assistance
• Onboarding Support
• Dedicated Account Manager
Sign up with your professional email to avail special advances offered against purchase orders, seamless multi-channel payments, and extended support for agreements.
