En un EDC, un asistente que se limita a responder preguntas tiene un interés limitado. Un equipo de data management espera de una herramienta que ejecute acciones: crear un formulario, definir una regla de visibilidad, añadir un idioma a un estudio. Y como cada acción sobre un estudio está sujeta a las GCP y al 21 CFR Part 11, esa ejecución debe quedar trazada, atribuida a una persona y en espera hasta que alguien la valide.
El Model Context Protocol (MCP) es el estándar que permite a un LLM como Claude, ChatGPT, Gemini, Grok o un modelo alojado en local pilotar un EDC sin reescribir una integración para cada nueva necesidad. Este artículo describe qué cambia respecto a las API, el principio que gobierna todo lo demás (ningún dato clínico se envía al modelo), los casos de uso donde más aporta y lo que no permite.
¿Qué es el Model Context Protocol?
El MCP es un estándar abierto publicado por Anthropic a finales de 2024 y adoptado desde entonces por la mayoría de los proveedores de modelos. Describe cómo un LLM, ya sea Claude, ChatGPT, Gemini, Grok u otro, descubre y llama a las funciones de una aplicación de terceros.
En la práctica, un servidor MCP expone un catálogo de herramientas: list_studies,
get_form_structure, create_item, get_query_stats.
Cada herramienta tiene una descripción y unos parámetros. El modelo lee el catálogo, recibe una
petición en lenguaje natural y decide por sí mismo qué herramientas llamar.
Detrás del servidor MCP trabajan las API REST ya existentes del EDC. El protocolo no las sustituye. Añade una capa que permite a un modelo utilizarlas sin que un desarrollador haya escrito un conector para cada escenario.
API o MCP: qué cambia
Las API siguen siendo la base de cualquier integración, y Datacapt está construido API-first. Son muy adecuadas para necesidades puntuales y estructuradas: una exportación programada a un almacén de datos, una sincronización con un CTMS, un flujo de resultados de laboratorio. La necesidad se conoce de antemano, el formato también, y la integración funciona durante años.
Su límite aparece cuando las peticiones se multiplican y varían. Cada nueva necesidad implica un desarrollo dedicado: una integración para extraer las métricas de inclusión de un centro, otra para alertar sobre formularios atrasados, una tercera para la exportación del comité de seguimiento. Cuando llega la siguiente necesidad, ligeramente distinta, el ciclo vuelve a empezar.
Con un servidor MCP, todas las capacidades del EDC se exponen una sola vez y quedan disponibles de inmediato. El usuario formula su petición en lenguaje natural y el modelo la ejecuta, eligiendo las herramientas adecuadas en el orden correcto.
| Criterio | Solo API REST | API + servidor MCP |
|---|---|---|
| Tipo de necesidad | Puntual, estructurada, conocida de antemano | Variable, formulada sobre la marcha |
| Quién desencadena la acción | Un conector desarrollado para ese caso | Un usuario, en lenguaje natural |
| Coste de un nuevo caso de uso | Desarrollo, pruebas, mantenimiento | Formular la petición |
| Alcance de los datos | Todo lo que autorice la clave API | Solo metadatos y agregados |
| Control de permisos | En la API | En la API, sin cambios |
| Audit trail | Llamada API registrada | Llamada registrada con un origen «MCP» diferenciado |
| Riesgo principal | Rigidez | Mala interpretación de una petición ambigua |
El principio que lo gobierna todo: ningún dato clínico se envía al modelo
El punto de partida es sencillo. Enviar datos clínicos a un LLM público, ya sea Claude, ChatGPT, Gemini, Grok u otro, supone un riesgo que la mayoría de promotores y CRO no pueden asumir: datos de salud, identificadores de sujetos, elementos de aleatorización. Técnicamente sería posible, con garantías contractuales, cifrado y un alojamiento certificado. La opción más segura sigue siendo no enviar nada. Es la que se ha elegido, y todo lo demás deriva de ahí.
Lo que recibe el modelo: recuentos, estados, porcentajes, estructuras. El número de pacientes incluidos por centro, la tasa de SDV, la distribución de queries por antigüedad, la lista de secciones de un formulario con sus reglas de validación.
Lo que el modelo nunca recibe: un valor introducido en un eCRF, una respuesta ePRO, un identificador de sujeto o de screening, el contenido de un consentimiento, un elemento de aleatorización. Los endpoints de monitorización que devuelven filas a nivel de inclusión se agregan en el servidor antes de cualquier envío. Una fila en bruto nunca llega al modelo.
Esta regla se aplica sea cual sea el cliente. El agente integrado en la plataforma y un modelo local conectado por el usuario a través de su propio cliente MCP pasan por el mismo servidor, con los mismos alcances. En modo local, ni el prompt ni el modelo están bajo control del proveedor, por lo que las salvaguardas están en el servicio y no en las instrucciones dadas al modelo. Un alcance ausente no se puede sortear reformulando la petición.
¿Y el cifrado de extremo a extremo?
La pregunta surge a menudo: ¿no se podría construir una pasarela en la que los datos clínicos viajen cifrados de extremo a extremo, de modo que el modelo los manipule sin leerlos nunca en claro?
Técnicamente, sí. Pero un LLM trabaja sobre texto legible. Con un contenido cifrado no puede comparar dos fechas, ni detectar una incoherencia, ni proponer un código MedDRA. Transportaría bloques opacos de un punto a otro, algo que una API ya hace muy bien sin él. Y descifrar del lado del modelo, incluso en un entorno aislado, reabre exactamente la cuestión que se quería cerrar.
La decisión es, por tanto, mantener los datos fuera del modelo y aceptar lo que eso implica.
Lo que esto limita
Hay que decirlo con claridad: esta arquitectura cierra algunas puertas.
- Sin queries a nivel de sujeto. El agente no puede redactar «la fecha de la visita V3 del sujeto 012 es anterior a V2». Puede señalar que un centro tiene doce formularios incompletos en la sección de acontecimientos adversos y preparar un recordatorio para el investigador. El contenido de la query a nivel de sujeto lo sigue escribiendo el data manager.
- Sin revisión médica. El agente no ve los valores, así que no detecta ni incoherencias clínicas ni señales de seguridad.
- Sin exportación de datos recogidos. Las exportaciones MCP se limitan a estructuras y plantillas.
Caso de uso principal: del protocolo al study design del eCRF
Es el caso de uso que más pesa en el calendario de arranque de un estudio, y también el que la regla anterior no afecta: diseñar un eCRF no requiere ningún dato de paciente.
Pasar de un protocolo a un eCRF operativo lleva varias semanas. La reflexión es rápida. Lo que consume tiempo es la introducción: crear las visitas, los formularios, los campos, los controles de coherencia, las condiciones de visualización («este bloque solo aparece si la paciente está en edad fértil»), y después redactar los escenarios de prueba y ejecutarlos uno por uno.
Con un agente conectado al servidor MCP del EDC, el proceso queda así:
- El usuario aporta el schedule of assessments. Con la tabla basta. Transmitir las 80 páginas del protocolo no mejora el resultado y consume tokens para nada.
- El agente crea la estructura en entorno draft: secciones, ítems, campos, lógica condicional y reglas de validación. Se apoya en los elementos del protocolo aportados, en la petición del usuario o en formularios existentes.
- El agente genera un informe de lo que ha creado y redacta los escenarios de prueba UAT.
- El data manager revisa, corrige, valida las pruebas y acepta el paso a producción. Entonces el agente puede ejecutarlo.
Es el principio del human in the loop: en cada paso, el agente propone y una persona decide. El data manager revisa la configuración, corrige lo que haga falta (una nota al pie mal interpretada, un campo numérico donde hacía falta una lista desplegable, siempre hay correcciones), valida los escenarios de prueba que redactó el agente y da su conformidad para el paso a producción. Nada pasa a LIVE sin esa aceptación explícita, que queda registrada en el audit trail a nombre de la persona, no del agente.
Una vez que el estudio está en LIVE, el agente ya no modifica nada en la versión publicada. Cualquier evolución pasa por una nueva versión del estudio, que vuelve a draft, y el agente con ella.
Otros casos de uso
- Dashboards y seguimiento de la monitorización. «Saca las inclusiones del centro 102 frente a las previsiones, y la distribución de queries abiertas por antigüedad.» El agente lee los indicadores agregados (screening, inclusiones, cumplimentación por sección, SDV, datos faltantes), construye el gráfico y comenta la desviación. El monitor (CRA) ya no tiene que abrir cuatro pantallas. El límite aparece cuando la pregunta se apoya en una noción no definida («los pacientes de riesgo»): sin una definición explícita, el modelo se la inventa.
- Traducciones. El agente puede añadir un idioma a un estudio en draft y proponer las etiquetas traducidas, a partir de las etiquetas de origen y de las carencias detectadas.
- Ayuda a la codificación médica. Es el único lugar donde un texto introducido tiene que salir de la plataforma: el término verbatim, solo, con el diccionario y su versión. Ni sujeto, ni centro, ni fecha, ni visita. A cambio, una sugerencia de código MedDRA o WHODrug, nunca un código aplicado. El medical coder valida o sustituye, y no solo por motivos regulatorios: con términos ambiguos o mal escritos, la tasa de error de un modelo sigue siendo demasiado alta para prescindir de la revisión.
Cómo está construido
El servidor MCP es un servicio independiente, situado delante de la API pública. No tiene acceso directo a la base de datos ni credenciales propias. Llama a la API con la clave del usuario, y esa clave no abre nada que su titular no tuviera ya.
[ Data manager / monitor ]
│ «Genera la estructura del eCRF a partir del schedule of assessments»
▼
[ Agente LLM — chat integrado o modelo local del usuario ]
│ get_form_structure(), create_item(), list_templates()
▼
[ Servidor MCP — servicio independiente, clave MCP del usuario ]
│ agregación, filtrado, control del estado DRAFT, registro del origen MCP
▼
[ API pública del EDC ]
│ informe de ejecución, sin datos clínicos
▼
[ Revisión, validación de pruebas y aceptación por el data manager ] ──► producción
La clave MCP es distinta de la clave API clásica. Una integración de sistema y un agente conversacional no comparten ni ciclo de vida ni perfil de riesgo: la clave MCP es individual, caduca, se revoca de inmediato, lleva alcances fijados en su creación y cuotas de volumen. No existe clave de organización ni cuenta de servicio para el MCP.
Cumplimiento: 21 CFR Part 11, Anexo 11, ICH E6(R3)
Tres preguntas se repiten sistemáticamente en las conversaciones con los equipos de calidad.
- ¿Puede el agente ejecutar una acción irreversible? No. Las escrituras están limitadas a estudios en DRAFT o a nuevas versiones, y ese control lo aplica el backend, no las instrucciones dadas al modelo. El paso a producción requiere la aceptación explícita del usuario. Las acciones sobre una versión publicada (modificar un formulario LIVE, aplicar un código, escribir sobre un dato recogido) no están expuestas en absoluto.
- ¿Qué contiene el audit trail? Cada llamada se registra con un origen «MCP» diferenciado de las acciones de plataforma y de las llamadas API clásicas, junto con el nombre de la herramienta, sus parámetros, el usuario que hizo la petición y la marca de tiempo. El actor registrado es siempre la persona, nunca un actor del sistema. Un filtro «origen MCP» permite a un auditor aislar el conjunto en una sola consulta. Es lo que exigen el 21 CFR Part 11 y el Anexo 11 en materia de trazabilidad de sistemas informatizados.
- ¿Se utilizan los protocolos o las estructuras de estudio para entrenar el modelo? Depende del proveedor del LLM y del ajuste que elija el usuario. En Claude, ChatGPT, Gemini o Grok existe la opción de no utilizar los datos para entrenamiento, pero corresponde al usuario o a su organización activarla en su cuenta. Datacapt no tiene visibilidad sobre ese ajuste. Con un modelo alojado en local, la cuestión no se plantea.
La ICH E6(R3) apunta en la misma dirección al insistir en un enfoque proporcionado al riesgo y en la integridad de los datos. Un agente que prepara sin decidir, y que no ve los datos, encaja en esa lógica.
Lo que el MCP no resuelve
Algunas situaciones en las que el enfoque muestra hoy sus límites, más allá de las ya descritas sobre el acceso a los datos:
- La construcción completa sin revisión. El agente produce una base sólida, no un eCRF terminado. Siempre hay que repasar detrás.
- Los errores. Los comete, y algunos son discretos: un tipo de campo, una unidad, una condición invertida. Precisamente por eso el data manager lo revisa todo y el agente no despliega nada sin aceptación.
- El coste. Una construcción completa de eCRF supone un volumen no despreciable de llamadas al modelo, que hay que presupuestar igual que una licencia.
- Las peticiones imprecisas. Un servidor MCP bien diseñado devuelve una pregunta de aclaración en lugar de una acción aproximada, pero eso depende de la implementación.
El MCP con Datacapt
El servidor MCP de Datacapt aplica las reglas descritas en este artículo. Se utiliza desde el chat integrado en la plataforma o desde el cliente MCP que prefiera, conectado al modelo que haya elegido, ya sea Claude, ChatGPT, Gemini, Grok u otro.
- Solo metadatos y agregados. Ningún valor de eCRF, ninguna respuesta ePRO, ningún identificador de sujeto sale de la plataforma. El único texto introducido que puede salir es un término verbatim, solo, para una sugerencia de codificación.
- Escrituras en DRAFT o en una nueva versión, nunca en una versión publicada. Estructura del eCRF, lógica condicional, reglas de validación, plantillas, idiomas. El control está en el backend.
- Una clave MCP por usuario. Distinta de la clave API, con caducidad, revocable, con alcances fijados en su creación. Hereda los permisos de la persona y nada más.
- Origen MCP en el audit trail. Cada llamada es identificable como tal, a nombre del usuario, con la herramienta y sus parámetros. Un filtro dedicado para las inspecciones.
Conclusión
El MCP no cambia lo que un EDC sabe hacer. Cambia quién puede activar esas capacidades y cómo: un data manager o un monitor, en lenguaje natural, sin pasar por un desarrollo dedicado.
En investigación clínica, la condición para que esto funcione se resume en dos reglas. El agente prepara, la persona valida. Y por ahora, el modelo no ve ningún dato clínico, lo que restringe su alcance. Eso debería evolucionar, por ejemplo con un modelo interno alojado en local, que permitiría abrir ciertos datos al agente sin que salgan de la infraestructura.
