20.3: Planear el flujo de datos

Hay muchas ventajas al recopilar y almacenar datos de investigación electrónicamente. El almacenamiento electrónico de datos facilita la recuperación fácil, la generación más simple de informes de estudio, la fácil exportación a paquetes estadísticos y el intercambio rápido de datos. Los beneficios del almacenamiento electrónico de datos solo pueden realizarse completamente si la base de datos que almacena los datos está bien diseñada. Una base de datos mal diseñada conduce a un rendimiento deficiente, consultas de datos ineficientes, datos inexactos y poco confiables, y datos redundantes que se duplican en muchos lugares, lo que dificulta su verificación y limpieza. Esta sección se centra en los aspectos clave de los procesos en el flujo de datos.

3.1 Diseño de bases de datos

El diseño de bases de datos es el proceso de organizar los datos de tal manera que puedan ser almacenados y recuperados de manera eficiente. Implica tomar decisiones sobre la mejor manera de modelar un sistema de información del mundo real, como un sistema de recopilación de datos en papel, en una base de datos. Es muy poco probable que un analista pueda diseñar correctamente un sistema sin una comprensión completa de los procesos y actividades clave involucrados en el estudio. Esto requiere que los investigadores pasen tiempo con los desarrolladores del sistema para asegurar que el sistema desarrollado es lo que se requiere.

Es una buena práctica utilizar un enfoque estructurado, denominado ciclo de vida de desarrollo de sistemas, al emprender un proyecto de desarrollo de bases de datos. La elección de la metodología suele estar influenciada por factores como la complejidad de la base de datos propuesta, el tamaño de la base de datos y el equipo de programación, el costo, el tiempo y la criticidad del proyecto. Lo importante es conseguir un enfoque que satisfaga las necesidades del proyecto. Se presenta una visión general de las fases clave involucradas en el desarrollo de bases de datos, en lugar de enfocarse en una metodología específica. Estos procedimientos no deben ser vistos como listas de verificación, sino procesos clave que se pueden incorporar en cualquier metodología elegida. Los procedimientos clave son:

1. especificación del proyecto
2. recopilación de requisitos
3. programación y pruebas
4. implementación de bases de datos ('going live')
5. mantenimiento de bases de datos y gestión de cambios.

El objetivo de la siguiente fase es transformar los requerimientos de alto nivel en tareas y funciones manejables más detalladas que puedan programarse en un sistema de software. Los requisitos se pueden recopilar entrevistando a los usuarios finales de la nueva base de datos propuesta, examinando la base de datos actual, si la hubiera, y también observando los formularios existentes como cuestionarios e informes. Es importante pensar en qué funcionalidad extra se requiere en la base de datos. ¿Se compartirán los datos? Si es así, ¿qué datos específicos se compartirán? ¿Cuáles son los requisitos de seguridad y cumplimiento? ¿Se han evaluado los riesgos y se ha diseñado la base de datos para mitigar los riesgos? El resultado de este proceso es un documento detallado de especificación de requisitos, que describe todos los requisitos funcionales y no funcionales de la base de datos. Es imperativo que los requisitos se especifiquen correctamente y de la manera más completa posible en esta fase; de lo contrario, podría conducir a un sistema que no cumpla con su objetivo previsto y pueda requerir cambios importantes durante la programación y prueba o después de que la base de datos haya entrado en funcionamiento.

La tercera fase consiste en crear un diseño conceptual (diagrama lógico) que muestre las diferentes tablas que se requerirán para almacenar los datos identificados en las dos primeras fases. Un buen lugar para comenzar a la hora de generar la lista de tablas posibles y sus atributos (columnas de datos) es mirar el proceso actual, en su caso, utilizado para recopilar datos. Hay dos escenarios posibles: un sistema informático existente se está convirtiendo o modernizando o construyendo un nuevo sistema desde cero. En el escenario anterior, se deben utilizar como punto de partida las tablas y formas de entrada de datos del sistema informático existente. Si nunca existió un sistema computarizado, comience con los formularios de recolección de datos en papel existentes. Si no hay ninguno, esboce los formularios, con base en el documento de especificación de requisitos, y discuta los bocetos con el equipo de investigación, y afinarlos más. Tenga en cuenta que, si bien algunos de estos formularios de entrada de datos son bocetos de lo que eventualmente se convertirán en pantallas de entrada de datos, otros permanecerán adecuadamente en los ámbitos de los formularios en papel y no necesariamente se mapearán directamente en las pantallas de entrada de datos. Si surgen nuevos requisitos, mientras se está creando el diseño conceptual, agréguelos a la lista de requisitos que se creó en la fase anterior. Al esbozar las tablas, revisar también la lista de reportes existentes y nuevos para establecer un

Un proyecto de base de datos debe comenzar definiendo claramente lo que se espera que haga la base de datos. Se define el requisito de alto nivel, que es la declaración de misión que establece el objetivo pretendido de la nueva base de datos. No debería tener más de unas pocas líneas de largo. Otros factores críticos a definir en esta fase inicial son el alcance, los recursos, los plazos, el hardware, el software y el equipo de base de datos. El alcance es el límite del sistema y la base de datos, y establece qué datos y funcionalidad se incluirán y qué se excluirá. Es importante que el alcance se defina claramente al inicio del proyecto de desarrollo de bases de datos, ya que una mala definición conduce a ambigüedad y a requisitos de base de datos mal definidos. También es importante elegir el hardware y el software temprano, ya que esto puede afectar algunas de las características de diseño de la base de datos. El resultado de esta fase inicial es un documento de especificación de proyecto que define los objetivos, cronogramas, entregables e hitos.

lista definitiva de los informes que el sistema debe producir para satisfacer las necesidades de los usuarios. El objetivo de analizar los reportes es asegurar que las tablas esbozadas tengan todos los atributos necesarios para generar los reportes. Si faltan atributos o tablas, deberían agregarse ahora. La completitud es importante, pero a veces puede ser difícil saber si se han identificado todos los informes que se están produciendo o van a ser producidos o utilizados. El desarrollador de la base de datos puede proceder a crear la base de datos física cuando el equipo considere que los requisitos son suficientemente completos.

Una vez creada la base de datos, un programador diseña los formularios de entrada de datos y los vincula a las tablas de la base de datos. Existen varios tipos de software que se pueden utilizar para crear los formularios electrónicos de entrada de datos para capturar los datos. La elección de las herramientas y el lenguaje de programación dependerá de las habilidades técnicas y la preferencia del equipo. Cuando finalice la fase de programación, se debe probar la aplicación de base de datos. Se recomienda que alguien que no sea el programador que lo desarrolló pruebe la aplicación. Las pruebas son una fase importante, ya que asegura que el sistema sea validado y verificado, un requisito importante para el cumplimiento de GCP. Los usuarios tienen que ser entrenados sobre cómo usar la base de datos, antes de implementarla para su uso real. La aplicación de base de datos debe complementar la capacitación del usuario al proporcionar funciones de ayuda donde los usuarios puedan acceder a la ayuda a través de

3.2 Limpieza e integridad de los datos

La limpieza de datos debe ser un proceso continuo, más que algo que se haga al final del estudio. El proceso por el cual se limpiarán los datos debe estar bien pensado, planificado y documentado al inicio del proyecto, y ciertamente antes de que se haya recopilado cualquier volumen significativo de datos.

La doble entrada de datos se usa comúnmente para minimizar los errores de entrada de datos. En esta técnica, dos personas diferentes ingresan al mismo registro de manera independiente, y las dos entradas se comparan entre sí. Un registro de datos validado es aquel en el que ambas entradas son iguales (ver Sección 5.1). Es importante recordar, sin embargo, que ningún sistema de ingreso de datos puede evitar errores que fueron cometidos por el entrevistador utilizando un cuestionario en papel para registrar información en el campo.

La aplicación de base de datos se puede programar para marcar inconsistencias en los registros, ya sea durante o después de la entrada de datos. Un enfoque es categorizar los errores como críticos y no críticos. Un error crítico es aquel que es tan importante que se implementan sistemas para garantizar que el registro de datos no se pueda guardar en la base de datos hasta que se haya corregido el error, por ejemplo, falta del código de identidad del encuestado o que este esté fuera del rango válido, ya que este código será necesario para vincular información en la base de datos. El programador los escribiría como cheques incrustados en la aplicación de base de datos, a veces llamados 'cheques en línea'. La desventaja de tener demasiadas comprobaciones de este tipo incrustadas en las pantallas de entrada de datos es que los usuarios no pueden guardar los datos hasta que se hayan corregido todos los errores, lo que puede llevar a registros atrasados. Las decisiones sobre qué errores serán críticos y no críticos deben tomarse con la suficiente antelación, para que estos se programen en el sistema. Los errores no críticos no deben impedir que el usuario guarde el registro de datos. En su lugar, se marcarían como consultas de datos e informes para que el administrador de datos haga un seguimiento, rectifique y actualice la base de datos.

Otro enfoque es incorporar verificaciones de datos en un programa estadístico, por ejemplo, Stata, y ejecutar las comprobaciones contra los datos periódicamente. En el caso de un sistema de recolección en papel, se pueden realizar visitas periódicas de monitoreo para asegurar que se están cumpliendo los SOP. Se pueden realizar comprobaciones adicionales tomando una muestra aleatoria de formularios en papel y comparándolos con los registros electrónicos de datos correspondientes.

3.3 Problemas de programación

Los sistemas computarizados de recolección de datos son impulsados por programas informáticos escritos por desarrolladores de sistemas. Los recursos utilizados para desarrollar estos sistemas pueden ser más efectivos si se utilizan buenas prácticas de programación. Los sistemas de datos computarizados deben documentarse a un nivel suficientemente detallado, para que cualquier otro desarrollador de sistemas pueda hacerse cargo rápidamente del mantenimiento o extensión de dicho sistema. Un sistema de datos informatizados mal documentado hace que sea muy difícil realizar cambios en el sistema existente, y le llevará más tiempo a una segunda persona averiguar qué es lo que hay que cambiar. Incluso el programador que escribió el programa inicial puede olvidar detalles técnicos específicos después de unos meses. Invertir el esfuerzo para documentar los programas, a medida que se desarrollan, hace que sean más fáciles de mantener, y los cambios se pueden hacer mucho más rápidamente.

La creación de prototipos es una técnica iterativa utilizada en el desarrollo de sistemas informáticos donde el programador diseña maquetas y pide al usuario que las pruebe y dé retroalimentación. La ventaja de la creación de prototipos es que los usuarios no tienen que esperar hasta que el sistema se haya desarrollado completamente, antes de que puedan probarlo.

3.4 Procedimientos operativos estándar

Los SOP son un conjunto de instrucciones escritas que detallan cómo se lleva a cabo un proceso en particular. Los sistemas basados en computadora soportan procesos de prueba al proporcionar un medio para almacenar, modificar y recuperar datos. El proceso mediante el cual se desarrollan y utilizan estos sistemas informáticos debe ser documentado y controlado por procedimientos (SOP) que aseguren que sean adecuados y, en su caso, que cumplan con GCP. Los SOP permiten a diferentes personas verificar los procedimientos y determinar si lo que se hace corresponde con lo que se debe hacer. Los SOP también son invaluables para capacitar a diferentes personas en las tareas que se deben realizar en el estudio.

Por lo general, es una buena idea dividir los SOP en diferentes categorías, como desarrollo de bases de datos, validación y pruebas de bases de datos, implementación de bases de datos y configuración del sitio, y mantenimiento/respaldos/actualizaciones de bases de datos. Los SOP deben ser escritos por el responsable de la tarea (quién sabe lo que se debe hacer) y revisados por la persona que supervisa su trabajo y finalmente aprobados por el PI de estudio.

3.5 Control de versiones

El propósito del control de versiones es realizar un seguimiento de los cambios realizados en un sistema computarizado durante su desarrollo y después de su implementación. Los cambios pueden provenir de diversas fuentes. Por ejemplo, los usuarios pueden encontrar errores que necesitan ser corregidos cuando empiezan a usar el sistema en vivo o pueden solicitar nuevas funciones o mejoras en el sistema. Además, un cambio en el entorno puede requerir un cambio en el sistema informático.

Por ejemplo, una decisión de pasar de bases de datos de Microsoft Access a bases de datos de SQL Server requerirá cambios en las pantallas de entrada de datos. Otro ejemplo es un nuevo requisito de cumplimiento que requiere que el sistema genere cierto tipo de reporte.

Un requisito para la gestión de datos compatible con GCP es el uso de sistemas de recolección de datos computarizados validados y verificados. Los sistemas son validados y verificados mediante pruebas exhaustivas, comparando el sistema de base de datos con los requisitos del usuario Un sistema validado y verificado es aquel que cumple con sus especificaciones y requisitos y que cumple con el propósito para el que fue creado. Cualquier cambio realizado en un sistema informático ya validado puede introducir nuevos errores. De ahí que el proceso de realizar cambios tenga que hacerse en un ambiente controlado. Las versiones anteriores del código del programa se almacenan en un software de control de versiones, por ejemplo, Visual SourceSafe, Subversion. El sistema debe probarse después de realizar cambios para garantizar que permanezca en un estado validado, antes de implementar la versión actualizada. El proceso detallado para administrar y mantener los cambios en el sistema debe escribirse en un SOP de control de versiones y administración de cambios. Es importante que se cumpla estrictamente el SOP.

3.6 Confidencialidad

La información que pueda ser utilizada para identificar a una persona debe ser almacenada en una base de datos segura que permita que solo personas autorizadas accedan a los datos. Cualquier dato que pueda ser utilizado para identificar a una persona, por ejemplo, nombre, dirección, fecha de nacimiento, debe mantenerse fuera del dominio público. La información sensible debe ser identificada desde el inicio, de manera que los controles ap- propios sean puestos en la base de datos. Si se van a compartir los datos, es necesario decidir cómo se va a hacer esto y qué tipo de controles de seguridad se pondrán en marcha. Los mecanismos técnicos de seguridad, como las pistas de auditoría, el control de acceso mediante inicios de sesión y contraseñas de usuarios, y los permisos deben complementarse con contratos de intercambio de datos y capacitación de usuarios. El cifrado debe usarse al compartir o transportar datos en dispositivos portátiles para garantizar que los usuarios no autorizados no puedan leer los datos, incluso si se apoderan del dispositivo portátil.

3.7 Capacitación

Por muy básico que pueda parecer el sistema de bases de datos, los usuarios deben estar adecuadamente capacitados y deben comprender completamente lo que están haciendo. Esta capacitación puede ser en forma de formación profesional e interna y puede implicar el uso de un prototipo de la base de datos en un esquema piloto. Los registros de capacitación del usuario deben mantenerse como evidencia de capacitación.

3.8 Pruebas piloto y pruebas de bases de datos

Las pruebas de aceptación del usuario y las pruebas piloto se utilizan comúnmente para verificar que la base de datos funciona bien. En las pruebas de aceptación de usuarios, los usuarios finales prueban la nueva base de datos ingresando datos, siguiendo el SOP y probando la funcionalidad proporcionada por la base de datos. Los usuarios finales retroceden comentarios a los programadores y líderes del estudio, quienes pueden realizar los cambios necesarios en los programas de la base de datos y al SOP que definen cómo funcionan los procedimientos. Esto es muy útil, ya que los problemas de bases de datos se identifican temprano y se rectifican, antes de que los datos hayan comenzado a capturarse Las pruebas piloto también ayudan a identificar posibles problemas que pueden surgir cuando los sistemas de estudio se ponen en marcha.