Causas y recomendaciones
Un grupo de expertos de las comisiones IEC/SC62A + ISO/215/JWG7 fue designado para determinar las causas del fracaso de los tres proyectos de la 2ª edición de IEC 62304 y definir recomendaciones para la nueva versión de la norma, con el objetivo de ayudar a las comisiones nacionales a preparar una versión más asertiva de la norma.
El proyecto de la 2da edición pasó por 3 CDV* sin acuerdo entre ISO e IEC, la principal disputa fue definir qué requisitos del sistema de calidad requieren Gestión de Riesgos.
Con el tiempo, otros puntos tampoco encuentran consenso:
▫Clasificación de seguridad (basada en la lesión)
▫legacy SW
▫Falta de disposiciones para nuevas tecnologías (por ejemplo, IA)
El grupo recomendó que el proyecto 62304 Edición 2.0 debería tener una especificación de diseño basada en requisitos específicos, además de:
El proyecto de la segunda edición pasó por 3 CDV (borrador del Comité para votación - Documento preparado por el grupo de estudio para ser evaluado por la comisión) sin acuerdo entre ISO e IEC, la principal disputa fue definir qué requisitos del sistema de calidad requieren Gestión de Riesgos.
Con el tiempo, otros puntos tampoco encuentran consenso:
▫Clasificación de seguridad (basada en la lesión)
▫legacy SW
▫Falta de disposiciones para nuevas tecnologías (por ejemplo, IA)
El grupo recomendó que el proyecto 62304 Edición 2.0 debería tener una especificación de diseño basada en requisitos específicos, además de:
▫IEC 62304 es un estándar de seguridad de software ampliamente utilizado y reconocido en la industria de dispositivos médicos. El estándar es utilizado por desarrolladores, fabricantes y organismos reguladores.
▫IEC 62304 es una referencia normativa en varios estándares de dispositivos médicos (por ejemplo, IEC 60601-1, ISO 14708-1, IEC 82304-1). Los cambios a la norma no deben entrar en conflicto con las necesidades de estas normas de producto.
▫IEC 62304 Edición 1.0 es un estándar MDD/AIMDD (UE) armonizado y la Edición 1.1 está reconocida por la FDA de EE. UU. Los cambios al estándar deben continuar adaptándose a las necesidades de los reguladores para un desarrollo de software seguro y eficaz.
2) Ampliar el alcance para incluir software sanitario fue problemático para llegar a un consenso sobre el estándar. El alcance del estándar debe dejarse en manos de IEC/SC62A, ISO/TC215 (e ISO/TC210) y los comités nacionales para decidir sobre la necesidad de estandarización de los procesos del ciclo de vida del software de atención médica.
Ampliar el alcance del software sanitario fue un punto central para alcanzar el consenso en la segunda edición de 62304 debido a los diferentes intereses de las partes involucradas. Un conjunto de partes interesadas querían el estándar para dispositivos médicos y su uso regulatorio, lo que dificultaba ser imparcial en la regulación del software de atención médica. También sigue existiendo el argumento de que el software de dispositivos médicos está regulado de manera diferente según las jurisdicciones: lo que es software de dispositivos médicos en una jurisdicción no lo es en otra.
La pregunta es si este es un problema que la norma debe resolver. ¿O corresponde al fabricante elegir qué estándares utilizar?
Si este es un problema que debe abordar la norma, el grupo recomienda no diluir los requisitos de IEC 62304 para incluir software de atención médica, a riesgo de que ed2 no sea reconocido por la FDA o no esté armonizado en la UE.
Otro punto a tener en cuenta es que restringir el alcance de IEC 62304 al software de dispositivos médicos puede causar problemas al llamar al estándar IEC 82304-1 (que cubre SaMD y productos de software de atención médica no médica). Esto también dejará una brecha en la arquitectura de los estándares ISO/TC215 para los procesos de desarrollo/mantenimiento de software sanitario.
IEC 82304-1: PRODUCTOS DE SOFTWARE DE SALUD está destinado a que el FABRICANTE gestione, mantenga o mejore la salud de personas individuales o la prestación de atención. SOFTWARE DE SALUD se refiere al software que contribuye a la salud de personas individuales según lo observado y/o demostrado utilizando parámetros de salud medibles o experiencia clínica.
*software como dispositivo médico (etc.) - SaMD es un software que realiza una o más funciones médicas. Si bien el software puede estar integrado en una pieza de hardware (como suele ser el caso), es el software en sí el que realiza la función médica.
La experiencia del equipo del proyecto 62304 de la segunda edición muestra que el proyecto duró mucho tiempo (6 años). Durante este tiempo, algunos fundamentos iniciales cambiaron 180 grados debido al entorno regulatorio y se produjo un "desplazamiento del alcance" para agregar nuevos requisitos al estado del arte. Esto contribuyó a la dificultad de alcanzar un consenso entre las partes interesadas de ISO e IEC.
Existe una tendencia en la industria hacia la subcontratación del desarrollo de software, incluso a desarrolladores no especializados en el sector de dispositivos médicos. La subcontratación de software podría respaldarse mejor si se aumentara la claridad de los estándares en las siguientes áreas:
- a) La interfaz de proceso entre los procesos a nivel de fabricante de productos y los procesos de desarrollo de software.
- b) Cumplimiento de los niveles de rigor de los procesos a través del desarrollo de software subcontratado basado en la evaluación de riesgos por parte del fabricante del producto.
- c) Un equilibrio entre los resultados del proceso prescritos que necesita el fabricante y la necesidad del proveedor de software de proteger su propiedad intelectual.
- d) Los criterios utilizados por el fabricante para evaluar un candidato a subcontratación de desarrollo de software y su cumplimiento de la norma
Por ejemplo, cómo y con qué algoritmo de IA se debe entrenar. El estándar no debería incluir requisitos detallados sobre cómo entrenar una red. Aún así, debería exigir que esta capacitación se documente como parte de cualquier otra documentación de diseño que permita la repetibilidad de la construcción del software.
El grupo cree que la norma debe ser imparcial en cuanto a la elección del modelo de desarrollo.
Sería útil para los usuarios y evaluadores proporcionar anexos informativos sobre el uso de los requisitos 62304 con diferentes modelos de desarrollo. También se podría considerar el desarrollo de una “Guía para la aplicación de IEC 62304”, ya que ISO/TR24971 se desarrolló para la norma de gestión de riesgos ISO 14971.
El estándar actual tiene muchos ejemplos de SiMD, pero se debe considerar un conjunto más diverso de ejemplos, incluida la computación en la nube.
El acrónimo SIMD (Single Instrucción, Múltiples Datos) describe un método para operar computadoras con múltiples unidades operativas en computación paralela. En este modo, la misma instrucción se aplica simultáneamente a múltiples datos para producir más resultados.
Una alternativa podría ser definir interfaces de flujo de información/proceso tales como:
- ▫Requisitos del sistema/producto y flujo de información arquitectónica entre los procesos del sistema y del software.
- ▫Asignación de gestión de riesgos (flujo de información de gestión de riesgos entre el sistema y los procesos de software (situaciones peligrosas y riesgos asociados)
Esto permitirá a los evaluadores (evaluación de terceros o fabricante/proveedor) evaluar el cumplimiento del estándar más fácilmente. Una alternativa sería ampliar un anexo que explique cómo se puede lograr el cumplimiento.
- Esto será útil para la evaluación del esquema IECEE CB cuando se incluya en la prueba/evaluación IEC 60601-1.
- Los organismos de certificación verifican el cumplimiento de la norma por parte de los fabricantes. Esto permitirá una verificación más sencilla de que la empresa cumple con los requisitos de la norma.
Recibimos comentarios de que este caso debería considerarse y que el software heredado no debería considerarse.
El grupo recomienda que el estándar proporcione un medio de cumplimiento sin requerir un rediseño completo del software.
Se trata de gestionar software genérico que, debido a cambios regulatorios, de repente se convierte en software sanitario o en un crecimiento funcional que cambia el uso previsto de un producto para convertirse en software sanitario.
El uso de elementos de software no desarrollados por el fabricante es una práctica común para muchos desarrolladores.
El grupo recomienda que la norma defina requisitos sobre el uso seguro de lo que comúnmente se conoce como SOPA u OTS.
* Disponible en el mercado (OTS) - Componentes de software predesarrollados, generalmente desarrollados por otra organización y diseñados para soluciones específicas.
- Software de procedencia desconocida (SOUP)- Software de procedencia desconocida generalmente entendido como elementos de software "disponibles en el mercado" que se utilizan en un dispositivo médico.
Hay al menos dos aspectos aquí.
▫ Cómo se determinan los niveles de rigor del proceso, pero también si es necesario.
▫Una eliminación completa del enfoque de rigor de proceso probablemente dará como resultado un estándar con el rigor de proceso más alto (Clase C) para satisfacer los requisitos reglamentarios.
▫ Sin embargo, para permitir una ampliación del alcance, a nosotros, como grupo, nos parece lógico esperar un rigor de proceso diferente para una aplicación inofensiva en comparación con un sistema de software de control de soporte vital.
Existen varios métodos posibles para determinar la clasificación del software que pueden investigarse más a fondo.
▫La clasificación actual se basa en las lesiones y el grupo sugiere que, en su lugar, basemos la clasificación en los daños. Este cambio se alinearía mejor con la norma ISO 14971 e incluiría mejor aspectos de seguridad de lo que es posible hoy en día.
▫También se sugiere adoptar las modificaciones de 62304 CDV3 en el diagrama de flujo para eliminar la “ruta de escape” al nivel A.
▫El grupo recomienda adoptar el cambio propuesto 62304 CDV3 para los niveles de rigor del proceso (en comparación con la clasificación de seguridad del software).
▫Hubo la opinión de que la determinación del nivel de rigor del software debería hacerse llamando a estándares (es decir, fuera de 62304) porque dicha decisión debería tomarse mediante actividades de gestión de riesgos a nivel de producto/sistema. Este método necesitaría una coordinación adicional con el comité de normas y normas de desarrollo convocado.
▫62304 CDV3 también incluyó un anexo informativo de la categorización de riesgos de SaMD y cómo se pueden alinear los niveles de rigor del proceso 62304. El grupo recomienda adoptar esta información en una nueva segunda edición.
Como grupo, recomendamos adoptar la adición de desmantelamiento que se incluyó en 62304 CDV3.
Otras mejoras pueden incluir seleccionar y mantener el uso apropiado de los elementos de SOUP o administrar actualizaciones y relanzamientos del sistema de software.