20.5: Gestión de datos

La gestión de datos es una tarea importante en la mayoría de los ensayos de intervención. Las principales etapas del

proceso de gestión de datos son:

1. introducir los datos en un sistema informático
2. verificar los datos en busca de errores e inconsistencias
3. organizar los datos en una forma apropiada para su análisis
4. archivar los datos.

Una buena administración de datos requiere una estrategia de administración de datos bien definida, no es algo que simplemente sucederá. La complejidad del proceso de gestión de datos dependerá del tamaño y tipo de estudio. La atención a la gestión de datos reducirá en gran medida el tiempo necesario en la etapa de análisis, ya que los datos estarán bien organizados y consistentes y tendrán menos errores.

5.1 Entrada de datos

El proceso de entrada de datos generalmente involucrará a un administrador de datos que diseñe las pantallas de entrada de datos, mientras que otro personal, como los empleados de entrada de datos o el personal de campo, hacen el ingreso real de los datos. Crear pantallas de entrada de datos no es difícil pero requiere cuidados. La pantalla de ingreso de datos debe seguir el cuestionario, por lo que los saltos automáticos se pueden utilizar para seguir los omitidos en el cuestionario, y los menús desplegables se pueden usar para mostrar las mismas opciones que en el cuestionario para preguntas individuales.

Si los datos se ingresan desde formularios en papel, la entrada de datos puede ser doble o simple. La doble entrada de datos se utiliza rutinariamente para minimizar los errores de mecanografía y para garantizar que los datos en la base de datos reflejen con precisión lo que se registró en los formularios. Existen dos técnicas principales utilizadas para la doble entrada de datos. En un método, dos empleados de entrada de datos ingresan independientemente los datos sin ningún conocimiento del trabajo del otro, y se almacenan ambas entradas. Un programa, que puede tener que ser escrito por el administrador de datos, compara las dos entradas e identifica cualquier discrepancia. La resolución de las discrepancias generalmente se denomina “verificación” y se puede hacer de diferentes maneras. En algunos sistemas, la verificación puede implicar que ambos empleados de entrada de datos vuelvan a ingresar los campos de datos específicos donde se identificaron discrepancias y comparando las nuevas entradas. Más comúnmente, una tercera persona resuelve las discrepancias, haciendo referencia a los formularios o cuestionarios originales, y toma una decisión en cuanto a la entrada correcta, cambiando la entrada incorrecta apropiadamente. Una vez que los datos han sido doblemente ingresados y no se identifican discrepancias entre las dos entradas, los datos se consideran verificados.

En el otro método, que se utiliza en programas especializados de ingreso de datos, como CSPro, la segunda persona resuelve los desajustes al momento de ingresar. Una vez completada la primera entrada, una segunda persona ingresa los datos, y cualquier discrepancia se marca inmediatamente, ya que se ingresan los datos. La segunda persona deberá decidir cuál debe ser el valor correcto e ingresarlo en consecuencia. Con este método, generalmente se elige a la segunda persona para que tenga más experiencia y se espera que haga la entrada final, correspondiente a lo que hay en el formulario. Este método es más rápido pero más propenso al error que el primer método descrito.

Las facilidades para la doble entrada de datos son una característica en algunos paquetes de software, por ejemplo, Epi-Info. En otros paquetes, como Access, se debe configurar una doble entrada de datos cuando se crea la base de datos y requeriría un tiempo y habilidad considerables. Una opción es usar un paquete, como Epi-Info, para la entrada de datos, antes de transferir los datos a un paquete separado, como Access, para almacenamiento y administración.

La entrada única de datos es relativamente rara y no se recomienda. Solo se debe considerar si existen extensas rutinas de verificación, fuertes procesos de soporte y tecnología implementada para identificar posibles errores. Generalmente, el costo de hacer una segunda entrada de datos es menor que los costos de la administración de datos adicionales requeridos para limpiar los errores que puedan quedar después de una sola entrada de datos.

La tarea de ingresar datos debe separarse conceptualmente de la tarea de análisis. Se pueden usar diferentes programas informáticos para la entrada de datos, la verificación de datos y el análisis. El sistema de entrada de datos debe diseñarse para que la entrada de datos sea lo más simple posible. Simplificar el proceso de codificación acelerará la tarea y la hará menos propensa a errores. Idealmente, las pantallas de entrada de datos deben parecerse mucho al formulario en papel desde el que se copian los datos. Los cuestionarios también deben diseñarse teniendo en cuenta la entrada de datos. Los datos deben ingresarse como se registra en el cuestionario. No se deben realizar cálculos manuales ni transformación antes de la entrada de datos, todos estos se pueden hacer durante la etapa de análisis.

5.2 Comprobaciones de datos

La mayor parte del tiempo de gestión de datos se toma con verificar los datos del estudio en busca de errores e inconsistencias y “limpiarlos”. Hay tres puntos principales a tener en cuenta al desarrollar las comprobaciones de datos: (1) decidir qué se verificará; (2) determinar cuándo se utilizará cada cheque; y (3) especificar cómo resolver las inconsistencias y errores identificados por las comprobaciones.

Muchos paquetes de software tienen instalaciones incorporadas para la verificación de datos. Estos programas de verificación automática se pueden configurar cuando se crea la base de datos y se ejecutan en diferentes etapas del proceso de administración de datos. Antes de que se cree el programa de verificación, se debe preparar un documento de especificación, definiendo los datos que se verificarán y los errores que el programa se diseñará para capturar. Este documento suele ser escrito por el hombre de datos o estadístico, con aportes de los investigadores, y se conoce como plan de validación de datos o plan de especificación de verificación. Generalmente, la persona que establezca la base de datos del estudio también escribirá el programa de cheques y se encargará de probarlo. El programa debe probarse con datos 'ficticios', antes de usarlo en los datos reales del estudio, para asegurarse de que está funcionando correctamente. Se pueden completar varios cuestionarios 'ficticios' con errores deliberados e ingresados en la base de datos; estos pueden ser utilizados como datos de prueba para fines de verificación.

Las comprobaciones de datos se pueden incorporar a las pantallas de entrada de datos, de manera que los valores ilógicos o inverosímiles se marquen al momento de la entrada. Además, las pantallas de entrada pueden diseñarse, de manera que no permitan la entrada de valores no válidos, como una fecha imposible o un valor de '5' para una pregunta que tenga '1' a '4' como únicas respuestas posibles. Hay argumentos a favor y en contra del uso de verificaciones de datos en el momento de la entrada de datos. Las comprobaciones ralentizarán el proceso de ingreso y, con doble entrada de datos, se puede argumentar que las verificaciones no son necesarias para recoger errores en la entrada de datos, sino que recogerán algunos datos que se han registrado incorrectamente en el cuestionario. Si se incorporan cheques a las pantallas de entrada, deben diseñarse de manera que permitan la entrada de valores no válidos, si eso es lo que se registra en el cuestionario. De lo contrario, el cuestionario debe ponerse a un lado, hasta que se resuelva el error, y corre el riesgo de perderse o extraviarse, para que nunca se ingrese en la base de datos. A excepción de estudios muy pequeños, a menudo es mejor ingresar los datos en la base de datos y ejecutar verificaciones para identificar cualquier error después, especialmente donde hay una gran cantidad de preguntas que podrían necesitar ser revisadas. Sin embargo, la verificación interactiva puede ser preferible cuando los datos son ingresados por el mismo personal de campo que completó los cuestionarios más temprano en el día. Pueden ser mecanógrafos lentos pero, teniendo las entrevistas frescas en sus mentes, es más probable que puedan corregir errores al momento de la entrada. No obstante, en este caso, probablemente sería aún mejor considerar tener los datos ingresados al momento de la entrevista, utilizando métodos electrónicos de captura de datos.

Después de que se complete la entrada de datos y se verifiquen los datos, se ejecuta un programa de verificación automática para identificar errores. Estas verificaciones pueden incluir verificaciones de rango para identificar valores fuera de rango o faltantes (por ejemplo, fechas fuera del rango esperado, edad del participante fuera del rango permitido por el protocolo de estudio) y verificaciones cruzadas para identificar inconsistencias entre valores (por ejemplo, hombres que están embarazadas). El momento en que se ejecutan estas verificaciones requiere una cuidadosa consideración; por ejemplo, si una verificación compara datos de diferentes visitas, los datos de ambas visitas deben estar presentes para que los resultados sean significativos.

En un estudio longitudinal, con visitas repetidas de recolección de datos a cada sujeto, las verificaciones de datos deben realizarse de manera temprana y continua a lo largo del estudio. Cuando se identifican errores al principio del estudio, a menudo es posible descubrir malentendidos en la interpretación del cuestionario o una falla en el diseño del cuestionario que no se recogió durante la fase piloto. La aclaración o formación complementaria puede evitar que esos problemas se repitan a lo largo de todo el estudio.

Los análisis iniciales son una continuación del proceso de verificación y deben incluir la observación de tabulaciones cruzadas de los datos para identificar inconsistencias, y diagramas de dispersión y diagramas de caja para comparar grupos e identificar observaciones periféricas. En ensayos longitudinales grandes, se recomiendan tabulaciones provisionales de datos como una forma de detectar posibles errores de datos. Se pueden realizar comprobaciones especiales sobre observaciones que sean más de dos o tres

desviaciones estándar de la media. Tales observaciones deben verificarse individualmente, ya que no son imposibles, meramente improbables.

Por último, cabe señalar que las discrepancias en los datos requieren mucho tiempo para identificarlas y resolverlas. Las implicaciones para la verificación de datos y la resolución de consultas deben considerarse durante la etapa de diseño del cuestionario. Solicitar información duplicada en diferentes partes del cuestionario es una fuente de consultas innecesarias. También surgirán consultas si el diseño del cuestionario no contempla adecuadamente las respuestas no disponibles o permite respuestas ambiguas. Los cuestionarios suelen incluir preguntas que se utilizan deliberadamente como verificaciones cruzadas de otros campos. Esta puede ser una muy buena política cuando los datos son realmente diferentes. Por ejemplo, una verificación del sexo con el estado de embarazo del sujeto proporciona una verificación cruzada razonable de si la persona no podría posiblemente estar embarazada por ser varón. No obstante, surgen problemas cuando las preguntas duplican los mismos datos, por ejemplo, un cuestionario que pide registrar tanto la edad como la fecha de nacimiento. Las discrepancias y confusión están obligadas a generarse cuando los valores no están de acuerdo. Al diseñar un cuestionario con solicitudes de información repetida, se deben considerar las implicaciones para la verificación de datos y si la información duplicada es realmente necesaria.

5.3 Limpieza de datos

La limpieza de datos implica plantear y resolver consultas de datos que se identifican durante el proceso de verificación de datos y realizar los cambios adecuados en la base de datos para corregir los errores. El objetivo es asegurarse de que los datos sean de la mayor calidad posible, antes de que sean analizados.

Algunas consultas de datos se pueden resolver dentro del grupo de gestión de datos, por ejemplo, un error obvio en el año de una fecha de visita. Sin embargo, la mayoría de los problemas deberán ser resueltos por el equipo de campo o el investigador. Comúnmente, el grupo de gestión de datos enviará una lista de consultas al equipo de campo; el equipo resolverá las consultas escribiendo la respuesta correcta junto a cada una y devolverá la lista al grupo de gestión de datos. Alternativamente, se pueden hacer correcciones al propio cuestionario. Sin embargo, es muy importante que la respuesta original no esté oscurecida, en cambio, debe cruzarse con un solo trazo, para que siga siendo legible, y la nueva información escrita en el costado. Es una buena práctica (y requerida para GCP) para la persona que realiza el cambio para iniciar y fechar los cambios.

Una vez resueltas las consultas, se deberá actualizar la base de datos para reflejar la información corregida. Algunos sistemas de software tienen características para permitir cambios en los datos después de la resolución de consultas. Estos cambios generalmente se realizan a través de las pantallas de entrada de datos y se registran en una pista de auditoría electrónica. En un sistema sin pista de auditoría automática, se pueden realizar cambios directamente en las tablas de datos, aunque esto puede ser más propenso a errores que cambiar los datos a través de las pantallas de entrada de datos.

La corrección o edición de datos para reflejar una resolución generalmente sigue un camino diferente al de la entrada inicial de los datos. La mayoría de los sistemas no admiten doble entrada de correcciones, por lo que es una buena práctica tener una verificación visual de los datos después de la corrección para asegurarse de que el cambio se realizó correctamente. Una vez realizados los cambios, es fundamental volver a ejecutar el programa de verificación, ya que es posible que la actualización de los datos haya provocado que se identifique una nueva inconsistencia.

En algunos casos, es posible que no sea posible obtener una resolución a una consulta, particularmente si hace algún tiempo desde que se recopilaron los datos. Algunos sistemas de software mantienen un registro electrónico de los problemas identificados por el programa de verificación, y se puede ingresar un código para indicar que la inconsistencia no se puede resolver. Alternativamente, a los datos incorrectos se les puede dar un código para 'faltantes' si no se puede obtener la respuesta correcta. El número de veces que esto se hace debe mantenerse lo más pequeño posible y debe documentarse.

Es importante tener una copia maestra única de la base de datos que contenga todas las correcciones de datos que se realicen. Incluso después de que se complete la etapa de limpieza de datos, los errores pueden detectarse mucho más tarde durante el análisis; todos estos deben corregirse en la copia maestra, para que esté siempre actualizada. Debe existir un sistema de control de versiones para garantizar que sea posible conocer qué versión de la base de datos se utilizó para cualquier análisis en particular.

5.4 Nombramiento y codificación de variables

Una de las primeras cosas que se deben hacer, antes de desarrollar la base de datos de estudio, es crear un cuestionario anotado, que contenga los nombres que se darán a las diferentes variables y las características de las variables como numéricas o de texto, la longitud de la variable (número máximo de caracteres), y cualquier listas de códigos específicos que se utilizarán. Idealmente, los nombres de variables deben proporcionar información sobre los datos que se están registrando, por ejemplo, 'nacimiento' para el peso al nacer o 'intdate' para la fecha de la entrevista. En un estudio longitudinal, se debe utilizar el mismo nombre para aquellas variables que se registran en cada visita. Algunos estudios han utilizado una convención de nombrar las variables en diferentes visitas con un número al final correspondiente a la visita, por ejemplo, 'visit_date3' y 'visit_date6' para las visitas 3 y 6. Sin embargo, generalmente es más fácil ejecutar comprobaciones de datos y hacer otras manipulaciones sobre los datos si las variables tienen exactamente el mismo nombre en cada visita. Se debe incluir una variable adicional para el número de visita para identificar la visita.

Algunos paquetes de software tienen restricciones en la longitud de los nombres de variables; en particular, algunos paquetes más antiguos no permiten más de ocho caracteres. Una buena regla general es no usar más caracteres de los permitidos por el paquete de software más restrictivo (en términos del número de caracteres) que probablemente sea utilizado para el estudio.

Las preguntas que tienen categorías de respuestas se introducen mejor como valores codificados, en lugar de texto (por ejemplo, 0 = No, 1 = Sí). Estos campos tienen una lista limitada de posibles respuestas y solo presentan un problema para la gestión de datos si el campo puede contener más de una respuesta o si la respuesta cae fuera de la lista predefinida. Cuando es posible más de una respuesta (por ejemplo, una lista de tipos de anticoncepción alguna vez utilizados), el diseño de la base de datos cambia de un solo campo a una serie de campos, cada uno de los cuales puede contener cualquiera de las respuestas válidas de la lista (codificadas sí o no). Si ocurre una respuesta que no está en la lista predefinida, puede ser necesario un valor para 'otro'. En este caso, es recomendable crear un campo de base de datos adicional donde la respuesta específica también se pueda ingresar como texto. Si una respuesta que no está en la lista ocurre con frecuencia, puede valer la pena crear un nuevo código para ello. También pueden ser necesarios nuevos códigos si el diseño del cuestionario cambia durante el estudio o entre rondas de encuesta. En estos casos, es fundamental que la lista de códigos existente no cambie. En cambio, los nuevos códigos deben agregarse al final de la lista. La codificación de las respuestas a las preguntas se trata con más detalle en el Capítulo 14.

Algunos estudios utilizan texto libre en el cuestionario y vuelven a codificar el texto en categorías al momento de la gestión de datos. Generalmente no se recomienda recodificar las variables de esta manera, ya que, si han sido recolectadas e ingresadas, los datos originales deben encontrarse en el conjunto de datos final. Si se realiza alguna re-codificación después de la entrada de datos, los nuevos datos deben colocarse en una nueva variable, con una nota para indicar cómo se definieron la variable y los códigos.

5.5 Bloqueo de datos

Cuando se han ejecutado todas las comprobaciones de datos, se resuelven las consultas y se completan todas las actividades de control de calidad, los datos se declaran “limpios” y la base de datos está “bloqueada”. Esto significa que no se harán más correcciones a los datos. En estudios conformes con GCP, el ensayo no puede ser desciego, es decir, los códigos de aleatorización puestos a disposición del equipo de estudio y los análisis principales no se pueden realizar, hasta que la base de datos esté bloqueada. En esta etapa, la base de datos bloqueada puede ser depositada ante un organismo independiente, como el comité de seguridad y monitoreo de datos (DSMC), de manera que, si hay alguna consulta posterior sobre la integridad de los datos o cambios que se hayan podido hacer, se pueda hacer una comparación con el conjunto bloqueado.

Incluso en estudios que no se están llevando a cabo para que cumplan plenamente con GCP, es útil, en algún momento, tomar la decisión formal de que los datos están 'cerrados', y no se harán más correcciones. En ocasiones, los datos se pueden cerrar para un análisis, mientras que las correcciones están en curso para otros datos. El propósito de 'cerrar' la base de datos es asegurar que los datos se definan para un conjunto estable de análisis y no cambiarán cada vez que se vuelva a ejecutar el programa de análisis. El cierre de la base de datos, o cualquier parte de la base de datos, no debe hacerse antes de que se hayan resuelto todos los errores que sean corregibles.