UNIDAD 5 Captura y gestión de datos - campuscec.es · La dificultad de disponer y manipular datos...

Unidad 5. Captura y gestión de datos

1

UNIDAD 5 Captura y gestión de datos Alberto Cobos Doctor en Medicina; MSc Estadística Aplicada; Universidad de Barcelona Departamento de Salud Pública - Sección Bioestadística. En esta unidad del curso de Monitorización de ensayos clínicos se explican los procesos de captura y gestión de datos que se llevan a cabo en el ámbito de la investigación clínica. La finalidad última de estos procesos es la de poder disponer de datos completos y exactos, para llevar a cabo posteriormente el análisis estadístico de los mismos y obtener los resultados del ensayo clínico. Para ello, es necesario que estos datos estén disponibles en un soporte informático y que estén dispuestos en una estructura que permita su análisis. Mientras no se indique explícitamente lo contrario, en esta unidad supondremos que los datos del ensayo se han registrado en un CRD de papel, por lo que la primera necesidad será la de trasladarlos a un soporte informático. La dificultad de disponer y manipular datos en un soporte informático, crece con el volumen de datos y la complejidad de éstos. Si el número de datos es muy limitado y la complejidad es baja, bastará utilizar una hoja de cálculo (p.e., MS Excel). Sin embargo, cuando el volumen de datos es considerable y su complejidad elevada, cualquier operación que deba realizarse con los mismos adquiere notable dificultad. Por ello, es necesario definir explícitamente los procesos que necesitaremos realizar, y utilizar herramientas adecuadas a dichas necesidades. En esta unidad presentaremos los procesos que deben llevarse a cabo, y las herramientas que pueden utilizarse para ello. Podéis consultar el material desde esta página Web del Colegio Oficial de Médicos de Barcelona. También podéis descargarlo en vuestro ordenador y consultarlo sin necesidad de seguir conectados a Internet. Os recomendamos esta última opción.


2

1. Datos y bases de datos (BD) Una base de datos (BD) es una colección organizada de datos. Los sistemas de gestión de bases de datos, a los que frecuentemente se alude mediante las siglas DBMS (del inglés DataBase Management Systems), son aplicaciones informáticas especialmente diseñadas para crear y gestionar bases BDs. Aunque existen otros tipos de DBMS, la mayoría de DBMS están basados en un modelo de representación de datos llamado relacional, por lo que se conocen genéricamente como RDBMS (del inglés Relational DBMS). Hay muchos RDBMS disponibles en el mercado. Entre los más conocidos, cabe citar MS Access, MS SQL Server, Oracle, y dBASE. Algunos RDBMS son de uso libre, como SQLite, PostreSQL o MySQL. En un RDBMS, los datos se estructuran en una serie de tablas. Las tablas son disposiciones de datos ordenados en filas o registros (records) y columnas o campos (fields). Los campos de una tabla pueden ser de distintos tipos. Aunque las tipologías de campo pueden variar en distintos RDBMS, la mayoría distingue al menos los siguientes tipos de campo: numero entero (integer), número decimal (decimal or float), fecha (date), y cadena de caracteres (character or string). Por ejemplo, el cuadro 1 muestra una tabla de datos demográficos y antropométricos. En dicha tabla, aparecen 7 campos, denominados Centro, Paciente, Fnac, Sexo, Peso, y Talla. Estos campos son de tipo número entero (Centro, Paciente, Visita, Sexo y Talla), número decimal (Peso) o fecha (Fnac, destinado a registrar la fecha de nacimiento). Cada una de las filas de esta tabla representa un paciente, que queda identificado por los campo Centro y Paciente. Los campos que se utilizan para identificar a quién pertenece la información de un registro se denominan claves, o campos clave. Cabe notar que el sexo se ha representado mediante números, utilizando alguna regla o diccionario de codificación (como 1 = “hombre”, y 2= “mujer”). Lo mismo sucede con el centro, (1 = “Hospital A”, 2 = “Hospital B”, etc.). Cuadro 1. Ejemplo de tabla de datos demográficos y antropométricos

Centro Paciente FNac Sexo Peso Talla 1 1 21/02/1963 1 78,5 180 1 2 13/02/1980 2 65,0 174 1 3 01/03/1958 2 72,7 170 2 1 06/02/1975 2 82,3 178 2 2 13/02/1967 2 65,7 174 … … … … … …

Una BD no es más que un conjunto de tablas, que se reconocen mediante un nombre. Conviene que dicho nombre sea indicativo de los datos que contendrá


3

la tabla (por ejemplo, podríamos llamar DEMO a la tabla que contendrá los datos demográficos). La primera tarea del gestor de datos es la de decidir como estructurar los datos de un ensayo clínico. Para ello, tendrá que definir las tablas que constituirán la BD del estudio: a cada una de estas tablas tendrá que asignarle un nombre y definir los campos que contiene. 2. Estructura de la BD Aunque no hay una única forma de estructurar un conjunto de datos, es bastante habitual hacerlo de modo que las distintas tablas de la BD alojen datos temáticamente relacionados. Así, es frecuente que las distintas secciones del CRD, como datos demográficos, antecedentes, signos vitales, medicaciones concomitantes, o acontecimientos adversos, se estructuren en una serie de tablas correspondientes a cada una de ellas. El cuadro 2 muestra la lista de las tablas de un estudio hipotético, y los cuadros 3 y 4 ilustran el contenido que podrían tener dos de ellas. Cuadro 2. Lista de tablas de la base de datos de un estudio hipotético

Nombre Descripción Tipo CRISEL Criterios de selección Un registro por paciente DEMO Datos demográficos y antropométricos Un registro por paciente ENFCO Enfermedades concomitantes Número variable de registros SIGVIT Signos vitales Un registro por paciente y visita MEDCO Medicaciones concomitantes Número variable de registros AA Acontecimientos adversos Número variable de registros FINEST Fin de estudio Un registro por paciente

Cuadro 3. Contenido de la tabla ENFCO. Los campos Centro y Paciente son numéricos (enteros), Enf es una cadena de carácteres, y FDiag (la fecha del diagnóstico) es de tipo fecha.

Centro Paciente Enf FDiag 1 1 Diabetes 03-05-2000 1 1 Hipertensión arterial 03-05-2000 1 3 Anemia drepanocítica 17-04-1988 1 4 Pneumotórax 22-11-1999 … … … …

Cuadro 4. Contenido de la tabla SIGVIT. Todos los campos se han definido como (números) enteros.

Centro Paciente Visita Pulso PAS PAD 1 1 1 77 130 75 1 1 2 81 125 70


4

Centro Paciente Visita Pulso PAS PAD 1 1 3 79 135 80 1 1 4 80 130 80 1 1 5 81 135 75 1 2 1 73 145 90 1 2 2 77 140 85 … … … … … …

Nótese que la tabla del cuadro 1 (que bien podría ser la tabla DEMO de este estudio hipotético) tendrá un registro por cada paciente. Sin embargo, la tabla SIGVIT (cuadro 4) tendrá un registro por paciente y visita (suponiendo que los signos vitales se registran en cada visita); y la tabla ENFCO (cuadro 3), tendrá un número variable de registros por paciente: el paciente 1 del centro 12, tiene dos enfermedades, mientras que el paciente 3 tiene una sola. 2.1. Documentación de la estructura de la BD El diseño de la estructura de la BD debe documentarse. Aunque la forma de documentar la BD dependerá del RDBMS que utilicemos, el cuadro 5 muestra un posible forma de documentación básica de una BD. Nótese que se proporciona la lista de los campos que incluye cada tabla, así como ciertas características mínimas de cada campo, como son la descripción de su contenido, el tipo de campo y, en el caso de variables codificadas, el nombre del diccionario de codificación (cuyo contenido se documenta en el cuadro 6). La definición del tipo de campo depende de las opciones disponibles en cada RDBMS, pero casi todos los RDBMS distinguen al menos cuatro tipos de campo: números enteros, números decimales, fechas y cadenas de caracteres. La denominación de estos tipos puede variar entre distintos RDBMS (por ejemplo, los números decimales sulen denominarse mediante términos como REAL, FLOAT, DOUBLE, o DECIMAL; las cadenas de caracteres mediante términos como CHAR, VARCHAR o STRING). En nuestro ejemplo, hemos utilizado los términos INTeger, REAL, DATE y STRING. En los campos de tipo INT, se indica el número máximo de dígitos. Así, si el campo Paciente se define como INT 3, significa que podremos introducir números del 1 al 999, pero no será posible escribir un número de más de tres dígitos (como por ejemplo 1000). En los de tipo REAL (número decimal), se indica el número máximo de caracteres (incluyendo el separador decimal), y el número de decimales. Así, REAL 5.1 en el campo Peso, significa que podremos poner un solo decimal, y un total de cinco caracteres contando con el punto (o la coma) decimal. Por tanto, será posible escribir un peso de 105,8 Kg, pero no será posible entrar valores como 95,55 ó 1015,3. Los campos codificados como el centro, los criterios de inclusión, el sexo, o la visita, requieren un diccionario de codificación que se identifica con un nombre. De este modo se puede documentar aparte el contenido de estos diccionarios, como se ha hecho en el cuadro 6.


5

Cuadro 5. Estructura de la BD de un estudio hipotético

Tabla Campo Descripción Tipo Dicionario CRITSEL Centro Código del centro INT 3 centros CRITSEL Paciente Número de paciente INT 3 - CRITSEL CI1 Criterio de inclusion nº 1 INT 1 sino CRITSEL CI2 Criterio de inclusion nº 2 INT 1 sino CRITSEL CI3 Criterio de inclusion nº 3 INT 1 sino

… … … … DEMO Centro Código del centro INT 3 centros DEMO Paciente Número de paciente INT 3 - DEMO FNac Fecha de nacimiento (dd-mm-aaaa) DATE - DEMO Sexo Sexo INT 1 - DEMO Peso Peso (Kg) REAL 5.1 - DEMO Talla Talla (cm) INT 3 -

… … … … … ENFCO Centro Código del centro INT 3 centros ENFCO Paciente Número de paciente INT 3 - ENFCO Enf Enfermedad CHAR 80 - ENFCO FDiag Fecha del diagnóstico (dd-mm-aaaa) DATE - SIGVIT Centro Código del centro INT 3 centros SIGVIT Paciente Número de paciente INT 3 - SIGVIT Visita Número de visita INT 2 visitas SIGVIT Pulso Pulso arterial (lpm) INT 3 - SIGVIT PAS Presión arterial sistólica (mm Hg) INT 3 - SIGVIT PAD Presión arterial diastólica (mm Hg) INT 3 -

AA … … … … … … … … …

FINEST … … … … … … … … …

Cuadro 6. Diccionarios de codificación

Diccionario Valor Descriptor sino 1 Sí sino 2 No

centros 1 Hospital A centros 2 Hospital B centros … … centros 10 Hospital J

sexo 1 Hombre sexo 2 Mujer

visitas 1 Visita de inclusión visitas 2 Visita de seguimiento (1 mes) visitas … … visitas 5 Visita de seguimiento (12 meses)


6

Dependiendo del RDBMS, pueden definirse otras características de cada campo, como las siguientes: • Clave interna: si se trata de un campo que es una clave de la tabla a la que

pertenece dicho campo • Clave externa: si se trata de un campo que es una clave de otra(s) tabla(s) • Requerido: si es un campo requerido, es decir, que no podrá dejarse en

blanco • Valor por defecto: si al crearse un nuevo registro en la tabla, debe adoptar

por defecto el valor indicado (por ejemplo, si todos los registros de la tabla DEMO deben tener un 1 en el campo Visita, a este campo se le podría asignar el valor por defecto 1, de modo que no sería necesario entrar este valor para cada nuevo registro que se añada a la tabla.

• Calculado: si se trata de un campo que no está presente en el CRD, sino que se calcula a partir de otros mediante cierta fórmula. Por ejemplo, en la tabla DEMO, se podría haber añadido el Índice de Masa Corporal (IMC), calculado a partir del peso y la talla, mediante la fórmula IMC = Peso (kg) / [ Talla (cm) / 100 ]2.

La documentación de la BD debe permitir establecer la correspondencia entre los campos de las tablas de la BD y los ítems del CRD. Aunque esto puede conseguirse de distintas maneras, es muy habitual hacerlo mediante un CRD anotado. Un CRD anotado es un CRD (en blanco), en el que se ha escrito, al lado de cada item, el campo (y la tabla) de la BD en que se introducirá dicho item. A veces se anotan también algunas características del campo, como el nombre del diccionario asociado (si se trata de un campo codificado), el tipo de campo, si se trata de un campo calculado a partir de otros mediante cierta fórmula, etc. 2.2. Creación de la BD Una vez decidida la estructura de la BD, habrá que crearla. Nuevamente, la forma de hacerlo depende del RDBMS utilizado, pero en muchos casos se hace mediante un lenguaje informático denominado SQL, que implementan los RBDMS. Mediante este lenguaje, pueden escribirse y ejecutarse sentencias como las siguientes: create database MI_BD; create table DEMO ( Centro INT(3), Paciente INT(3), Fnac DATE(),

Sexo INT(1), Peso FLOAT(5.1), Talla INT(3) ); Al ejecutar la primera sentencia, crearíamos una nueva BD denominada MI_BD. Al ejecutar la segunda sentencia, crearíamos una nueva tabla denominada DEMO, que tendría los campos definidos en el cuadro 5 para esta tabla. Para facilitar estas tareas, algunos RDBMS, como MS Access®, disponen de una interfaz gráfica de usuario que permiten definir los campos de las tablas sin


7

necesidad de programar las sentencias SQL. El cuadro 7 muestra la interfaz de MS Access, que se ha utilizado para crear la tabla DEMO. Los campos Centro y Paciente se han definido como claves internas (símbolo de llave a la izquierda del nombre del campo). En la parte inferior se muestran las propiedades que definidas para el campo resaltado (Peso). Cuadro 7. Creación de la tabla DEMO mediante MS Access®

3. Proceso de entrada de datos (ED) Una vez definida la estructura de la BD, es necesario disponer de un medio para introducir los datos. Para ello es necesario construir formularios que faciliten la tarea de entrada de datos. Algunos RDBMS, como MS Access®, disponen de herramientas para construir formularios de un modo más o menos sencillo. El cuadro 8 muestra el aspecto de un formulario básico para la tabla DEMO, construido mediante MS Access. Los campos centro, visita y sexo, tienen listas desplegables para escoger el valor adecuado. Los restantes campos tienen cajas de texto. Para minimizar los errores de entrada de datos, es habitual realizar una doble entrada de datos, idealmente llevada a cabo por operadores distintos (si las dos entradas las realiza el mismo operador, es probable que ciertos errores cometidos en la primera entrada se reproduzcan de forma idéntica en la segunda).


8

Hay diversas formas de organizar la doble entrada. Una de ellas, consiste en realizar las dos entradas de forma independiente, posteriormente compararlas y resolver las discepancias consultando de nuevo el valor que consta en el CRD. Una forma alternativa consiste en que, al realizar la segunda entrada, se compara con la primera entrada de forma automática, y si no hay coincidencia de datos entre ambas, salta una alarma para que el operador que realiza la segunda entrada verifique de nuevo el valor en el CRD e introduzca el dato correcto. Naturalmente, esto exige que el sistema utilizado sea capaz de tal automatismo. Cuadro 8. Formulario de entrada de datos para la tabla DEMO confeccionado con MS Access®

La doble entrada es un método muy adecuado para minimizar errores de entrada de datos numéricos o de fecha, pero es muy poco eficiente para datos de tipo texto. La razón es que con frecuencia se producen diferencias poco o nada relevantes entre ambas entradas, que resultarán a pesar de todo en una discrepancia. Algunos ejemplos de ello son:

• Mayúsculas y minúesculas (“vómitos” y “Vómitos”) • Los acentos (“vómitos” y “vomitos”) • Los espacios en blanco (“vómitos” y “vómitos ”) • Los números romanos (“Diabetes tipo 2” y “Diabetes tipo II”)

Por esta razón, es frecuente que no se realice doble entrada de los textos, y en su lugar, se opte por una verificación posterior (“proof reading”) de los textos entrados en una única ocasión. Dicha verificación consiste en preparar un listado de estos textos, convenientemente identificados, y verificar que son correctos por comparación con el texto escrito en el CRD. Es muy aconsejable que la entrada de datos se realice bajo un procedimiento normalizado de trabajo (PNT) que constituirá una guía para el personal de entrada de datos y que indica en cada caso cómo hay que proceder ante determinadas incidencias, como valores ilegibles, datos imposibles, etc.


9

Adicionalmente, es recomendable preparar un manual de instrucciones específicas para la entrada de datos de cada EC, que instruya acerca de cómo proceder con los aspectos específicos del ensayo clínico no cubiertos en el PNT así como ante las incidencias o situaciones imprevistas. Una interesante alternativa a la entrada de datos manual, es la utilización de aplicaciones informáticas que permiten leer automáticamente los datos escritos en el CRD, a partir de una imagen del mismo capturada mediante un scanner y un software de OCR (Optical Character Recognition), e incorporarlos a la BD. Aunque este tipo de herramientas es eficiente para interpretar casillas de verificación (checkboxes), siguen siendo poco fiables para interpretar la escritura manual, ya se trate de números o, sobre todo, de textos. Por ello, en caso de que se utilicen estas herramientas, es imprescindible configurarlas de manera que, antes de incorporar el dato interpretado por el OCR a la BD, sea necesaria una verificación por parte de un operador. Con independencia de la modalidad que se haya utilizado para entrar los datos, es recomendable someter el proceso a un control de calidad. Para ello, se selecciona una muestra aleatoria de pacientes (o de datos), se obtiene un listado de los datos seleccionados a partir de la BD, y se realiza una verificación comparándolos con el CRD. En caso de que la tasa de errores sea nula o muy pequeña, se da por bueno el proceso. Sin embargo, si la tasa de errores supera ciertos límites tolerables (que pueden depender del tipo de ensayo clínico y del tipo de datos), se extiende la verificación al resto de pacientes/datos. 4. Plan de validación de los datos La doble entrada de datos permite minimizar los errores de transcripción de datos desde el CRD a la BD. Sin embargo, en muchas ocasiones el CRD contiene carencias de información (datos ausentes), datos sospechosos de ser erróneos (p.ej., fecha de visita en domingo, peso de 142 Kg), datos claramente erróneos (p.ej., valores incompatibles con la vida, como potasio plasmático de 42 mEq/L), o datos inconsistentes (diabetes tipo 1 sin tratamiento con insulina). Por ello, tras finalizar la doble entrada de datos y resolver las posibles discrepancias entre ambas entradas, es necesario verificar que los datos no contienen errores o inconsistencias provenientes del CRD. En el cuadro 9 se muestran distintos tipos de verificaciónes que a menudo se realizan sobre las bases de datos de los ensayos clínicios. Nótese que los dos primeros tipos (detección de missings y reglas de rango) son univariantes, es decir, se refieren a una sola variable; mientras que los tres siguientes son multivariantes, es decir, involucran a más de una variable.


10

Cuadro 9. Tipos de verificaciones frecuentemente incluídas en el PVD

Tipo de verificación Ejemplo Detección de valores ausentes (missing) La edad no está ausente Reglas de rango La edad está comprendida entre 18 y 65 años Reglas de orden La fecha de la visita 2 es posterior a la de la visita

1 Reglas de incremento El cambio de peso en dos visitas consecutivas es

inferior a un 5% Reglas lógicas Si un acontecimiento adverso se considera

resuelto, entonces debe facilitarse la fecha de finalización del mismo

Dado que el número de verificaciones que podemos llevar a cabo es potencialmente muy elevado, conviene establecer un plan de validación de datos (PVD), es decir, una lista explícita de dichas verificaciones. 4.1. Confección de un PVD Para elaborar un PVD, es necesario revisar detenidamente el CRD, y pensar en los posibles errores de cumplimentación. Esta tarea no es en absoluto sencilla y requiere considerable experiencia en gestión de datos, además de conocimientos médicos sobre la indicación y tratamientos del ensayo. Como estos dos tipos de conocimiento se combinan en una sola persona, es recomendable que el PVD se realice de manera colaborativa entre un gestor de datos y un experto en la indicación dels ensayo. Un error frecuente, al elaborar un PVD, es pretender que éste sea absolutamente exhaustivo, de forma que permita identificar cualquier posible error en los datos. Esta pretensión es ingenua por varias razones. En primer lugar, porque el número de posibles errores aumenta exponencialmente con el número de variables registradas en el CRD, y para CRDs medianamente complejos, puede ser muy elevado. En segundo lugar, porque es muy difícil anticipar algunos errores y, por mucho que lo intentemos, la realidad siempre acabará sorprendiéndonos con situaciones que no supimos prever. Por último, porque redactar reglas lógicas que detecten posibles inconsistencias entre diversas variables es más difícil de lo que pudiera parecer a primera vista. Para tomar conciencia de ésta dificultad, plantéese el alumno todas las posibles combinaciones de resultados de las siguientes variables, y decida cuáles son inconsistentes y cuáles no: sexo (hombre / mujer / missing), anticoncepción fiable (sí / no / missing), y menopausia (si / no / missing). Por lo demás, no todos los datos de un CRD son igualmente importantes, y es muy aconsejable concentrar la atención en los que sí lo son. Por lo tanto, a la hora de diseñar el PVD, conviene identificar primero los datos críticos y priorizar (si no limitarse a) la verificación de éstos.


11

En general, los datos más importantes de un ensayo clínico son:

• La variable principal, o las variables necesarias para evaluar la variable principal (cuando ésta es una variable derivada).

• Los datos de los que dependa la inclusión de un paciente en cada uno de los conjuntos de análisis previstos (en la sección de análisis estadístico del protocolo). Típicamente, éstos será los criterios de selección y los datos de cumplimineto del tratamiento del ensayo, pero pueden ser necesarios otros datos (como por ejemplo la administración de tratamientos concomitantes prohibidos, o el valor basal de la variable principal si lo hay).

• Los datos de seguridad: acontecimientos adversos, y signos vitales. • Las variables necesarias para la evaluación de objetivos secundarios.

4.2. Documentación del PVD Parar redactar el PVD, es recomendable estructurarlo según las tablas de la BD (o lo que suele ser lo mismo, las secciones del CRD). Para cada una de estas tablas, se especificará una lista de verificaciones a realizar (a veces denominadas reglas de verificación). Cada una de ellas debe identificarse con un código único, e idealmente debería especificarse al menos dos cosas: la regla lógica que se verificará, y la forma en que se describirá el problema detectado mediante dicha regla. La cuadro 10 muestra una posible forma de documentar las reglas de verificación para algunas de las tablas de ejemplo presentadas anterioremente. Nótese que las reglas se expresan como una condición, y una evaluación de dicha condición. Si la evaluación es como se indica, se emitirá una query, con el texto indicado. Cuadro 10. Ejemplo de documentación de las reglas de un PVD Id regla Ejemplo

Demo01 Condición 18 ≤ Edad ≤ 65 Evaluación Se emitirá query si la condición es FALSA Texto query La edad no está comprendida en el rango previsto por el protocolo

(18 a 65). Por favor confirme que el valor es correcto. Demo02 Condición Sexo = missing

Evaluación Se emitirá query si la condición es CIERTA Texto query No se indica el sexo del paciente. Por favor facilite este dato.

… … Sigvit01 Condición PAS > PAD

Evaluación Se emitirá query si la condición es FALSA Texto query PAS no es mayor que PAD. Por favor revise estos datos.

… …


12

Una vez diseñado el PVD, (y revisado y aprobado por quien proceda), se procederá a programar las reglas mediante algún lenguaje que permita realizar estas verificaciones de manera automática sobre la BD. Una vez programadas las reglas, es necesario verificar que se han programado correctamente (¡también es posible cometer errores cuando se programa!), por lo que los programas informáticos que implementan las reglas tendrán que validarse antes de ser utilizados. Aunque la mayoría de las reglas de validación pueden implementarse mediante reglas lógicas, éste no siempre el caso. Por ejemplo, a pesar de que las enfermedades y los tratamientos concomitantes se codifiquen mediante diccionarios estándar (como ICD9 o MedDRA y WHODRUG), no es planteable en la práctica programar una regla para verificar la consistencia entre ambos tipos de información. En tales casos, es necesario realizar una revisión visual de estos datos a partir de listados elaborados a tal efecto. Esta revisión debe realizarla una persona con los conocimientos médicos necesarios para poder evaluar posibles inconsistencias (como por ejemplo, diabetes tipo I sin insulina). Esta necesidad complica ciertamente la ejecución del plan de validación. 4.3. Programación del PVD Una de las grandes ventajas de utilizar un RDBMS para la gestión de los datos de un ensayo clínico, es la capacidad de manipulación de datos que ofrecen. Prácticamente todos los RDBMS, implementan el llamado lenguaje SQL (siglas del término inglés Structured Query Languaje), del que ya hemos hablado en relación con la creación de la BD. Este lenguaje permite realizar consultas (queries) a la BD. Ilustraremos la utilidad de este lenguaje mediante algunos ejemplos. Supongamos que deseamos verificar los valores de peso que se han introducido en la tabla SIGVIT. En particular, queremos detectar si hay valores poco creíbles, por ser demasiado elevados o demasiado bajos. La siguiente consulta SQL permitiría calcular el máximo y el mínimo de los valores del campo Peso: select min(Peso), max(Peso) from DEMO y el resultado de ejecutar esta consulta sobre la BD del estudio hipotético, sería algo parecido la cuadro 11.


13

Cuadro 11. Resultado de la consulta SQL para calcular valores extremos del peso

MínDePeso MáxDePeso 52 172

Como ha salido un máximo de 172 Kg, y este valor es sospechosamente elevado, queremos identificar el paciente que tiene este valor de peso. Además, queremos saber si hay otros valores de peso, por debajo del máximo, que también son sospechosos de ser erróneos. La siguiente consulta SQL permitiría verificar ambas cosas (se incluye también el campo talla): select Centro, Paciente, Peso, Talla from DEMO where Peso > 100 El resultado de esta consulta podría ser como se muestra en la cuadro 12. Hay un único paciente con peso > 100, y es el paciente 3 del centro 4. Además, el valor de talla es sospechosamente bajo, por lo que es posible que se haya cometido un error, entrando el peso en el campo de la talla y viceversa. Cuadro 12. Resultado de la consulta SQL para identificar casos con peso > 100

Centro Paciente Peso Talla 4 3 172 70

También pueden realizarse consultas SQL para detectar valores ausentes (missing), o para comparar valores de distintos campos de una tabla (por ejemplo, fecha inicio de un acontecimiento adverso > fecha de su finalización), o consultas realmente complejas que involucren campos de distintas tablas. Como curiosidad, el término queries utilizado en el entorno de los ensayos clínicos para referirse a los problemas detectados en los datos, tiene su origen en las consultas (queries) que se realizan sobre la BD mediante el lenguaje SQL (Structured Query Languaje). Por limitaciones de extensión, no podemos detenernos a explicar el lenguaje SQL en toda su extensión. Sin embargo, sí que consideramos importante advertir al alumno que, si pretende realizar tareas de gestión de datos, aprender dicho lenguaje es una de las mejores inversiones que puede realizar. Existen muchos libros y tutoriales de SQL. En la sección de Enlaces de Interés, al final de esta unidad, recomendamos uno que consideramos apropiado para iniciar el estudio de este lenguaje.


14

5. Gestión de “queries” Una vez validado el PVD programado, se ejecutará sobre la BD, obteniendo como resultado el conjunto de problemas detectados en los datos. Para cada uno de ellos, se emitirá una solicitud de aclaración (o query) al investigador responsable del paciente, quien facilitará la aclaración oportuna y, finalmente, ésta se incorporará a la BD. Para facilitar este proceso, conviene que las aclaraciones se realicen en un formato que permita al investigador las aclaraciones oportunas en el mismo documento. Estos documentos se conocen a veces como formularios de queries. Los formularios de queries deben elaborarse de manera que queden ordenados por centro y paciente, y deben incluir los identificadores necesarios: estudio, centro, paciente, visita, sección (o página) e item del CRD. Además del texto que describe el problema detectado en cada caso, es imprescindible reservar un espacio para que el investigador pueda responder la aclaración oportuna a cada problema. Conviene imprimir dos copias de los formularios de queries: una de ellas quedará en posesión del investigador (quien la integrará en su archivo) y la otra será devuelta al gestor de datos (quien la adjuntará al CRD del paciente). Con esta copia el gestor de datos procederá a actualizar la BD, manteniendo un registro de los cambios efectuados (audit trail), de forma que todo cambio sea trazable y que esté refrendado por la aclaración facilitada por el investigador en un formulario de queries. 6. Codificación de textos Ciertos datos registrados en el CRD son textos libres. Notables ejemplos, presentes en todo ensayo clínico, son las enfermedades concomitantes, los tratamientos previos o concomitantes, y los acontecimientos adversos. Los datos de tipo texto requieren de un proceso de codificación para que el resultado de su análisis sea práctico. Considérese los siguientes textos registrados como acontecimientos adversos en los CRD de siete pacientes:

• Dolor de cabeza • Dolor cabeza • Cefalea • Cefalea parieto-temporal • Cefalea ocasional • Cefalea intensa • Cefalalgia

Todos estos términos describen esencialmente el mismo tipo acontecimiento adverso (aunque algunos incluyen detalles sobre la localización o la intensidad). Al analizar los acontecimientos adversos, posiblemente mediante una tabla de frecuencias, el resultado será una tabla muy larga, en la que aparecerá cada uno de estos términos, con una frecuencia muy baja (quizás


15

unitaria). Sin embargo, para interpretar los resultados, sería mucho más conveniente que en dicha tabla apareciera el término “Cefalea”, con una frecuencia de 7 pacientes. Éste es precisamente el propósito de la codificación de textos: reunir todos los textos que pueden considerarse sinónimos, bajo un único descriptor preferido. El problema de la diversidad de textos que pueden referirse a una misma cosa, que hemos ilustrado para los acontecimientos adversos, ocurre también con los tratamientos (p.ej., considérense los textos “Aspirina”, “Ácido acetilsalicílico”, “Aspirina comprimidos”), con las enfermedades concomitantes (“Hipertensión arterial”, “HTA”, “Hypertensión esencial”, “HTA idiopática”) y, en general, con cualquier campo abierto que haya en el CRD. Por esta razón, los campos de texto deben codificarse antes de proceder al análisis estadístico de los datos. La codificación de textos puede realizarse ad-hoc o mediante diccionarios estándar, pero si se dispone de diccionarios estándar, es aconsejable utilizarlos. Los diccionarios estándar son colecciones terminológicas más o menos exhaustivas y estructuradas, a menudo de manera jerárquica. Algunos diccionarios ampliamente utilizados son los siguientes: • ICD9, para la codificación de enfermedades. • ATC, para la codificación de medicamentos. • MedDRA, para la codificación de acontecimientos adversos. El proceso de codificación consiste en asignar el código más apropiado del diccionario que hayamos decidido utilizar, al texto que se ha escrito en el CRD (y posteriormente se ha trasladado a la BD). La labor de codificar mediante diccionarios estándar requiere de conocimientos extensos de terminología médica, pero también de conocimiento del diccionario estándar utilizado, para seleccionar el código más adecuado a un término escrito por el investigador en el CRD. La codificación ad-hoc, se utilizada cuando no se dispone de diccionarios estándar. Esto sucede típicamente en preguntas referentes al motivo por el que no se realizó una prueba (como un cultivo de esputo), o una visita de seguimiento, o cualquier procedimiento del ensayo. En tales casos, lo más razonable es revisar todos los textos incluidos en el campo de texto, y decidir arbitrariamente los términos preferidos para describir estos textos. Así, descripciones como “el paciente no expectora”, “esputo mínimo”, o “muestra de esputo insuficiente”, podrían codificarse todos ellos mediante el término preferido “ausencia de muestra o muestra insuficiente”. 7. Cierre de la BD Cuando la ejecución del PVD no produce resultados (no detecta problemas en la BD), o cuando los que produce se consideran menores o irresolubles, se da por terminado el proceso de revisión de datos y se procede a proteger contra escritura la BD, para impedir cualquier cambio o modificación ulterior. Esta acción se denomina a veces cerrar (lock) o congelar (freeze) la BD.


16

De esta forma, la BD se declara cerrada de mutuo acuerdo entre el gestor de datos y el responsable del proyecto. A partir de ese momento, la BD podrá accederse para lectura, pero no podrá modificarse. Es aconsejable documentar el cierre de la BD y la conformidad de los responsables, explicitando la composición de la BD (archivos) y su ubicación (directorios). A partir de este momento la BD puede utilizarse para el análisis estadístico, pero siempre sin alterar su contenido. Puede ocurrir que, tras el cierre de la BD, se detecte algún problema en los datos que pasó inadvertido. Ello puede motivar la reapertura de la BD para enmendar el problema. En los ensayos enmascarados, si esto ocurre antes de desvelar el código de tratamiento, basta la aprobación de los responsables del ensayo clínico para proceder a desproteger la BD, realizar los cambios necesarios, y proteger de nuevo la BD. Si, por el contrario, surge la necesidad de desproteger la BD tras desvelar el ciego, el procedimiento es similar pero los motivos de la reapertura deben documentarse de forma clara y precisa, con justificación especifica de todos y cada uno de los cambios efectuados. 8. Herramientas específicas para la gestión de datos de ensayos clínicos Aunque la BD de un ensayo clínico se puede organizar mediante RDBMS genéricos como los que hemos mencionado anteriormente (véase la sección 2), existen herramientas específicamente diseñadas para la gestión de datos de ensayos clínicos, como Oracle Clinical, y OpenClinica, que facilitan muchas de las tareas a realizar durante la gestión de datos de un ensayo clínico. Estas soluciones incorporan toda la funcionalidad necesaria a través de interfaces gráficas, de odo que los usuarios no necesiten tener habilidades de programación. Entre las funcionalidades podemos citar las siguientes:

• Diseño de la BD • Diseño de las pantallas de entrada de datos • Comparación de doble entrada y resolución de discrepancias • Facilidades para la revisión de datos y definición de reglas de validación • Facilidades para la codificación de textos • Audit Trail o registro de cambios realizados en los datos • Acceso a través de internet (eCRD) • Definición de roles de usuario (como datamanager, data entry, etc.) • Control de seguridad (acceso mediante contraseña)

Aunque posiblemente este tipo de soluciones son las óptimas para organizaciones de investigación clínica de gran tamaño, su utilización en


17

organizaciones de pequeño tamaño puede ser problemática, tanto por el coste de adquisición, como por la complejidad de implementación. 9. Clinical Data Interchange Standards Consortium (CDISC) El Clinical Data Interchange Standards Consortium (CDISC), es una organización global, abierta, multidisciplinaria y sin ánimo de lucro, que establece estándares para la captura, intercambio, envío y archivo de datos de investigación clínica. La misión principal de CDISC es desarrollar y mantener estándares de datos globales independientes de plataforma que permitan la interoperabilidad de systemas de información, para mejorar la investigación clínica y otras areas relacionadas con el cuidado de la salud. Entre los objetivos del CDISC podemos destacar los siguientes:

• Definir los estándares de intercambio de datos, sin limitación del proceso o de la aplicación implementada.

• Asegurar que los estándares son independientes de la plataforma y de la aplicación informática.

• Disminuir el tiempo del ciclo del programa de desarrollo de fármacos y su coste.

• Definir un modelo de datos estándar que se ajuste a los requisitos anteriores.

• Definir una nomenclatura estándar relacionada con la adquisición e intercambio electrónico de la información procedente de los ensayos clínicos.

Actualmente, la mayoría de las compañías farmacéuticas y de las CRO están realizando un esfuerzo importante en la creación o adaptación de sus CRD, bases de datos y metadatos, a este estándar común.


18

9.1 Captura Electrónica de Datos (CED) y su impacto sobre los procesos de gestión de datos La utilización de sistemas de captura electrónica de datos tiene un notable impacto en los procesos de gestión de datos. El cuadro 13 ilustra los diferentes tiempos en que estos procesos tienen lugar, cuando se trabaja con un CRD en papel o con un sistema de CED. Cuadro 13. Diferencias entre CRD en papel y CED

Cuando se utiliza un CRD en papel, la única tareas de gestión de datos que debe finalizarse antes de incluir al primer paciente es la preparación del propio CRD. Aunque no conviene rertasarlas demasiado, las tareas de definición de la estructura de la BD, creación de la BD y del sistema de grabación de datos, definición y programación del plan de validación (PV) de datos, pueden realizarse durante el reclutamiento. La grabación, la verificación de datos (ejecución del PV) y la gestión de queries, no podrán finalizarse hasta después de que haya finalizado el reclutamiento (y el seguimiento) de todos los pacientes. Sin embargo, cuando se untiliza un sistema de CED, la definición y la creación de la BD, el sistema de grabación (pantallas para entrada de datos o eCRD) y la definición y programación del plan de validación de datos, deben realizarse antes de la inclusión del primer paciente. Durante el reclutamiento (y seguimiento), se grabarán los datos, se ejecutarán las reglas de validación, y se generarán y resolverán las queries. En consecuencia, cuando finaliza el ensayo (última visita del último paciente), podrá procederse al cierre de la BD y al análisis estadístico. Por lo tanto, la utilización de un sistema de CED, tiene dos implicaciones fundamentales: la dilatación de la fase de planificación del ensayo, y el acortamiento del tiempo necesario para disponer de los resultados del análisis estadístico, desde la finalización del ensayo (última visita del último paciente).


19

Resumen En esta unidad se ha presentado los distintos procesos que típicamente se integran bajo el término gestión de datos de ensayos clínicos: el diseño y la creación de la BD, la preparación de un sistema para introducir los datos en la BD, la introducción de los datos, su revisión sistemática mediante el diseño, la programación y la ejecución de un PVD, la gestión de queries, la codificación de textos, y el cierre de la BD. Por último, se ha discutido el impacto que tienen los sistemas de CED en estos procesos.


20

Ejercicio 1 En un ensayo de disfunción eréctil, el CRD incluye la sección de datos demográficos que se muestra en la cuadro 14. El ensayo e lleva a cabo en 20 centros, y se pretende reclutar un total de 120 pacientes de forma competitiva, pero con un mínimo de 4 pacientes por centro. En cada centro, los pacientes se identifican mediante el número de orden de inclusión en el ensayo (1, 2, …). Cada paciente realiza 3 visitas: inclusión, al mes y a los 6 meses de la inclusión. 1. Diseñe la tabla de la BD que contendrá los datos de esta sección del CRD,

utilizando la plantilla que se muestra en la cuadro 15. 2. Anote esta sección del CRD para reflejar la correspondencia entre las

respuestas que se registran en el mismo, y los campos de la tabla de la BD. Cuadro 14. Sección de datos demográficos del CRD de un ensayo en disfunción eréctil

Cuadro 15. Plantilla para diseñar la tabla de demografía de la BD

Tabla Campo Descripción Tipo Dicionario Requerido

Visita 1


21

… Ejercicio 2 Confeccione y documente un plan de validación de datos para la tabla Demofrafía del ejercicio anterior. Utilice como plantilla la cuadro 10 de esta unidad. Para confeccionar el PVD, tenga en cuenta lo siguiente:

• El estudio ha de comenzar el 1 de enero de 2014, y está previsto que finalice (último paciente última visita, el 1 de enero de 2015.

• El protocolo indica que se han de inluir hombres entre 30 y 55 años


22

Enlaces de interés RDBMS genéricos SQLite. http://www.sqlite.org/ Tutorial de SQL. http://www.w3schools.com/sql/ Tutoriales de MS Access:

http://www.gcflearnfree.org/access http://www.baycongroup.com/access2007/index.html

Software específico para gestión de datos en investigación clínica Oracle Clinical. http://www.oracle.com/us/products/applications/health-sciences/e-clinical/clinical/index.html OpenClinica. https://www.openclinica.com/ Otros enlaces de interés Clinical Data Interchange Standards Consortium (CDISC). http://www.CDISC.org

http://www.sqlite.org/

http://www.w3schools.com/sql/

http://www.gcflearnfree.org/access

http://www.baycongroup.com/access2007/index.html

http://www.oracle.com/us/products/applications/health-sciences/e-clinical/clinical/index.html

http://www.oracle.com/us/products/applications/health-sciences/e-clinical/clinical/index.html

https://www.openclinica.com/

http://www.cdisc.org/

UNIDAD 5 Captura y gestión de datos - campuscec.es · La dificultad de disponer y manipular datos...

Documents

Transcript of UNIDAD 5 Captura y gestión de datos - campuscec.es · La dificultad de disponer y manipular datos...