La mayoría de comparativas de EDC acaban siendo una lista de funciones: si tiene eConsent, si tiene randomización, si soporta modo sin conexión. Las listas son fáciles de rellenar y difíciles de traducir en una decisión, porque dos plataformas pueden marcar la casilla de "tiene SDV" y sentirse completamente distintas de usar cada día durante los dos años que dura un estudio.
Una comparativa más útil pregunta cómo se comporta una plataforma ante las situaciones que todo estudio acaba encontrando: una enmienda de protocolo a mitad de camino, un centro que introduce un valor del que nadie está seguro, un monitor que tiene que verificar trescientos campos antes del viernes. Las dimensiones de abajo son las que predicen esa fricción del día a día, aproximadamente en el orden en que te van a importar.
Velocidad de construcción del estudio
¿Cuánto se tarda de un PDF de protocolo a un eCRF funcionando? Algunas plataformas son genuinamente sin código y rápidas de configurar; otras son flexibles pero asumen un servicio de construcción o un especialista formado en diseño de estudios. Ninguna opción es incorrecta, pero implican plazos y costes totales muy distintos: un constructor rápido de autoservicio vale menos si tu equipo no tiene a nadie que lo use con confianza.
Pregunta específicamente si la plataforma puede ingerir un protocolo o una hoja de cálculo existente y proponer una estructura, frente a exigir que cada campo se defina a mano desde un constructor vacío. Solo esa diferencia puede suponer semanas.
¿Flujo de calidad de datos bloqueante o no?
Esta es la dimensión que más quejas de centros genera y de la que menos se habla en las demos de los proveedores. Una plataforma con comprobaciones bloqueantes impide a un coordinador guardar una visita hasta corregir o justificar un valor marcado, lo cual suena riguroso, y en la práctica significa que el coordinador o bien introduce un valor plausible para pasar la comprobación, o la visita no se registra a tiempo.
Un modelo no bloqueante, donde el valor se guarda, se marca y se convierte en una query que un revisor trabaja después, tiende a producir datos reales más limpios, porque no genera presión para forzar la validación. Pide ver qué ocurre realmente en pantalla cuando un valor falla la validación, no solo si existe la validación.
Verificación de datos fuente: ¿cuán granular, y hereda?
Los requisitos de SDV suelen variar según la criticidad: algunos campos necesitan verificación al 100%, algunos ninguna, la mayoría una muestra basada en riesgo. Pregunta si eso se puede configurar una vez a nivel de estudio y heredarse hasta página y campo, con excepciones solo donde realmente se necesiten, o si cada campo necesita su propia configuración explícita. El segundo enfoque no escala más allá de un estudio pequeño.
Control de cambios: ¿qué pasa cuando el protocolo se enmienda?
Todo estudio de duración significativa recibe al menos una enmienda. La pregunta no es si la plataforma permite cambios estructurales cuando ya hay pacientes incluidos (la mayoría lo permite), sino si te dice qué estás a punto de romper. Una plataforma que elimina o retipa un campo en silencio puede dejar huérfanos datos de pacientes existentes sin avisar; una pensada para esto usa un borrador privado de enmienda, muestra el impacto exacto (pacientes, visitas, formularios, registros de SDV, firmas afectadas) antes de confirmar, registra el motivo del cambio y publica una nueva versión sin eliminar datos recogidos.
Analítica: ¿está realmente en la plataforma, o exporta a una?
Esta es la dimensión que las demos de los proveedores pasan más rápido por encima, porque la respuesta honesta en la mayoría de plataformas es "exportamos a una herramienta asociada o a un módulo separado". Eso no es automáticamente malo, pero significa un segundo sistema, un segundo inicio de sesión y un paso de conciliación entre lo que dice el eCRF y lo que dice el conjunto de datos del estadístico.
Si la analítica nativa te importa, pide verla funcionando sobre un conjunto de datos real en la demo (estadística descriptiva, una comparación de grupos, una curva de supervivencia), no una diapositiva que describa que existe.
Control de acceso: ¿configurado, o un proyecto de implantación?
El control de acceso por rol es un mínimo en cualquier plataforma. Lo que varía es si una plataforma viene con definiciones de rol razonables y ya delimitadas por organización y centro, o si cada despliegue empieza como un ejercicio de configuración de RBAC a medida. Para una CRO que gestiona muchos promotores, o un equipo pequeño sin administrador dedicado, esa diferencia es tiempo de implantación real.
Una checklist breve para una demo de proveedor
Algunas cosas concretas que pedir ver, en lugar de que te las describan:
- Sube una página real de un protocolo y observa si la plataforma propone una estructura de formulario.
- Introduce un valor fuera de rango y observa exactamente qué ocurre en pantalla.
- Pide ver un cambio estructural aplicado a un estudio que ya tiene pacientes de prueba: ¿muestra el impacto antes de confirmar?
- Pide ver un análisis real (no una captura de pantalla) ejecutado sobre datos vivos del estudio.
- Pregunta quién configura roles y centros el primer día, y cuánto tarda.