{"id":2217,"date":"2023-05-20T20:32:45","date_gmt":"2023-05-20T18:32:45","guid":{"rendered":"https:\/\/alenta.net\/?p=2217"},"modified":"2023-05-20T20:32:41","modified_gmt":"2023-05-20T18:32:41","slug":"requisitos-del-sw-y-la-iec62304","status":"publish","type":"post","link":"https:\/\/alenta.net\/requisitos-del-sw-y-la-iec62304\/","title":{"rendered":"Requisitos del SW como producto sanitario. IEC62304"},"content":{"rendered":"\n
Los fabricantes de Software como Producto Sanitario o SaMD (Software as Medical Device) tienen que documentar el ciclo de vida completo del desarrollo del SW de acuerdo con la norma IEC62304. La metodolog\u00eda no est\u00e1 definida y se puede usar la que mas convenga. Es de aplicaci\u00f3n para todo software m\u00e9dico y al ciclo de vida completo y adem\u00e1s requiere de la aplicaci\u00f3n de la ISO14971<\/p>\n\n\n\n
El SaMD se clasifica de acuerdo con la norma IEC62304 por clases de seguridad:<\/p>\n\n\n\n
Cuando no exista una clasificaci\u00f3n clara siempre lo clasificaremos como Clase C<\/strong>.<\/p>\n\n\n\n La norma IEC62304 se desglosa en apartados y se requiere que el ciclo de vida del SW sea implementado con los procesos de los apartados 5, 6, 7, 8 y 9 y ser\u00e1 responsabilidad del fabricante documentarlos convenientemente. Estos procesos son:<\/p>\n\n\n\n As\u00ed tenemos que dependiendo de la clase de seguridad que tenga el SW (A, B o C) le aplicaremos unos apartados de la norma u otros como se muestra a continuaci\u00f3n:<\/p>\n\n\n\n El ciclo de vida del desarrollo del SW, seg\u00fan la norma EN 62304 la podemos dividir en estas partes:<\/p>\n\n\n\n Los fabricantes pondr\u00e1n los medios necesarios para que el proceso de desarrollo del SW est\u00e9 totalmente planificado por uno varios planes que detallaran los subprocesos que lo componen, los entregables o documentos de cada actividad y tarea, la trazabilidad entre los requisitos del sistema, los requisitos del SW, los requerimientos de sistema de ensayo o test y las medidas de control de riesgo implementadas. El Plan o planes se deben tener actualizados de forma continua.<\/p>\n\n\n\n Como mantenimiento de SW entendemos los procedimientos para realizar actualizaciones, resoluci\u00f3n de errores, parches de seguridad y qu\u00e9 hacer cuando se produzca la obsolescencia del SW. Este proceso estar\u00e1 totalmente planificado y se detallaran: los procedimientos para recabar, documentar, evaluar, resolver y realizar la trazabilidad del feedback sobre el software despu\u00e9s de su entrega. No solo esto sino que tambi\u00e9n ser\u00e1 necesario establecer los criterios para determinar el grado del feedback para considerarlo un problema u otra cosa. <\/p>\n\n\n\n Por cada modulo de software que pueda contribuir a una situaci\u00f3n de riesgo, se definir\u00e1n las medidas de gesti\u00f3n y control del mismo. Cualquier cambio en el SW o cualquier evento no identificado anteriormente estar\u00e1 sujeto a una verificaci\u00f3n de las medidas de control de riesgo para ver en qu\u00e9 manera podr\u00eda afectar a la seguridad del SW.<\/p>\n\n\n\n Ser\u00e1 necesario establecer un esquema para la identificaci\u00f3n de las configuraciones y sus versiones. El fabricante solo realizar\u00e1 un cambio en la configuraci\u00f3n o aplicar\u00e1 una configuraci\u00f3n nueva despu\u00e9s de una aprobaci\u00f3n de petici\u00f3n de cambio. Deber\u00e1 existir una trazabilidad desde la petici\u00f3n de cambio hasta la aprobaci\u00f3n del cambio. Todas las configuraciones y sus cambios quedar\u00e1n reflejadas en un documento para que se pueda realizar una trazabilidad del proceso.<\/p>\n\n\n\n Ante cualquier problema detectado deberemos generar un informe del problema. Es importante reflejar el tipo de problema\/resoluci\u00f3n, como correctiva, preventiva, adaptativa a un nuevo entorno. Reflejaremos el alcance del problema as\u00ed como n\u00ba de unidades, modelos o accesorios afectados, al igual que el tiempo invertido en la acci\u00f3n. Ser requiere una investigaci\u00f3n que determine las causas, que eval\u00fae las posibles consecuencias usando el proceso de gesti\u00f3n del riesgo en caso de que este nuevo problema resulte ser un riesgo que hay que gestionar y que no conoc\u00edamos hasta el momento. Es importante informar sobre el problema a los partes involucradas. Las partes involucradas en un problema pueden depender de si el SW se ha liberado ya o no, si se encontr\u00f3 dentro de la organizaci\u00f3n o fuera de ella, etc…El fabricante decidir\u00e1 en cada caso las partes a ser informadas. El informe puede reflejar tambi\u00e9n una tendencia que se est\u00e9 produciendo.<\/p>\n\n\n\nApartados de la norma<\/strong><\/h2>\n\n\n\n
\n
<\/figure>\n\n\n\n
<\/figure>\n\n\n\n
<\/figure>\n\n\n\n
<\/figure>\n\n\n\n
Ciclo de vida de desarrollo del software<\/strong><\/h2>\n\n\n\n
<\/figure>\n\n\n\n
Proceso de Desarrollo del Software<\/h2>\n\n\n\n
Proceso de mantenimiento<\/h2>\n\n\n\n
Proceso de gesti\u00f3n del riesgo del Software<\/h2>\n\n\n\n
Proceso de gesti\u00f3n de la configuraci\u00f3n<\/h2>\n\n\n\n
Proceso de resoluci\u00f3n de problemas<\/h2>\n\n\n\n