uo d metodologÍa de la inestigaciÓn · 2017-06-28 · un cuaderno de recogida de datos es un...

METODOLOGÍA DE LA INVESTIGACIÓN

CURSO DE

UNIDAD 19:

Dra. Maria Teresa García Morales. Hospital Universitario 12 de Octubre.

GESTIÓN DE DATOS CLÍNICOS

2

Gestión de Datos en la Investigación Clínica

ÍNDICE

1. INTRODUCCIÓN y OBJETIVOS DEL TEMA2. DESARROLLO DE LOS CONTENIDOS DOCENTES2.1 Definición de Datos, Formularios y Diseño de Base de Datos

2.1.1 Definición de Datos a Recoger2.1.2 Diseño de Cuadernos de RecogidA2.1.3 Disposición de los Formularios en los Cuadernos de Recogida2.1.4 Modificaciones en los Formularios

2.2 Plan de Gestión de Datos2.3 Diseño de la Base de Datos

2.3.1 Planificación2.3.2 Estructura de los datos2.3.3 Diseño y desarrollo2.3.4 Testeo, UAT y validación2.3.5 Implementación2.3.6 Mantenimiento y modificaciones

2.4 Validación de la Base de Datos2.4.1 Creación del Plan de Validación de Datos2.4.2 Programación y testeo de los edit checks2.4.3 Validación de discrepancias y cambios2.4.4 Pruebas de Aceptación del Usuario (UAT)

2.5 Gestión de Datos y Entrada de Datos2.6 Validación de Datos

2.6.1 Edit Checks de Limpieza/Validación2.6.2 Gestión de Queries

2.7 Cierre de la Base de Datos2.7.1 Datos Finales y Queries2.7.2 Bloqueo de la Base de Datos2.7.3 Informes Intermedios2.7.4 Informe FinaL2.7.5 Desbloqueo

3. RESUMEN DEL TEMA4. BIBLIOGRAFÍA

3


1. INTRODUCCIÓN y OBJETIVOS DEL TEMA

Estudios clínicos se realizan en muchas especialidades clínicas para probar la eficacia de un tratamiento o una intervención específica en un grupo de pacientes/sujetos, y las inferencias se dibujan sobre el uso del tratamiento en la población general. Existen diferentes tipos o fases de estudios clínicos, pero todos ellos tienen una característica común: los resultados que se reportan al final son tan buenos como la calidad de los datos recogidos y analizados. Un buen resultado de un estudio clínico es un resultado que proporciona las respuestas correctas a las preguntas planteadas, no necesariamente uno que sea positivo o estadísticamente significativo.

Las buenas prácticas de gestión de datos son esenciales para cualquier estudio clínico.

Los estudios clínicos pueden ser grandes o pequeños, pueden implicar un centro o múlti-ples centros. Los estudios multicéntricos permiten una inclusión más rápida de pacientes y, por tanto, las respuestas a las preguntas que se hacen están disponibles más rápidamente. Los resultados de los estudios multicéntricos también se generalizan más fácilmente a la población en su conjunto porque incluye a pacientes de varios entornos, en lugar de sólo un único sitio.

No hay una manera correcta para llevar a cabo un estudio clínico. Hay muchas maneras diferentes de organizar un estudio. El sistema desarrollado para la realización de un estudio específico debe basarse en decisiones inteligentes después de revisar los requisitos del estudio y los recursos disponibles. La planificación prospectiva cuidadosa es esencial para asegurar que el estudio se ejecuta sin problemas, que todos los datos necesarios se reco-gen de una manera oportuna, que el progreso en curso garantiza la seguridad del paciente, y que los resultados finales pueden ser analizados y publicados tan pronto como sea posible después de la terminación del estudio. Un sistema de gestión de datos es satisfactorio si, utilizando los recursos disponibles, se traduce en la obtención de datos precisos y com-pletos que responden a las preguntas científicas oportunas.

4


2. DESARROLLO DE LOS CONTENIDOS DOCENTES

FIGURA 1. DIAGRAMA DE FLUJO DE LAS ACTIVIDADES DE GESTIÓN DE DATOS

2.1 Definición de Datos, Formularios y Diseño de Base de Datos

La identificación de los datos que deben recogerse para un estudio, el posterior diseño de los formularios de recogida de datos, y el diseño de la base de datos son críticos para el éxito de un estudio. Estas tres actividades están relacionadas entre sí y se deben desarrollar para un mejor resultado en el orden indicado. Es decir, primero la identificación de los da-tos que deben recogerse para el estudio; a continuación, el diseño de los formularios de recogida de datos; y luego el diseño y configuración de la base de datos. Siempre es útil revisar los datos recogidos en otros estudios similares antes de diseñar nuevos formularios. Los formularios de recogida de datos, ya sea en papel o en formato electrónico, deben es-tar disponibles antes de la inclusión del primer paciente en el estudio.

2.1.1 Definición de Datos a Recoger

Hay diferentes tipos de datos que pueden ser necesarios recoger para un estudio, y du-rante la fase de planificación de un estudio es importante pensar en todos los requisitos.

Datos de Identificación

Cada formulario tiene que tener un espacio para registrar la información suficiente para una correcta identificación. Esto debe incluir la identificación del paciente y un identificador del estudio. También suele ser útil recoger el nombre del centro que envía los datos, para así poder contactar con éste para correcciones de datos erróneos.

Datos para la Investigación

Los datos para la investigación proporcionan información que se analiza para responder a las preguntas que se hacen en los objetivos del estudio. La identificación de estos datos

5


se debe hacer durante la fase de desarrollo del protocolo.

Siempre es tentador recoger datos “por si acaso”, que pueden ser interesantes cuando se analizan los datos. Sin embargo, la recogida de demasiados datos puede ser perjudicial, ya que, como se aumenta el volumen de datos requeridos, la calidad de los datos recogidos en el cuaderno de recogida puede disminuir. En la evaluación de los datos requeridos, el equipo debe distinguir entre los datos necesarios para la atención clínica del paciente y los datos necesarios para responder a los objetivos de la investigación. Por ejemplo, para ase-gurar que el paciente tiene la atención clínica adecuada, puede ser importante conocer el momento exacto en que se le dio una medicación, pero este nivel de detalle puede no ser importante en el análisis de los datos para el estudio. La información se registra en la his-toria clínica del paciente, pero no hay necesidad de recogerla en el cuaderno de recogida.

Las omisiones de datos críticos en esta fase son casi imposibles de superar una vez en marcha el ensayo, ya que es difícil recoger datos de forma retrospectiva. Es aún peor si no se descubre que faltan datos hasta que se haga el análisis final.

Para evitar esto, durante las etapas de desarrollo se debe preparar un plan de análisis pre-liminar indicando la información que se incluirá en el informe final del estudio. Una vez que esto se ha hecho, será más fácil identificar los datos que deben estar disponibles para el análisis.

2.1.2 Diseño de Cuadernos de Recogida

Una vez que los datos se han definido, se desarrollan los formularios de recogida de datos (CRF). Los formularios pueden ser de papel o electrónicos, y muchos de los problemas de diseño pueden aplicarse a ambos.

Un cuaderno de recogida de datos es un documento impreso o electrónico que está diseñado para recoger los datos requeridos para una investigación. La medición y el registro de los datos en los estudios son, quizás, los pasos más críticos en el proceso global de gestión de datos, por lo que es importante que los CRFs se diseñen con claridad y facilidad de uso en mente. Los CRFs deben diseñarse para permitir que los datos se puedan recoger de manera precisa, clara y sin ambigüedades, lo que garantiza la estandarización y la con-sistencia de la calidad de los datos.

El diseño del CRF tiene un impacto directo en la calidad de los datos recogidos para un es-tudio, por lo que merece la pena invertir tiempo en el diseño y desarrollo de los formularios y desarrollar un díselo amigable para el usuario.

Con el fin de garantizar la coherencia entre el protocolo y el CRF, el investigador debe liderar el proceso de diseño de CRF, con el apoyo del bioestadístico y el gestor de proyecto, cuando sea necesario.

Los cuadernos de recogida siempre deben estar disponibles antes de que se active el estudio. La activación de un estudio sin el CRF es probable que resulte en un estudio con datos incompletos e inconsistentes. Se recomienda que, siempre que sea posible, los formularios se validen con algunos participantes en los ensayos prospectivos antes de la activación del estudio. La validación puede hacerse mediante la cumplimentación de los

6


formularios propuestos utilizando datos históricos de los registros médicos pertinentes disponibles en los centros. Este proceso permite identificar problemas que pueden ser corregidos antes de la aplicación de los formularios en los pacientes reales.

Los formularios de recogida de datos deben ser concisos y recoger sólo los datos nece-sarios.

Contenido y Organización de los Formularios de Recogida de Datos

El objetivo del CRF es recoger los datos que respondan a los objetivos del ensayo. Una vez que los datos requeridos han sido identificados, es necesario decidir cómo organizar estos datos en formularios. En el diseño de los formularios, hay que tener en cuenta que no siempre la mejor manera es minimizar el número de formularios. Puede ser mejor tener más formularios, cada uno con una pequeña cantidad de datos. Para tomar la decisión sobre los formularios que son necesarios para un ensayo, hay que preguntarse:

1. ¿Cuándo estarán disponibles los datos?2. ¿Cuándo se recogerán los datos?3. ¿Quién completará los formularios?

Como primer paso, se debe establecer el periodo de recogida de los datos. Por ejemplo, identificar todos los datos que se han de recoger en el momento que se incluye al paciente en el estudio. Esto normalmente incluye datos sobre el historial clínico del paciente, datos que confirman la elegibilidad del paciente, y los resultados de las pruebas de referencia requeridas por el protocolo. Otros puntos de tiempo relevantes podrían ser los datos recogi-dos durante todo o parte del protocolo de tratamiento (cada ciclo, por ejemplo), y los datos recogidos cuando un paciente completa el tratamiento.

También es útil identificar dónde se recogerán los datos y por quién. Por ejemplo, puede haber datos que son recogidos de la historia clínica y otros datos que deben ser com-pletados por otro especialista. A pesar de que todos los datos se recogen en el mismo punto de tiempo, sería más eficiente tener dos formularios diferentes para el registro de la información – uno para cada investigador. Esto permite que dos personas completen sus datos en paralelo, en lugar de que una persona tenga que esperar a que el otro complete su sección antes de poder completar la suya.

Formato de Preguntas

El propósito de los cuadernos de recogida de datos es recoger datos completos y precisos para el ensayo clínico y para asegurar la estandarización y consistencia de los datos entre los centros participantes. Su formato debe ser diseñado con tres funciones en mente:

• Registro de datos en un formulario de la base de datos.• Recuperación de datos para el análisis.

Las personas que completan los datos en cada formulario deben ser capaces de responder a las preguntas y registrar las respuestas de forma no ambigua y eficiente, reduciendo al mínimo cualquier posibilidad de interpretaciones erróneas o errores de transcripción.

7


Los diseños de los formularios deben ser similares. Las convenciones de codificación tam-bién deben ser consistentes para todos los datos. Por ejemplo, S = Sí y N = No para todos los datos “sí/no”.

Las preguntas pueden tener diferentes tipos de respuestas. Algunos pueden ser texto, como el nombre de algún medicamento; otros pueden ser valores categóricos, como los resultados de las pruebas de laboratorio; otros pueden depender de las características del paciente y requieren que la persona que completa el formulario selecciones la respuesta adecuada a partir de una lista de posibles opciones.

Las de texto suelen limitarse a la información que no va ser analizada directamente. Por ejemplo, un formulario podría recoger una variable codificada preguntando si el paciente estaba tomando antibióticos, y si es afirmativo, preguntar por los nombres de los antibióti-cos. En el análisis, el estadístico puede utilizar fácilmente la variable codificada que indica que el paciente estaba tomando antibióticos, pero a menos que el texto con los nombres de los antibióticos se codifique posteriormente, no sería fácil hacer análisis sobre los fár-macos tomados, ya que las diferencias de ortografía podrían causar dificultades para tra-ducir los campos de texto. Sí es importante conocer los medicamentos tomados, existiendo sistemas de codificación de diccionarios para la traducción de los nombres de los fárma-cos en códigos estándares internacionales.

Cuando se recogen los valores categóricos, una consideración importante es especificar las unidades que se utilizan.

Un tipo común de preguntas en un formulario es uno en el que el usuario tiene que seleccio-nar la respuesta correcta de una lista de valores dados.

Unas directrices que ayudan a la consecución de claridad son:

1. Formular la pregunta con un texto lo más sencillo posible conservando el signifi-cado. La pregunta no tiene que ser planteada como una oración completa, si es una frase corta de manera suficientemente clara.Ejemplo:

2. Usar una terminología que sea familiar para la persona que completa el formulario. Mientras que palabras y frases pueden ser muy familiares para los miembros del equi-po del ensayo al diseñar un formulario, puede que no lo sean para las personas que tienen que completar los formularios en los diferentes centros. 3. Hacer sólo una pregunta cada vez y no introducir preguntas compuestas, que pueden ser confusas.

8


Ejemplo:

Esta pregunta realmente son dos preguntas, y sólo se puede interpretar plenamente si la respuesta es “Sí”. Si la respuesta es “No”, el paciente podría ser:

• Ambulatorio, pero no con una dieta equilibrada.• Con una dieta equilibrada, pero no ambulatorio.• Ni ambulatorio ni con una dieta equilibrada.

Es importante saber las respuestas exactas para ambas partes de la pregunta, por lo que se deben pedir preguntas separadas.Ejemplo:

Fechas

Cuando se completan fechas, es importante identificar claramente el formato que se uti-liza, sobre todo en un ensayo con la participación multinacional. En Estados Unidos, las fechas se registran habitualmente como mes, día y año, pero en muchos otros países las fechas se registran como día, mes y año. Una fecha escrita como 07/08/2006 ¿quiere decir 7 de agosto u 8 de julio? Para reducir este tipo de ambigüedad y garantizar que las fechas se interpretan correctamente, los formularios deben indicar claramente cuál es el formato esperado.

Ejemplo:

En ensayos con participación internacional puede ser menos confuso abreviar el nombre del mes. Por ejemplo, 10/DEC/1995 en lugar de 10/12/1995 (día, mes, año) ó 12/10/1995 (mes, día, año).

Unidades de Medida

Las unidades de medida adecuadas deben indicarse en el formulario de recogida. Si hay posibilidad de que algunos centros participantes reporten en diferentes unidades que otros centros (por ejemplo, en un ensayo internacional):

9


- Los formularios deben permitir especificar las unidades utilizadas o- La documentación proporcionada a los centros debe incluir un algoritmo de con-versión estándar para el estudio.

En general, es aconsejable recoger el valor real y las unidades, y realizar todas las conver-siones centralmente para asegurar mayor precisión. También puede ser necesario recoger los rangos normales de los resultados de las pruebas de laboratorio, ya que éstos también pueden diferir entre laboratorios y, sin este valor, es imposible saber si un resultado está dentro de los rangos normales o no.

Opción “Otro”

A menudo es difícil predecir todas las posibles respuestas a una pregunta en particular, y en estas circunstancias es aconsejable permitir la opción “Otro” como una posible respuesta.

Ejemplo:

Otros aspectos a tener en cuenta son:

• Evitar la duplicación de datos (mismos datos en diferentes ubicaciones en el CRF), a menos que sea necesario para una confirmación explícita. Por ejemplo, el sexo del sujeto sólo se necesita recoger en la visita basal, ya que es poco probable que cambie durante el curso del estudio.• Asegurarse de que las variables de seguridad y eficacia están incluidas en el CRF.• La confidencialidad del paciente debe mantenerse a través del uso del número de identificación del sujeto.• Los datos deben ser recogidos en un orden lógico. Esto reducirá al mínimo el error, especialmente cuando los datos sean transcritos de documentos de origen al CRF.• Limitar la cantidad de datos recogidos como “texto libre”, ya que esto complica el análisis de los datos.

2.1.3 Disposición de los Formularios en los Cuadernos de Recogida

Además de ser coherentes, las preguntas del formulario deben cumplir varios aspectos en cuanto al formato. El formato del tipo de letra debe ser lo suficientemente grande como

10


para leer con facilidad. La disposición de las preguntas del formulario debe ser agradable a la vista y debe permitir la entrada de datos con facilidad.

El uso de diferentes tipos de letra, negrita, cursiva y subrayado puede ayudar a resaltar áreas de un formulario, pero sólo si se usa con moderación.

Para asegurarse de que la respuesta a una pregunta se completa en el lugar correcto, el campo de respuesta debe estar situado cerca de la pregunta.

Es evidente que hay muchas maneras diferentes para diseñar las preguntas en un formu-lario, y los métodos elegidos dependerán del tipo y la complejidad de los datos que se vayan a recoger y de la persona que vaya a completar el formulario. Es importante que el formulario sea fácil de seguir y que las instrucciones sean claras.

La fecha de cada visita debe ser recogida en todos los formularios con el fin de mantenerlos en orden cronológico.

Dentro de los formularios es necesario incluir secciones o módulos con encabezamien-tos que indiquen su contenido para recoger la información sobre diferentes temas (datos demográficos, antecedentes clínicos, evaluaciones de laboratorio, etc.). Un CRF también puede contener cuestionarios y diarios de pacientes.

2.1.4 Modificaciones en los Formularios

Las modificaciones de los cuadernos de recogida de datos después de la activación de un ensayo deben hacerse sólo cuando sean absolutamente imprescindibles. Si es necesario hacer cambios, se deben considerar los siguientes puntos:

1. Si el cambio añade una pregunta, hay que pensar en su ubicación en el formulario. Añadir el cambio al final del formulario simplifica el proceso de cambio. 2. Si el cambio añade otra posible respuesta a la lista de opciones para una pregunta, y las respuestas se registran como códigos numéricos, el siguiente número de código no utilizado en la secuencia debe ser asignado para la nueva opción. No debe ser insertado en el medio de opciones existentes ni ser renumerado.

Por ejemplo, si la primera versión del formulario utiliza los códigos 1, 2 y 3, el nuevo código debe ser el código 4, aunque la opción más lógica fuese colocarlo después de la opción 2. La renumeración significaría que el código 3 significa una cosa en una versión del formulario y otra en la nueva versión. También podría causar confusión en el análisis.

Decidir qué datos se recogen, el diseño y el desarrollo de la base de datos para un ensayo son cuestiones críticas para el éxito de un ensayo. Los errores durante esta etapa de la planificación pueden ser muy costosos por una variedad de razones. Algunos ejemplos de problemas que pueden poner en peligro un ensayo pueden ser el no poder recoger datos importantes, recoger demasiados datos y poner en peligro la calidad de los datos esencia-les, diseño de formularios no claros y difíciles de usar (que conduce a errores de transcrip-ción o grabación), o la construcción de una base de datos con una estructura ineficiente.

11


2.2 Plan de Gestión de Datos

La creación del Plan de Gestión de Datos (DMP) al comienzo de un estudio aporta un valor añadido, planificando todas las actividades del proceso de gestión de datos para un estudio, ya que describe cada una de las actividades, desde la lista inicial de variables o diccionario de datos, hasta la transferencia final de los datos para el análisis estadístico.

El DMP se escribe en el comienzo de un estudio, ya que proporciona un enfoque para identificar el trabajo a realizar, el trabajo que se llevará a cabo, y la documentación que se va a producir.

Los temas a cubrir en un Plan de Gestión de Datos suelen ser:

• Diseño del CRF.• Puesta en marcha del estudio.• Flujo de seguimiento de los datos del CRF.• Entrada de datos.• Limpieza de datos.• Gestión de datos de externos (por ejemplo, datos de laboratorio).• Reconciliación de SAEs.• Codificación de términos. • Creación de informes y transferencia de datos.• Cierre del estudio.

El DMP debe reflejar todos los cambios importantes en el proceso de gestión de datos y de los sistemas informativos que surjan durante el estudio.

El desarrollar un DMP tiene los siguientes beneficios:

• El trabajo a realizar y las responsabilidades están claramente establecidas al inicio del estudio.• Los documentos a esperar al finalizar el estudio se enumeran al comienzo del mismo para que puedan ser producidos a lo largo o al final del estudio.• Ayuda a cumplir con los requisitos reglamentarios.• Las tareas de gestión de datos se hacen más visibles a todo el personal del equipo cuando el DMP se pone a disposición del equipo del proyecto.

Tener una planificación de trabajo desde el comienzo del estudio puede ahorrar tiempo al final del mismo, cuando la presión del tiempo es probablemente más fuerte. Los primeros planes de gestión de datos requieren algo más de trabajo, pero después la carga se debe reducir considerablemente, ya que cada nuevo plan de gestión de datos se basa en la ex-periencia de los anteriores.

12


2.3 Diseño de la Base de Datos

El diseño de la base de datos de un estudio siempre debe seguir el protocolo correspondiente. Este proceso debe comenzar solamente una vez que el CRF está diseñado y aprobado por el equipo del proyecto, y se debe revisar para asegurar la adherencia al protocolo.

El desarrollo de bases de datos siempre debe realizarse en un entorno aislado de cualquier otra base de datos en producción, con el fin de evitar cualquier impacto de una base de datos en desarrollo a los datos reales de un estudio en producción.

2.3.1 Planificación

La etapa de planificación es crucial para el éxito de cualquier proyecto. Durante la fase de planificación se evalúan las necesidades del estudio y se determina la mejor manera de satisfacer esas necesidades. Se deben llevar a cabo las siguientes tareas:

• Revisar el protocolo del estudio, donde se describe la descripción de la investi-gación, las hipótesis, la duración prevista del estudio, y el número estimado de sujetos requeridos para alcanzar el poder estadístico suficiente.• Revisar los formularios del CRF diseñados.• Identificar a los proveedores de servicios que van a participar en el estudio.

La base de datos debe cumplir con los requisitos establecidos para la integridad, exac-titud, fiabilidad y rendimiento esperado. En la práctica, esto significa que los datos del estudio deben ser almacenados en una base de datos con las siguientes características:

• La base de datos almacenará los datos tal y como se define en el CRF y en el proto-colo, en lo relativo al número de participantes y visitas.• Habrá una identificación ID inequívoca y única para cada participante.• Habrá un sistema de seguridad basado en roles que impide el acceso no autorizado a los datos.• Se recomienda mantener un adit trial de la base de datos, de manera que, cuando se cambia algún dato, se registra el valor original que tenía, así como la persona que hizo el cambio, el valor nuevo, la fecha y la hora del cambio, y las razones para el cambio (la base de datos suele pedir al usuario que introduzca el porqué del cambio del valor del dato).

2.3.2 Estructura de los datos

Durante esta fase se define la estructura de datos que mejor se ajuste a las necesidades del proyecto, utilizando técnicas y conocimientos para el desarrollo de bases de datos:

• Realizar una normalización de la estructura de datos.• Elaborar un diccionario de datos (especificaciones de los datos) para la docu-mentación de la estructura de datos.

13


El diccionario de datos contiene una descripción de todos los campos de datos que deben recogerse, sus tipos de datos y los rangos de valores válidos. Suele incluir la siguiente in-formación para cada variable:

• Nombre de la variable.• Descripción: texto libre que describe brevemente la variable.• Término: cómo debe aparecer la variable en el formulario de entrada de datos.• Formato de la variable:

- Número Entero: por ejemplo, ##9; es decir, al menos 1 dígito, pero es posible hasta 3 dígitos.- Número Real: por ejemplo, - ##9.9##; unos dígitos obligatorios y otros opciona-les antes y después del punto decimal, y permitiendo valores negativos.- Fechas: por ejemplo, dd/mm/aaaa, y tiempo, hh:mm.- Texto.

• Formulario• Recoger si: condiciones de activación que se deben cumplir antes de una variable para que pueda ser completada.• Estado de la variable:

- Obligatoria: cuando una variable debe ser completada para permitir que un for-mulario pueda ser guardado y considerado como completo.- Opcional: cuando una variable puede quedar incompleta y no será considerada como dato faltante.

• Categorías: para cualquier variable categórica, los posibles valores que la variable puede tomar.

2.3.3 Diseño y desarrollo

En esta fase, los documentos producidos en la fase de análisis de la base de datos se uti-lizan para crear la base de datos de recogida de datos.

Se recomienda diseñar una interfaz fácil de usar para el personal de entrada de datos como usuario final.

2.3.4 Testeo, UAT y validación

Esta etapa consiste en el diseño y programación de los edit checks en la base de datos, las pruebas de aceptación del usuario (UAT) y la validación de toda la base de datos.

El testeo y la fase de validación se deben llevar a cabo de acuerdo con la validación de la base de datos, que se explicará en el próximo apartado.

14


2.3.5 Implementación

La implementación se llevará a cabo una vez que la base de datos haya sido validada, e inmediatamente antes de que los usuarios sean entrenados en el uso del CRF y de que la base de datos sea liberada para la entrada de datos reales.

El último paso es comprobar que todos los pasos anteriores (diseño, desarrollo, testeo y UAT) se han completado adecuadamente.

2.3.6 Mantenimiento y modificaciones

La base de datos debe ser controlada continuamente para identificar errores del sistema y funcionalidades.

Pueden ser necesarias modificaciones en la base de datos una vez que ésta esté validada, por ejemplo, por una enmienda al protocolo.

Es recomendable la acumulación de varias modificaciones para minimizar los cambios en la base de datos.

Una vez que los cambios se han implementado en la base de datos, se debe ejecutar un testeo completo para asegurar que todos los campos y validaciones asociadas funcionan. correctamente.

FIGURA 2. DIAGRAMA DE FLUJO DEL PROCESO DE DISEÑO DE LA BASE DE DATOS

15


2.4 Validación de la Base de Datos

La validación de la base de datos es parte del proceso de desarrollo de la misma, y se inicia una vez que el CRF es aprobado y la base de datos está diseñada y programada. La base de datos debe estar desarrollada y validada con anterioridad a la entrada del primer participante en el estudio.

2.4.1 Creación del Plan de Validación de Datos

El proceso de validación de la base de datos consiste en la validación de los formularios específicos de ésta de un ensayo. El uso de una base de datos validada es un requisito de buena práctica en gestión de datos.

La validación de la base de datos que se va a utilizar en el estudio es un proceso crucial para asegurar y garantizar la calidad e integridad de los datos.

Una vez que la base de datos ha pasado por la etapa de diseño, se deben evaluar los ries-gos de ésta (datos en los que se espera que se produzcan mayores porcentajes de error) e identificar los datos que deben ser verificados para cada estudio, con el fin de definir los edit checks necesarios en el Plan de Validación de Datos (DVP).

El documento de validación contendrá todos los edit checks (manuales y automáticos) que se llevarán a cabo para poner a prueba la consistencia de los datos.

Este Plan de Validación de datos está incluido en el Plan de Gestión de Datos. El DVP debe contener los siguientes campos que se deben completar para cada uno de los edit checks:

• Número de edit check: identificador único para cada condición del ensayo.• Check: instrucciones que deben seguirse a fin de probar el requisito.

2.4.2 Programación y testeo de los edit checks

Los edit checks serán programados según las especificaciones del Plan de Validación de Datos.

Se crearán unos datos ficticios con el fin de testear los edit checks. Los casos de prueba contendrán datos de ejemplo que activarán todos los edit checks descritos en el Plan de Validación. El contenido y el número de formularios de un CRF que se deben completar con datos ficticios puede variar dependiendo de los datos que necesiten ser comprobados para cada estudio.

A continuación, los edit checks se ejecutan con los datos de prueba: los edit checks mostrarán mensajes de error, que se compararan con los que se esperaban según los da-tos introducidos con el fin de asegurarse que son exactamente los mismos.

Una vez que todas las pruebas se han superado con éxito (sin discrepancias entre los re-sultados de las pruebas y los esperados), se documentarán los hallazgos en la validación de la base de datos.

16


El siguiente diagrama de flujo describe el proceso de programación y validación de los edit checks:

FIGURA 3. DIAGRAMA DE FLUJO DEL PROCESO DE PROGRAMACIÓN Y VALIDACIÓN DE LOS EDIT CHECKS

2.4.3 Validación de discrepancias y cambios

Cualquier error o hallazgo resultante de la validación mencionada anteriormente será regis-trado y se aplicarán los cambios a la programación según sea necesario.

Durante el desarrollo de bases de datos, cualquier cambio en el protocolo que pueda afec-tar a la misma se implementará y documentará.

Una vez que las nuevas variables se incluyen en la base de datos, deben ser probados en un entorno de prueba y aceptados como válidos. Los cambios posteriores en el DVP tam-bién deben modificarse, si es necesario.

2.4.4 Pruebas de Aceptación del Usuario (UAT)

Una vez completada la base de datos y la validación de los edit checks, el usuario puede comenzar las pruebas de aceptación del usuario (UAT).

17


El UAT es la última fase del proceso de prueba de base de datos en la que ciertos usuarios de la base de datos tratan las funciones de la misma y dan su feedback con el fin de ga-rantizar que el sistema es práctico y fácil de usar.

Todos los formularios creados para un determinado estudio deben ser probados durante esta etapa. Se evaluarán los usuarios que deben participar en el UAT basando esta de-cisión en la complejidad del CRF y/o la experiencia de los usuarios del estudio (los usuarios pueden ser Coordinadores de ensayos clínicos, otros investigadores, etc.). El Investigador Principal es el único usuario que siempre debe realizar el UAT para cada estudio.

Una vez que se han superado con éxito todos los casos de prueba, el Investigador Principal aprobará la base de datos, lo que implica la aprobación de la última versión de la misma, el diccionario de datos y los casos de prueba utilizados para la validación de los edit checks.

En este momento, la versión final de la base de datos se pasará a fase de producción.

2.5 Gestión de Datos y Entrada de Datos

Para cualquier ensayo clínico, la precisión en la entrada de datos es esencial. Los errores en la entrada de datos, obviamente, dan lugar a valores erróneos introducidos en la base de datos y, por lo tanto, potencialmente pueden causar resultados erróneos. Es extrema-damente importante que se sistema de entrada de datos tenga controles de calidad ade-cuados.

La entrada de datos debe ir unida a unos controles de calidad. Los controles pueden ser mediante la revisión manual de los datos introducidos o mediante el desarrollo de controles automáticos de rangos de valores, tipos de datos, y relaciones lógicas entre los datos.

Los rangos de valores comprueban que un dato está dentro de un rango esperado de va-lores. Por ejemplo, un dato podría ser aceptable si es > 0 y < 25 o es 99, que es el código utilizado para “desconocido” en este campo.

La comprobación del tipo de campo es la que verifica que los datos introducidos en un campo son del tipo correcto. Por ejemplo, si se especifica un campo como “entero” y se detectan caracteres alfabéticos en ese campo, se generará un mensaje de error. También los campos de fecha se deben definir específicamente, y cualquier dato en ese campo que no pueda ser interpretado como una fecha válida causaría un error.

Los controles lógicos son generalmente específicos para cada ensayo y requieren la elaboración de una lista de relaciones lógicas entre los campos que pueden ser evaluados para verificar que los datos “tienen sentido”. Por ejemplo, si se introduce el género como “Hombre”, y el dato “¿Está embarazada la paciente?” se contesta como “Sí”, el programa detectaría la inconsistencia y generaría un mensaje de error. El alcance de la comprobación lógica dependerá de la complejidad de los datos.

Los controles lógicos generalmente se ejecutan a medida que se introducen los datos, pero también se pueden ejecutar posteriormente, cuando los datos ya se han introducido.

Un control exhaustivo de este tipo puede reducir los errores de entrada de datos a un nivel aceptable.

18


También se pueden detectar valores que faltan programando controles lógicos específi-cos. Los controles lógicos se definen mediante la revisión de los formularios de recogida de datos y la especificación de las relaciones entre los datos, y pueden ser dentro de un formulario o entre diferentes formularios.

Lo más apropiado es que, en el caso de que los datos estén incompletos, se activen unas alertas de validación (edit checks programados en la base de datos) directamente en la pantalla de entrada de datos, de tal manera que el personal de entrada de datos pueda corregir el error de forma inmediata. La alerta generará una consulta (query) que no será cerrada hasta que se introduzca un valor admisible en el campo correspondiente.

Todos los datos de los ensayos clínicos deben ser sometidos a controles de calidad para garantizar que sean lo más completos y precisos posibles. Cualquier proceso de control de calidad debe proporcionar una revisión sistemática y objetiva de los datos y la evaluación de los criterios de valoración del estudio. Los controles se pueden realizar manualmente, electrónicamente, o una combinación de los dos.

Para asegurarse de que la comprobación se hace coherente en todos los pacientes, se debe desarrollar un manual documentando los controles que deben realizarse y la acción que debe tomarse si se detectan errores. Las inconsistencias normalmente requieren una consulta (query) al centro participante. Una vez corregido el error, los datos pasarán el control de entrada de datos.

2.6 Validación de Datos

La limpieza o validación de datos se refiere al conjunto de actividades que se utilizan para asegurar la integridad, validez y exactitud de los datos reales de la base de datos. Las actividades de limpieza de datos pueden incluir una revisión manual de los datos y edit checks que identifican los datos inexactos o no válidos utilizando rangos, datos que faltan, violaciones de protocolo y comprobaciones de coherencia.

Cualquier procedimiento de limpieza de datos que se realice manualmente o automática-mente mediante la programación de edit checks, tiene que ser definido en el Plan de Vali-dación de Datos, incluido en el Plan de Gestión de Datos.

2.6.1 Edit Checks de Limpieza/Validación

Los controles de calidad de los datos se llevan a cabo de acuerdo a las instrucciones acordadas, a las buenas prácticas clínicas y a los requisitos reglamentarios. El centro debe establecer y ejecutar los edit checks programados durante la entrada de datos, y deberán aplicarse otros procedimientos de comprobación de datos después de la entrada de datos (edit checks manuales).

• Edit checks programados: controles ejecutados durante la entrada de datos. Deben cubrir, al menos, los datos numéricos y las fechas (por ejemplo, faltan los datos de un campo, inconsistencias entre campos).• Revisiones manuales: comparación manual del CRF, formularios, listados, etc; en papel. Por lo general, se aplican a los datos que no pueden comprobarse mediante

19


edit checks programados (por ejemplo, datos de laboratorio que generan un aconte-cimiento adverso).

Los objetivos primarios, los parámetros de seguridad, y los campos que identifican de for-ma única los datos de sujetos dentro de la base de datos clínica, deben ser evaluados para asegurar que están completos y correctos.

La depuración de datos (edit checks manuales y automáticos) puede incluir:

• Confirmar que los valores numéricos están dentro de intervalos predeterminados.• Identificar y eliminar entradas de datos duplicados.• Búsqueda de valores de datos no válidos.• Determinar si hay valores missing donde se requiere que los datos estén completos.• Comprobar la coherencia y la lógica de los datos a través del CRF.• Comprobar la singularidad de determinados valores, como números de sujeto o códigos de identificación.• Comprobación a través de formularios (por ejemplo, una acción tomada en relación con un acontecimiento adverso indica la terminación del estudio, pero el formulario de fin de estudio no indica como causa de finalización un acontecimiento adverso).• Identificar cualquier violación del protocolo.

Se debe tener en cuenta que, en caso de una modificación o cambio en las reglas de vali-dación durante la realización de un ensayo, podría ser necesaria la revalidación de todos los datos. Si los cambios consisten en una modificación de una regla (por ejemplo, cambio de rango) o la creación una regla de validación adicional, se debe documentar en una nue-va versión del DVP.

La frecuencia de limpieza de datos se determinará de acuerdo con las especificaciones del estudio y la frecuencia real de inclusión de pacientes.

Las principales características de los edit checks de validación se resumen en la siguiente tabla:

TABLA 1. CARACTERISTICAS DE LOS EDIT CHECKS DE VALIDACION

20


2.6.2 Gestión de Queries

La gestión de datos y la gestión de queries se pueden realizar de forma continua con los datos actualizados en los centros debido a que la base de datos se actualiza continua-mente con nuevos datos de los centros.

En el caso de los datos incorrectos detectados por los check automáticos, las queries electrónicas se generan automáticamente y pueden tener una respuesta inmediata y ser corregidas por el investigador en el momento.

En el caso de datos incorrectos detectados por los controles manuales, se generará una query, que describe el problema con los datos y las medidas que deben tomarse.

El monitor y el investigador generalmente reciben las queries, y el investigador debe corre-gir las discrepancias. Cualquier acción correctiva aplicada a una query debe ser revisada con el fin de cerrarla query y registrar su condición de corregida. Se debe remitir cualquier query pendiente al monitor y/o investigador tantas veces como sea necesario hasta que se resuelva o se aclare.

Antes del cierre de la base de datos, la lista de checks de validación del DVP (manuales y automáticas) se debe ejecutar de nuevo sobre los datos reales.

FIGURA 4. DIAGRAMA DE FLUJO DEL PROCESO DE LIMPIEZA/VALIDACIÓN DE DATOS

21


2.7 Cierre de la Base de Datos

2.7.1 Datos Finales y Queries

Antes de que la base de datos de un estudio pueda ser bloqueada, se debe asegurar que contiene todos los datos clínicos requeridos por el protocolo del estudio. Los datos son recogidos en los formularios, pero pueden existir otros datos como las correcciones de los centros, los valores calculados, la codificación de los términos reportados o los datos de laboratorio. Cualquiera de estos datos finales puede generar discrepancias que requieran la resolución antes del bloqueo de la base de datos del estudio.

Todos los datos pasarán por el proceso de limpieza, lo que puede generar discrepancias.

También es necesario revisar que todas las resoluciones de las nuevas discrepancias sur-gidas, así como las que estuviesen pendientes durante el estudio, estén resueltas para conseguir la integridad de los datos.

2.7.2 Bloqueo de la Base de Datos

Después de que los datos del último paciente han sido completados por el centro, se blo-quea la base de datos del estudio. Una vez que la base de datos ha sido bloqueada, se puede realizar el análisis final y obtener las conclusiones del estudio. Las últimas tareas a realizar son la recogida de los datos finales, la resolución de las queries pendientes, la reconciliación con otras bases de datos y la realización del control de calidad final.

Una vez que estas tareas se han llevado a cabo, la base de datos se considera bloqueada. Es decir, ningún valor puede ser cambiado. Si se detecta la necesidad de algún cambio o los cambios se consideran lo suficientemente graves, la base de datos del estudio se desbloqueará.

El bloqueo de una base de datos es un hito muy importante en un estudio. Se debe dedicar tiempo para asegurarse de que toda la documentación correspondiente al cierre de la base de datos está completada.

Este es un buen momento para revisar las métricas del estudio, como:

• Número total de formularios completados.• Número total de discrepancias.• Tipos de discrepancias más comunes.• Tiempo promedio para resolver las queries.

La mejor manera de reducir el tiempo necesario para bloquear una base de datos de un estudio es evitar dejar las cosas para el final del estudio. Esto no sólo ayuda a asegurar que el estudio se cierra poco después de que se reciba la última resolución de queries, sino que también mejora la calidad de los datos mediante la detección de problemas poco después de que se han introducidos los datos. Se deben considerar los siguientes enfoques para que tareas de gestión de datos puedan acortar el tiempo hasta bloquear la base de datos:

22


• Introducir los datos tan pronto como sea posible.• Ejecutar los procedimientos de limpieza durante todo el estudio. En el final del estu-dio, las queries pendientes deberían ser únicamente las relativas a los datos comple-tados recientemente.• Identificar los formularios que faltan.

2.7.3 Informes Intermedios

Estos informes pueden realizarse con datos de seguridad durante el desarrollo del estu-dio para asegurarse de que no existe una alta tasa de acontecimientos adversos graves o inesperados. La evaluación de estos informes puede concluir con la suspensión del es-tudio o una modificación del mismo si la tasa de acontecimientos adversos pareciese ser inaceptable.

2.7.4 Informe Final

Para realizar el análisis final se debe llevar a cabo la limpieza de la base de datos final. Se debe asegurar que todos los datos faltantes se solicitan a los centros participantes en el estudio y que éstos los recogen y completan en la base de datos. La mayoría de los ensay-os se cierran una vez que se ha alcanzado el objetivo y los datos han sido completados y validados. Sin embargo, un ensayo se puede cerrar prematuramente debido a acontecimien-tos adversos inesperados.

Cuando la base de datos está completada, el estadístico puede comenzar con el análisis final.

2.7.5 Desbloqueo

Una vez que la base de datos se bloquea y se comienza con el análisis de datos, se pueden encontrar problemas con los datos que requieran correcciones. Se debe documentar la so-licitud para desbloquear la base de datos con las razones detalladas para el desbloqueo de la misma. De nuevo, habría que realizar una revisión y validación de los datos para volver a bloquear la base de datos.

23


3. RESUMEN DEL TEMA

En este módulo se ha analizado el proceso de gestión de datos clínicos en su totalidad – desde la revisión del protocolo con el diseño del CRF hasta el bloqueo de la base de datos. Al describir las funciones y consejos para la práctica de una gestión de datos eficiente, se ha ofrecido un resumen conciso de este proceso esencial en la investigación clínica.

Desde el diseño de la base de datos hasta el bloqueo de la misma, la gestión de datos, el proceso de recogida, limpieza, cumpliendo con las normativas reguladoras, son compo-nentes esenciales en cualquier investigación clínica. Cuando estas actividades se hacen de manera eficiente, los datos estadísticos generados tienen la suficiente solidez.

La calidad e integridad en los datos clínicos son cruciales. Aunque puede parecer que la gestión de datos comienza después de que los datos se han recogido, el proceso comien-za realmente antes de finalizar el protocolo de estudio. Debido a que la gestión de datos se ve como un proceso que se desarrolla durante todo el estudio clínico, es importante la participación desde el principio, comenzando con el desarrollo del protocolo.

El cuaderno de recogida de datos se diseña para la recogida de datos de las actividades específicas requeridas por el protocolo.

El siguiente punto es desarrollar un Plan de Gestión de Datos (DMP), que detalla cómo se deben manejar los datos de acuerdo a cómo se prevé que el estudio discurra. El DMP describe las actividades de gestión de datos que han de seguirse durante el ensayo, in-cluyendo el mantenimiento permanente, el diseño y desarrollo del CRF, el diseño de la base de datos, la entrada de datos, el almacenamiento y la privacidad, la codificación médica, la reconciliación de datos (por ejemplo, datos de un laboratorio central), la revisión de los datos, la gestión de las discrepancias, la extracción de datos, y el bloqueo de la base de datos.

A continuación, se desarrolla el Plan de Validación de Datos (DVP). Este documento con-tiene los edit checks que se van a programar para identificar discrepancias durante la limpie-za de los datos. Las discrepancias deben ser revisadas periódicamente para asegurar que se están resolviendo de manera adecuada por los centros.

La codificación de términos médicos reportados permite la estandarización cuando llega el momento de que los datos son analizados y revisados. Esto es especialmente importante en ensayos multicéntricos en los que hay varios investigadores que recogen la información.

Por último, el bloqueo de la base de datos se pone en marcha después de que todos los datos se han completado para asegurar que no haya manipulaciones en los datos del es-tudio durante el análisis final.

24


4. BIBLIOGRAFIA

• Good Clinical Data Management Practices, Society for Clinical Data Management (SCDM), April 2011 Edition.

• Requirements for Certification of ECRIN Data Centres, European Clinical Research Infra-structure Network (ECRIN), version 3.0, October 2015.

• Eleanor McFadden, Management of Data in Clinical Trials, Second Edition, 2007.

uo d metodologÍa de la inestigaciÓn · 2017-06-28 · un cuaderno de recogida de datos es un...

Documents