Una aplicación que utiliza inteligencia artificial generativa no es necesariamente un producto sanitario por utilizar un LLM, procesar información clínica o ser utilizada dentro de un hospital.
La cuestión regulatoria es bastante más concreta: qué hace el software con la información y para qué finalidad médica ha previsto el fabricante utilizar el resultado.
El artículo 2.1 del MDR incluye expresamente el software dentro de la definición de producto sanitario cuando el fabricante lo destina a una o varias de las finalidades médicas establecidas por el Reglamento: diagnóstico, prevención, seguimiento, predicción, pronóstico o tratamiento de una enfermedad, en términos generales.
MDCG 2019-11 rev.1 traslada este principio al concepto de Medical Device Software (MDSW): software destinado a utilizarse, solo o en combinación, para alguna de las finalidades incluidas en las definiciones de producto sanitario del MDR o de producto sanitario para diagnóstico in vitro del IVDR.
En definitiva, debemos analizar la función concreta, no la tecnología.
Una IA que resume una historia clínica no es necesariamente MDSW
Pensemos en tres aplicaciones construidas sobre el mismo modelo generativo.
Aplicación A: recibe una historia clínica y genera un resumen para facilitar su incorporación a otro sistema, sin iterar ni alterar datos médicos.
Su función consiste esencialmente en organizar o representar información. Si no interpreta esos datos con una finalidad médica individual, el hecho de procesar información clínica no basta para convertirla en MDSW. Es necesario tomar este criterio con precaución, porque no existe completo acuerdo en torno a ciertas interpretaciones de algunos conceptos, tomemos el ejemplo en términos generales, como una mera estructuración de información, sin alterarla.
MDCG 2019-11 rev.1 excluye expresamente de la cualificación como MDSW determinados softwares destinados a funciones no médicas y señala que alterar la representación de datos por razones de presentación, compatibilidad o similares no determina por sí mismo la cualificación. Este es un concepto claro y que como punto de partida será de gran ayuda.
Cambiamos ahora la función.
Aplicación B: analiza esa misma historia clínica e identifica información compatible con una posible insuficiencia cardiaca para que el médico considere esa posibilidad diagnóstica o, simplemente destaca información que considera crítica o especialmente importante.
Aquí el software ya no se limita a presentar información. Está procesando datos de un paciente individual para generar nueva información con finalidad diagnóstica, al menos, de soporte al diagnóstico.
Estamos claramente mucho más cerca de la definición de MDSW. Desde mi punto de vista, ya nos encontramos dentro de ella, aunque faltarían detalles concretos de la finalidad prevista y el principio de funcionamiento.
Avanzamos otro paso.
Aplicación C: analiza los datos del paciente, identifica una posible insuficiencia cardiaca y propone una actuación terapéutica individualizada.
La finalidad médica resulta evidente, es, sin duda, un producto sanitario por participar de forma crítica en el proceso diagnóstico.
La diferencia entre A, B y C no está en el LLM. Puede utilizarse exactamente el mismo modelo fundacional en las tres aplicaciones. Lo que cambia es la finalidad y la función que el fabricante construye alrededor del modelo.
MDCG permite aplicar un análisis bastante concreto a una función GenAI
El esquema de decisión publicado por la Comisión para ayudar a determinar si un software es MDSW resulta especialmente útil para IA generativa.
Una vez confirmado que estamos ante software, uno de los puntos esenciales consiste en determinar si realiza sobre los datos una acción distinta del mero almacenamiento, archivo, comunicación o búsqueda simple.
Después debe analizarse si esa acción se realiza en beneficio de pacientes individuales y, finalmente, si cumple una finalidad comprendida en las definiciones de MDR o IVDR.
Aplicado a GenAI, podemos trasladarlo a ejemplos muy concretos:
- Transcribir una conversación médico-paciente: No será considerado producto sanitario siempre que realice una transcripción literal.
- Traducir un informe clínico: No es considerado producto sanitario, en sí mismo, con la interpretación actual aunque tienen un impacto potencial en el proceso clínico.
- Resumir información clínica sin interpretación médica: En principio no será considerado producto sanitario, pero es necesario evaluar el posible impacto en el proceso clínico, la literalidad y riesgo de introducir sesgo o equívoco en el usuario.
- Extraer de la historia clínica datos relevantes para una finalidad diagnóstica individual: Podría ser considerado producto sanitario tras el análisis de su principio de funcionamiento detallado.
- Generar un diagnóstico diferencial individual o estimar el pronóstico de un paciente: representa un producto sanitario sin ninguna duda, conforme a definición de MDR.
Esta categorización es importante porque evita considerar producto sanitario a cualquier herramienta de IA utilizada en un entorno clínico y viceversa.
MDCG 2019-11 rev.1 es explícito además en otro aspecto: el riesgo de daño asociado al software no es el criterio utilizado para decidir si el software es o no producto sanitario.
El riesgo tendrá una enorme importancia posteriormente para su clasificación. Pero primero debemos cualificar correctamente el software.
El fabricante no puede definir la finalidad prevista ignorando lo que realmente hace la IA
En IA generativa aparece, sin embargo, una dificultad adicional. El MDR define la finalidad prevista en relación con el uso previsto por el fabricante según la información que proporciona en etiquetado, instrucciones (IFU), materiales promocionales o comerciales y evaluación clínica.
Pero un LLM puede tener capacidades funcionales mucho más amplias que la aplicación concreta en la que se integra. Por ello conviene, es imprescindible, distinguir entre capacidad del modelo y función del producto.
Que el modelo fundacional sea capaz de proponer diagnósticos no significa necesariamente que cualquier aplicación construida sobre él tenga finalidad diagnóstica. Lo relevante será cómo se ha configurado el producto, qué entradas admite, qué instrucciones recibe el modelo, qué outputs permite, qué guardrails incorpora y qué utilización del resultado establece el fabricante.
Esta distinción también funciona en sentido contrario. No sería razonable asegurar que una aplicación es meramente administrativa si su configuración permite y pretende analizar información individual del paciente para generar recomendaciones diagnósticas.
En un producto GenAI, por tanto, prompts, RAG, guardrails y lógica de orquestación pueden ser parte de la propia delimitación funcional del producto, este concepto resulta crítico y esencial para la estrategia regulatoria.
Primero cualificar; después clasificar
La secuencia regulatoria debe mantenerse clara, lo idóneo es este orden y no el contrario.
Primero determinamos si la función de IA generativa cumple la definición de MDSW. Solo después analizamos su clasificación.
En MDR, si el software proporciona información utilizada para adoptar decisiones con finalidad diagnóstica o terapéutica (conceptos a los que limita la calificación como producto sanitario), entraremos entonces en la Regla 11, que establece diferentes clases en función, entre otros aspectos, de las consecuencias clínicas que puedan derivarse de esas decisiones.