Usabilidad IEC 62366 en productos sanitarios: qué exige el expediente técnico

La usabilidad IEC 62366 aparece en la mayoría de los expedientes técnicos de producto sanitario como una carpeta más, con un informe de validación y poco más detrás. En nuestra experiencia revisando expedientes antes de que lleguen al organismo notificado, es justo ese archivo —el usability engineering file— el que con más frecuencia se queda corto: no porque falte el ensayo con usuarios, sino porque nadie documentó cómo se llegó a la lista de tareas críticas que ese ensayo debía comprobar. El organismo no pregunta si el producto es fácil de usar; pregunta si la empresa puede demostrar, paso a paso, que identificó dónde podía producirse un error de uso peligroso y qué hizo para reducirlo.

Lo que dice el MDR, más allá del término «usabilidad»

El Reglamento (UE) 2017/745 no dedica un capítulo aparte a la usabilidad: la exigencia está en el anexo I, capítulo I, punto 5, dentro de los requisitos generales de seguridad y funcionamiento (GSPR). Ese punto obliga al fabricante, al eliminar o reducir los riesgos relacionados con los errores de uso, a reducir en la medida de lo posible los riesgos ligados a las características ergonómicas del producto y al entorno previsto de uso, y a tener en cuenta los conocimientos, la experiencia, la formación y el estado físico de los usuarios a los que se destina —profesionales, legos, personas con discapacidad. El propio reglamento define además el error de uso como una causa expresa de incidente en su artículo de definiciones, al mismo nivel que un fallo de funcionamiento del producto. Y el anexo II, punto 4, cierra el círculo: la documentación técnica debe demostrar la conformidad con cada GSPR aplicable, con su justificación, validación y verificación, así que el punto 5 no es una casilla que se marca sola por diseño; necesita evidencia propia dentro del expediente.

La norma de usabilidad IEC 62366-1: qué es y qué NO es

La norma de referencia para cumplir ese punto 5 es la IEC 62366-1:2015 (con su enmienda de 2020), que define el proceso de ingeniería de usabilidad: especificación de uso previsto y usuarios, identificación de las tareas relacionadas con el uso, análisis de las que son críticas para la seguridad, evaluación formativa durante el diseño y validación sumativa final con usuarios representativos. La pregunta que casi nadie se hace a tiempo es si esa norma da presunción de conformidad automática con el MDR, y la respuesta es que, a día de hoy, no: la IEC 62366-1 no figura en el listado de normas armonizadas publicado mediante la Decisión de Ejecución (UE) 2021/1182 y sus modificaciones posteriores. Eso no la hace opcional —los organismos notificados la exigen igualmente como estado de la técnica reconocido—, pero sí cambia el argumento que hay que llevar al expediente: no basta con citar la norma, hay que construir la justificación de conformidad con el GSPR punto 5 apoyada en el proceso de la IEC 62366-1, no dar por hecho que aplicarla cierra la casilla del artículo 8.

Qué debe contener realmente el archivo de usabilidad

Un archivo de ingeniería de usabilidad completo enlaza con el análisis de riesgos de la ISO 14971, no lo sustituye: cada tarea crítica identificada debe aparecer también como escenario de uso indebido razonablemente previsible en el análisis de riesgos, con su propia mitigación. Lo que un evaluador exige ver, en este orden, es la especificación del contexto de uso (quién, dónde, con qué formación, en qué condiciones ambientales), el listado de tareas relacionadas con el uso separando las críticas de las que no lo son, la evaluación formativa con los cambios de diseño que motivó, el protocolo de la validación sumativa con el tamaño de muestra y el perfil de los participantes justificado frente al usuario previsto real, y el informe final donde cada tarea crítica queda cerrada con un resultado observado, no solo con una opinión del participante. Un producto pensado para autoadministración domiciliaria que se valida únicamente con personal sanitario formado no cumple ese último punto, por buenos que sean los resultados: el usuario previsto no es el que se ensayó.

Dónde se atasca un expediente en revisión

El fallo más repetido no es la falta de ensayo, sino la desconexión entre el análisis de riesgos y el archivo de usabilidad: tareas que el equipo de diseño calificó como críticas en una reunión interna nunca llegan a la matriz formal, y el evaluador las encuentra por su cuenta en las instrucciones de uso. El segundo fallo habitual es una validación sumativa hecha con una muestra demasiado homogénea o demasiado pequeña para el perfil de usuario reclamado, sin justificación estadística ni cualitativa de por qué ese tamaño es suficiente. El tercero, específico de dispositivos con interfaz de software, es tratar la usabilidad del hardware y la del software como expedientes separados cuando el usuario interactúa con ambos como un único sistema, lo que obliga a una validación integrada y no a dos validaciones parciales que nunca se comparan entre sí. Y el cuarto, el que más tiempo cuesta corregir en fase de revisión, es no haber actualizado el archivo de usabilidad tras un cambio de diseño posterior a la validación: para el organismo notificado, esa versión sin revalidar es la que está fuera de conformidad, no la original.

Cómo lo resolvemos antes de que llegue al organismo notificado

La solución no es repetir el ensayo con usuarios cada vez que el organismo pide una aclaración, que es la reacción por defecto de muchos fabricantes y encarece el proceso sin resolver el problema de fondo. Lo primero que hacemos es cruzar la matriz de tareas del archivo de usabilidad contra el análisis de riesgos ISO 14971 línea a línea, porque casi siempre ahí aparece la tarea crítica que falta o la mitigación que no está referenciada. Cuando la validación sumativa ya se hizo pero la muestra o el perfil de usuario son defendibles con matices, construimos el argumento de justificación estadística y de representatividad en lugar de repetir el ensayo completo; cuando de verdad no lo son, planificamos la revalidación acotada a las tareas afectadas, no al conjunto del dispositivo. Y cuando el hueco es de trazabilidad —el trabajo de usabilidad existe pero está repartido entre actas de diseño, correos y una hoja de cálculo—, lo que falta no es más ensayo sino un expediente que lo cuente de forma coherente, que es precisamente donde un informe técnico devuelto se convierte en semanas perdidas.

Preguntas frecuentes

¿La IEC 62366-1 es obligatoria por ley para comercializar un producto sanitario en la UE?

No está citada como norma armonizada en el DOUE, así que no da presunción automática de conformidad, pero el requisito legal —el anexo I, punto 5, del MDR— sí es obligatorio, y en la práctica los organismos notificados exigen un proceso equivalente al de la norma como evidencia de que se ha cumplido.

¿Un dispositivo de bajo riesgo también necesita archivo de usabilidad?

Sí, la obligación del anexo I punto 5 no distingue por clase de riesgo; lo que cambia con la clase es la profundidad razonable del análisis y el rigor exigido a la validación sumativa, no si el archivo es necesario.

¿Se puede reutilizar la validación de usabilidad de una generación anterior del producto?

Solo si el cambio no afecta a ninguna tarea crítica ni al perfil de usuario ni al entorno de uso, y esa equivalencia hay que justificarla de forma explícita en el expediente; un cambio de interfaz, de envase o de instrucciones de uso suele obligar, como mínimo, a una validación formativa nueva.

Si tu documentación técnica MDR incluye un archivo de usabilidad que no está conectado con el análisis de riesgos, o si un organismo notificado ya te ha devuelto observaciones sobre errores de uso y no sabes si necesitas repetir el ensayo o solo reforzar la justificación, revisamos el expediente antes de la siguiente revisión —no después de que vuelva a salir con las mismas observaciones. Es el mismo trabajo que hacemos antes de que un expediente llegue al organismo notificado: contacta con nuestro equipo de productos sanitarios y lo revisamos contigo.