Para llevar a cabo una investigación clínica es necesario elaborar un Cuaderno de Recogida de Datos (a partir de ahora CDR) en el cual se gestionan todos los datos relevantes para llevar a cabo un estudio y poder analizarlos posteriormente. Señalar que estos cuadernos están en papel. Desde hace unos años, gracias a los avances tecnológicos y plataformas accesibles para muchos, se han informatizado y se conocen como Cuadernos de Recogida de Datos Electrónicos (CRDe). En este artículo voy a trasladar mi experiencia en el Área de Informática del IIS La Fe, trasladando los CDR a CDRe. De esta manera conoceréis la metodología en la creación de estos sistemas, los cuales permiten a los equipos de investigación, desarrollar sus investigaciones de forma satisfactoria.
En principio, los CRDe los creábamos mediante C# .net. Esto suponía tener que crear todos los formularios desde cero y programar cada función específica. Más adelante, y gracias a la llegada de un compañero al departamento, empezamos utilizar la herramienta OpenClinica para realizar algunos proyectos. Actualmente utilizamos ambas, cada una tiene sus pros y sus contras, y las utilizamos según la complejidad del estudio.
Tanto OpenClinica como C# .net, ofrecen resultados muy similares. No obstante, en este artículo voy a centrarme en todo momento en OpenClinica.
¿Cómo empieza todo?
En nuestra Área de Informática, los recursos humanos son limitados para llevar a cabo este tipo de tareas. Por eso, es frecuente que alguna compañera de la Unidad de Realización de Ensayos Clínicas (UREC) se ponga en contacto para valorar nuestra capacidad para crear un CRDe y dar soporte durante la vida del ensayo clínico. En otras ocasiones, son los propios investigadores/as o alguno de sus colaboradores/as los que contactan con nosotros para pedirnos este servicio.
Lo habitual es ponernos manos a la obra desde un principio. A pesar de esto, hay momentos en los que no disponemos de los recursos para atender la petición. También existe el caso en el que, los responsables de la investigación tienen la imperiosa necesidad de que el CDRe esté hecho “para ayer”. En estos dos últimos casos, el servicio se externaliza.
Primera reunión: Toma de requisitos ¿Que necesito?
Para empezar con buen pie, lo primero que hacemos es planificar una reunión con algún representante del estudio clínico para conocer su CDR en papel y todas sus particularidades.
Juntos revisamos todas y cada una de las variables para tomar nota de los datos básicos y preguntamos todas las dudas que puedan surgir sobre el tipo de datos que se van a recoger. Estas son las dudas más habituales que aparecen por cada una de las variables:
Variable numérica. Es muy importante saber si se pueden registrar valores negativos y si hay algún rango predeterminado. Además, hay que conocer si el valor se registrará en número enteros o decimales. En el caso de decimales, cuántos se van a registrar.
Variable de selección. En este aspecto, hay que concretar si únicamente se puede marcar una opción o si es multiselección. Un ejemplo de selección única sería el tipo de ventilación, donde únicamente puede ser VMC, VAFO o VNI
Un ejemplo para el tipo de multi selección sería el siguiente:
Variables check (si/no). En este apartado hacemos hincapié en el hecho de no crear sólo una casilla tipo check. Esto se debe a que una casilla vacía puede responder a No o que el investigador olvidó introducir un dato. Así pues, la mejor opción es el sistema de marcar Si o No, tal como se muestra en la imagen anterior. Así el investigador tiene tres opciones: Si, No y Vacía.
Variable fecha. Es necesario concretar desde un inicio si se trata del tipo date (dd/mm/aaaa) o si se necesita que sea datatime (dd/mm/aaaa hh:mm:ss). Lo sé, los informáticos somos así de tiquismiquis. Lo cierto es que preferimos pecar de preguntones y así poder configurar correctamente esta variable desde un principio, en lugar de tener que cambiar sobre la marcha. Siempre será más rápido hacerlo bien desde el principio.
Variable cadena de texto. Se necesita saber si tiene alguna longitud determinada o si por el contrario puede ser un texto de longitud variable para que el investigador pueda escribir todo lo que necesite.
Bloque de datos repetitivos. Un buen ejemplo de esta variable es el registro de acontecimientos adversos. Este bloque consiste en una serie de variables que se pueden repetir. Según se configure el evento en OpenClinica, este puede ser de varias formas. Un buen ejemplo es la imagen que se muestra a continuación, donde se pueden ir añadiendo las filas que se deseen:
A parte de todo esto, es de vital importancia concretar las unidades de medida de cada variable (m2, días, mg, ml…). De esta manera, en caso de no poder verlo en el CDR, siempre se tiene que preguntar.
Por último, en esta fase también tenemos que conocer si el estudio será multicéntrico, para crear en el entorno de prueba al menos dos centros y poder testear su funcionamiento.
Tras la primera reunión, empieza el diseño
Con todos los datos recogidos durante la primera reunión, el equipo del Área de Informática nos ponemos manos a la obra para desarrollar un entorno de preproducción en el que empezaremos a trastear y hacer pruebas haciendo lo siguiente:
Creamos un estudio nuevo.
Si se trata de un estudio multicéntrico, creamos dos centros para poder realizar pruebas y que el investigador principal vea cómo quedará en el futuro en el entorno de producción.
Creamos varios usuarios de acceso al estudio de las personas que van a estar implicadas en la construcción del estudio (normalmente suele ser alguna compañera nuestra de UREC y la persona encargada del estudio) y mandamos los accesos al entorno de preproducción.
Una vez el entorno está configurado, empezamos a trasladar el CDR, (el cual está en papel), al entorno OpenClinica. Esto se hace mediante un documento Excel de carga y confeccionamos visita a visita (o evento a evento como lo denomina OpenClinica) con los requisitos concretados durante la primera reunión.
A medida que las visitas están cargadas en el entorno de preproducción, contactamos con los encargados de la revisión del CRDe para ir confirmando que vamos por el buen camino y todo está correcto.
También aprovechamos la ocasión para que prueben a introducir datos de prueba. De esta manera comprobamos que todo está funcionando según las necesidades de la investigación.
Revisiones
A medida que se revisan las visitas empiezan a surgir cambios para mejorar el proyecto. Esto lo anotamos en nuestro sistema de solicitudes e incidencias GLPi. De esta manera, tenemos un registro por escrito y empezamos a gestionar cada uno de sus cambios y su evolución hasta que se cierran todos los cambios.
Una buena toma de requisitos inicial conseguirá que las revisiones sean las menores posibles
Tenemos el Ok al entorno de preproducción
Una vez se ha testeado todo el entorno de preproducción y tenemos el visto bueno de todo el CRDe, empieza la recta final. Pero antes, se necesita un último dato: el número de pacientes estimados tanto del estudio como por centros para poderlo configurar y poder ver las barras de progreso lo más real posible.
Llegados a este punto, es el momento que más nos gusta: crear el estudio en el entorno de producción, que consta de los siguientes pasos
Crear el estudio con todos los datos reales
Crear los centros, añadiendo el número de pacientes estimados
Cargar el Excel de la versión correcta del entorno de preproducción en el entorno de producción, ya que de momento OpenClinica no tiene opción de migrar todo el estudio.
Por último, los usuarios de OpenClinica, normalmente encontraréis que cada vez que se da de alta una visita en un paciente, es necesario agendarla. Este es un paso que muchos data entry, investigadores, Data Managers o monitores no entienden y les parece molesto. Por este motivo, aquí creamos unas reglas en XML para OpenClinica. Así, cada vez que se cree un paciente, desaparecerá la opción de tener que agendar los pacientes, evitando ese paso molesto.
Con todo creado, llega el momento de dar de alta a todos los usuarios del estudio. Para ello es necesario: nombre, apellidos, correo, rol y centro. El principal problema que tenemos en este apartado se encuentra en los correos electrónicos, porque siempre exigimos direcciones corporativas. Jamás damos de alta ningún correo Gmail, Hotmail, esto se debe a nuestras políticas de seguridad, ya que en principio las cuentas corporativas cuentan con las medidas de seguridad adecuadas que aplica cada empresa. A medida que se registran en el sistema y les asignamos el centro y el rol, empiezan a recibir sus credenciales de acceso.
Atención y servicio durante el estudio
Una vez empieza el estudio, si se ha realizado una buena toma de requisitos por parte del Área de Informática y se ha invertido tiempo por parte de los revisores del estudio introduciendo datos de prueba, no solemos encontrar muchas incidencias o peticiones, a no ser que haya algún cambio de versión de protocolo. Por lo tanto, nuestro día a día desde entonces es el siguiente:
Generar nuevas contraseñas para usuarios que la han olvidado.
Usuarios que no recuerdan cual es la página de acceso
Investigadores/as principales que no pueden firmar un paciente. En la mayoría de los casos es porque hay visitas por marcar como finalizadas.
Investigadores/as que, cada dos semanas, quieren recibir los datos para ir analizándolos.
Fin del estudio
Por fin llega el día esperado, el momento en el que nos piden la descarga final de los datos. Con esta noticia, accedemos a OpenClinica, descargamos los datos y por lo general, los mandamos a la plataforma de Bioestadística del IIS La Fe para su análisis.
Aunque para el Área de Informática, este es el final, lo cierto es que este es el principio para proporcionar evidencia científica para encontrar nuevas formas de mejorar tratamientos y mejorar la vida de muchos pacientes que confían en la ciencia e investigación. #SinCienciaNoHayFuturo.
Javier Ripoll Esteve
Coordinador Área de Informática IIS La Fe
Blog-> www.javierripoll.es