Lógica de ramificación y campos calculados en REDCap: ejemplos prácticos

⏱ 8 min de lectura

Por el Dr. Ángel Luis Rodríguez Santisteban · Médico de Familia · Investigación en Atención Primaria · tudoctordeconfianza.es

Cuando uno empieza a diseñar un cuaderno de recogida de datos en REDCap, la tentación es meterlo todo en una pantalla plana: cien campos en fila, visibles siempre, rellenados a mano. Funciona, pero es frágil y agotador para quien introduce los datos. Dos herramientas cambian por completo esa experiencia: la branching logic en REDCap (lógica de ramificación) y los calculated fields (campos calculados). La primera enseña u oculta campos según lo que se va respondiendo; la segunda calcula valores automáticamente a partir de otros. Bien usadas, reducen errores, ahorran tiempo y mejoran la calidad del dato. Mal usadas, generan datos perdidos silenciosos y discrepancias difíciles de rastrear.

En este artículo veremos la sintaxis real de REDCap, ejemplos pensados para Atención Primaria y, sobre todo, las buenas prácticas que evitan los disgustos clásicos. Si todavía estás decidiendo qué herramienta usar para tu estudio, te recomiendo leer antes la comparativa REDCap vs Excel y Google Forms, porque parte de las funciones que vamos a comentar son justo las que justifican dar el salto.

Qué es la branching logic en REDCap y para qué sirve

La branching logic en REDCap es una condición que decide si un campo se muestra o se oculta en el formulario. Mientras la condición no se cumple, el campo permanece oculto y no se puede rellenar. En cuanto la respuesta del usuario hace que la condición sea verdadera, el campo aparece. Es lógica de presentación: no borra datos por sí misma, simplemente controla la visibilidad en pantalla.

El caso de uso más típico en la consulta es evitar preguntas que no tienen sentido para ese paciente. No queremos pedir la fecha de la última regla a un varón, ni preguntar por el número de cigarrillos a quien ha contestado que nunca ha fumado. La ramificación hace que el formulario se adapte a cada caso, lo que se traduce en menos ruido, menos errores y una recogida más rápida.

La sintaxis de las condiciones

Las condiciones se escriben referenciando el nombre de variable (no la etiqueta) entre corchetes, seguido de un operador y un valor. La regla de oro: el valor que comparas es el código de la opción, no su texto visible. Si en un campo desplegable «Sexo» definiste 1 = Femenino y 2 = Masculino, la condición correcta es [sexo]="1", no [sexo]="Femenino".

• Igualdad: [sexo]="1" muestra el campo solo si el sexo registrado es femenino.
• Distinto / comparaciones: [fumador]<>"0", [edad]>=65, [imc]>30.
• Y / O lógicos: [sexo]="1" and [embarazo]="1"; [diabetes]="1" or [hta]="1".
• Casillas de verificación (checkbox): se usa la notación especial [sintomas(2)]="1", que es verdadera si está marcada la opción cuyo código es 2.
• Campo vacío / no vacío: [campo]="" y [campo]<>"".

Conviene recordar dos detalles que despistan. Primero, los valores numéricos de los campos de opción se escriben entre comillas porque para REDCap son códigos: [fumador]="1". Segundo, en formularios longitudinales o con repetición puedes necesitar referenciar campos de otro evento con la sintaxis [evento_arm_1][campo]; si no especificas evento, REDCap asume el evento actual.

Ejemplos prácticos de ramificación en Atención Primaria

Mostrar campos de embarazo solo en mujeres

Imagina un bloque de antecedentes ginecológicos: «¿Está embarazada actualmente?», «Semanas de gestación», «Fecha probable de parto». No tiene sentido que aparezcan salvo que el paciente sea mujer. La condición en cada uno de esos campos sería simplemente [sexo]="1" (asumiendo 1 = Femenino). Si además quieres que «Semanas de gestación» solo se muestre cuando la respuesta a estar embarazada sea afirmativa, encadenas: [sexo]="1" and [embarazada]="1". Así el formulario va revelando preguntas de forma progresiva y coherente.

Preguntas de seguimiento según una respuesta

El patrón «si responde X, pregunta Y» es el pan de cada día. Un campo «¿Fuma?» con opciones 0 = No, 1 = Sí, 2 = Exfumador. Los campos «Cigarrillos/día» y «Años de consumo» llevan la condición [fumador]="1", mientras que «Tiempo desde que lo dejó» lleva [fumador]="2". De este modo cada perfil ve únicamente lo que le corresponde y nadie introduce un dato incoherente, como cigarrillos diarios en un no fumador.

Bloques completos que dependen de una variable

Cuando varios campos comparten la misma condición, REDCap permite aplicar la lógica a cada uno, pero el patrón habitual es usar un descriptive field como cabecera de sección con su propia ramificación, y replicar la condición en los campos del bloque. Por ejemplo, un apartado de «Cribado de riesgo cardiovascular» que solo se despliega si [edad]>=40. Pensar en bloques mantiene el cuaderno limpio y facilita el mantenimiento.

Campos calculados: cuándo sí y cuándo no

Un campo calculado (tipo de campo «Calculated Field») contiene una ecuación que REDCap evalúa automáticamente a partir de otros campos. El usuario no lo edita: se rellena solo. Es ideal para derivar valores objetivos a partir de datos ya introducidos.

Calcular el IMC

El ejemplo clásico. Con un campo de peso en kilos (peso) y otro de talla en metros (talla), la ecuación del campo de IMC sería round([peso]/([talla]*[talla]),1), que devuelve el índice con un decimal. Si la talla la recoges en centímetros, ajusta la fórmula dividiendo: round([peso]/(([talla]/100)*([talla]/100)),1). REDCap admite funciones matemáticas habituales como round(), roundup(), sum(), mean() o datediff().

Calcular la edad o un riesgo sencillo

Para la edad a partir de la fecha de nacimiento y la de inclusión se usa datediff([fecha_nac],[fecha_inclusion],"y","ymd",true), que devuelve los años transcurridos. También puedes construir un score sumando puntos: un campo calculado que sume condicionalmente factores de riesgo con if() anidados, por ejemplo if([hta]="1",1,0)+if([diabetes]="1",1,0)+if([fumador]="1",1,0). Para algoritmos complejos, sin embargo, suele compensar más validar el dato fuera y guardar el resultado, porque las ecuaciones muy largas son difíciles de auditar.

Lo que NO debe ser un campo calculado

Aquí está la trampa más frecuente. Los campos calculados no almacenan datos de origen: si un valor tiene que ser introducido por un profesional (una cifra de laboratorio, una tensión medida, una respuesta del paciente), nunca debe ser un campo calculado. El cálculo es para derivar, no para capturar. Si necesitas que un valor por defecto se pueda corregir a mano, lo correcto es un campo normal, no un calculado, porque este último se recalcula y machacaría la edición manual.

Buenas prácticas para no llevarte un disgusto

• Prueba siempre en modo Desarrollo antes de pasar a Producción. REDCap distingue claramente ambos estados. En Desarrollo puedes cambiar la lógica libremente; una vez en Producción, los cambios estructurales pasan por el Draft Mode y, según la configuración, requieren aprobación del administrador.
• Cuidado al cambiar la ramificación con datos ya recogidos. Si un campo tenía datos y luego añades una condición que lo oculta, esos valores no desaparecen de la base, pero quedan «atrapados» en registros donde el campo ya no se ve. Por eso conviene revisar el informe de discrepancias.
• Usa el botón «Run data quality rules». Tras modificar lógica, la regla «Hidden fields that contain values» te avisa de campos ocultos por ramificación que aún contienen datos: justo el problema anterior.
• No abuses de los campos calculados para datos que deben introducirse. Reserva el cálculo para lo verdaderamente derivable.
• Documenta la lógica. El propio diccionario de datos exporta la columna de branching logic y la de ecuaciones; revísalo periódicamente como parte del control de calidad.

Un apunte importante sobre el comportamiento real: por defecto, los datos de un campo oculto por ramificación no se borran automáticamente al guardar el formulario, salvo que actives expresamente la opción de proyecto que los elimina. Conviene conocer cómo está configurado tu REDCap antes de asumir nada. Si quieres dominar este flujo completo —del diccionario de datos a la exportación, pasando por la validación— lo trabajamos paso a paso en el curso de investigación en Atención Primaria, y tienes una visión de conjunto en la guía pilar sobre REDCap en AP.

Preguntas frecuentes

¿La branching logic borra los datos de un campo cuando se oculta?

No de forma automática por defecto. Cuando un campo deja de mostrarse, su valor sigue almacenado en la base salvo que el proyecto tenga activada la opción de eliminar datos de campos ocultos. Por seguridad, ejecuta la regla de calidad «Hidden fields that contain values» tras cualquier cambio de lógica para detectar valores atrapados.

¿Puedo editar a mano el resultado de un campo calculado?

No. Un campo calculado se rellena solo y se recalcula cada vez que se guarda el formulario, de modo que cualquier edición manual se sobrescribiría. Si necesitas un valor sugerido pero corregible, usa un campo normal con valor por defecto o un cálculo en una variable distinta a la que se introduce.

¿Por qué mi condición con texto no funciona?

Casi siempre porque estás comparando con la etiqueta en vez del código. En los campos de opción (radio, desplegable, checkbox) debes usar el valor numérico definido: [sexo]="1" y no [sexo]="Femenino". Revisa el diccionario de datos para confirmar qué código corresponde a cada opción.

¿Es seguro cambiar la lógica una vez en Producción?

Sí, pero con método. Los cambios se hacen mediante el Draft Mode y, según la configuración del centro, pueden requerir aprobación del administrador. Antes de aplicarlos conviene revisar el impacto sobre los registros ya recogidos y ejecutar las reglas de calidad de datos para no dejar discrepancias.

Para saber más

• REDCap Help & FAQ y documentación oficial dentro de cada instalación de REDCap (sección «Help & FAQ» y «Training Videos»), Vanderbilt University / REDCap Consortium: projectredcap.org.
• Harris PA, Taylor R, Thielke R, et al. Research electronic data capture (REDCap): A metadata-driven methodology and workflow process for providing translational research informatics support. Journal of Biomedical Informatics. 2009;42(2):377-381.
• Harris PA, Taylor R, Minor BL, et al. The REDCap consortium: Building an international community of software platform partners. Journal of Biomedical Informatics. 2019;95:103208.