Diseño de CRF: errores comunes y cómo evitarlos

El formulario de reporte de caso (CRF, por sus siglas en inglés) es donde el protocolo se convierte en datos. Si está bien diseñado, el equipo del centro lo llena sin dudar y el análisis recibe lo que necesita. Si no, cada visita genera consultas y los errores aparecen meses después, cuando corregirlos cuesta mucho más.

Estos son problemas habituales en formularios en papel y electrónicos (eCRF), con lo que puedes hacer para evitarlos.

1. Recoger datos que el protocolo no necesita

Es la tentación de agregar un campo "por si acaso". Cada campo extra se llena, se verifica contra la fuente, se monitorea y genera consultas. Además, las leyes de protección de datos, como la Ley 81 de 2019 en Panamá, piden tratar solo los datos necesarios para la finalidad declarada.

Una prueba útil: por cada campo, pregunta en qué análisis, tabla o decisión de seguridad se usa. Si nadie sabe responder, sobra.

2. Preguntas ambiguas o dobles

"¿El participante fuma o bebe alcohol?" admite cuatro combinaciones de respuesta y el formulario guarda una sola. Cada pregunta debe medir una cosa, con un período de referencia claro: "¿Fumó algún cigarrillo en los últimos 30 días?".

Lo mismo ocurre con términos que cada persona interpreta a su manera, como "reciente", "frecuente" o "normal". Si importan para el análisis, se definen en las instrucciones de llenado.

3. Texto libre donde hacía falta una lista

El texto libre es cómodo al diseñar y caro al analizar: "HTA", "hipertensión", "hipertensión arterial" y "presión alta" terminan como cuatro categorías distintas. Cuando la respuesta tiene opciones conocidas, usa una lista cerrada. Reserva el texto libre para lo que no se puede anticipar, como la descripción de un evento adverso que luego se codifica con un diccionario médico como MedDRA.

4. Unidades y fechas sin definir

La glucosa puede venir en mg/dL o en mmol/L según el laboratorio. Si el campo no fija la unidad, o no la pide junto con el valor, los datos no se pueden comparar. Define la unidad en el campo o agrega un selector de unidad con una conversión documentada.

Con las fechas el riesgo es doble. Primero, el formato: en Panamá se escribe día, mes y año, y muchos patrocinadores trabajan con el mes primero, así que un 04/05 se puede leer de dos maneras. Usa el mes en letras o un selector de fecha. Segundo, las fechas incompletas: el participante recuerda que la cirugía fue en 2019, pero no el día. El formulario debe permitir registrar solo el año, o el mes y el año, con una regla clara. Si obliga a poner un día, alguien lo va a inventar.

5. No distinguir entre no hecho, no aplica y desconocido

Un campo vacío no dice por qué está vacío. No es lo mismo que el examen no se hizo, que no correspondía en esa visita o que se hizo y el resultado se perdió. Agrega opciones explícitas para cada caso y pide el motivo cuando el dato debía existir.

En las listas de "marque todo lo que corresponda", incluye la opción "ninguno". Sin ella, una lista sin marcas puede significar "ninguno" o que nadie la llenó.

6. Cálculos hechos a mano

El índice de masa corporal, la edad a la fecha del consentimiento o la tasa de filtración glomerular estimada no deberían calcularse a mano en el centro. Si el formulario pide los datos de base, el sistema o el análisis hacen el cálculo con la fórmula que define el protocolo, y se elimina un error de transcripción posible en cada visita.

7. Validaciones mal calibradas

Las validaciones automáticas (edit checks) detectan errores en el momento de la captura, cuando corregirlos es más fácil. Calibrarlas exige trabajo. Si son demasiado estrictas, bloquean valores reales y el equipo aprende a saltárselas. Si son demasiado laxas, dejan pasar una presión sistólica de 1200.

Prueba cada validación con datos ficticios antes de publicar el formulario: qué valor la dispara, qué mensaje ve el usuario y si ese mensaje le dice qué hacer.

8. Formulario desalineado con el calendario de visitas

Cada procedimiento del cronograma del protocolo necesita un lugar donde registrarse en la visita que corresponde, y ninguna visita debería pedir algo que el protocolo no incluye. Cruzar el CRF con la tabla de actividades antes de publicarlo ahorra consultas en las primeras visitas y evita procedimientos que nadie registró.

9. Cambios sin control de versiones

Los protocolos cambian con cada enmienda, y el formulario cambia con ellos. Cada versión del CRF necesita número, fecha y registro de qué cambió, y los datos ya capturados deben seguir vinculados a la versión con la que se recogieron. Un campo que cambió de significado sin cambiar de nombre es de los errores más difíciles de detectar en el análisis.

Cuando una enmienda cambia el formulario, casi siempre cambia también el consentimiento. Revisa cómo controlar las versiones del consentimiento informado.

Cómo prevenirlos antes de la primera visita

Seguir un estándar ayuda a no reinventar cada campo. CDASH, de CDISC, define cómo recoger datos habituales como signos vitales, medicamentos concomitantes o eventos adversos, y facilita el paso a los formatos que se usan en el análisis. No todos los estudios lo exigen, pero es un buen punto de partida.

Muchos de estos errores terminan como registros inexactos o incompletos. Para repasar qué hace confiable un dato, lee ALCOA+ explicado con ejemplos de campo.

Si tu equipo diseña sus propios instrumentos, Synalvia CRF permite configurar formularios versionados, aplicar validaciones en la captura por sede y exportar los datos con su diccionario para el análisis.