En la semana pasada enviar, hemos discutido algunas de las próximas características de JMP clinico 4.1 que identifican registros nuevos y modificados cuando se actualizan los datos de ensayos clínicos. Estas herramientas pueden acelerar enormemente las revisiones clínicas, lo que permite al médico, estadístico o administrador de datos enfocarse exclusivamente en registros no revisados. Aquí discutimos los detalles de cómo JMP Clinical lo hace posible.
Comprender la discusión a continuación será de gran ayuda para garantizar que su experiencia de revisión clínica de JMP sea lo más eficiente y placentera posible. Incluso si la presentación parece un poco técnica, el equipo responsable de generar los conjuntos de datos SDTM o ADaM deberá agregar un solo paso de procesamiento (si aún no lo están realizando). De lo contrario, la mayoría de nosotros puede permanecer felizmente inconsciente de los pasos adicionales.
En resumen, se trata de la llaves .
Las llaves normalmente nos dan acceso a algo, ya sea una caja cerrada o una habitación. Cuando se discuten conjuntos de datos, las claves nos dan una idea de la singularidad de un registro o fila de conjuntos de datos. los CDISC SDTM Guía de implementación define los siguientes términos:
Llave natural es una o más variables cuyo contenido distingue de forma única cada registro (fila) en el conjunto de datos. Por ejemplo, cada fila del dominio de DM debe representar un tema diferente. Las claves naturales en este caso podrían ser Identificador de estudio (STUDYID) e Identificador único de sujeto (USUBJID). Clave sustituta es un identificador de variable única establecido artificialmente que identifica de forma única las filas. Esto podría incluir cualquiera de las variables xxSEQ. Por ejemplo, si el conjunto de datos de signos vitales contiene 200 registros, la variable VSSEQ podría numerarse del 1 al 200 para identificar de forma única las filas.Alternativamente, xxSEQ puede formar parte de una clave natural para que xxSEQ pueda contar de 1 a n yo , donde n yo es el número total de registros para un sujeto. Aquí las claves serían STUDYID, USUBJID y xxSEQ.
Entonces, ¿por qué es importante? Bueno, para examinar un registro (fila) en busca de diferencias entre dos instantáneas, debe haber una forma de vincular estas dos versiones del registro. Aquí es donde entran las llaves. De lo contrario, JMP Clinical no tiene forma de saber qué registros deben coincidir. Además, para guardar o acceder a las notas de un registro en particular, debe haber una forma de archivar la nota para que sea accesible más tarde cuando regrese al registro. De nuevo, aquí es donde entran las llaves.
Entonces, ¿cómo puede un usuario proporcionar a JMP Clinical las claves de todos los dominios de datos para un estudio? Esto es en realidad bastante trivial. Si alguna vez ha utilizado CONTENIDOS DE PROC, el encabezado de salida para un conjunto de datos contiene información diversa sobre el conjunto de datos. Uno de estos datos es "ORDENADO: SÍ / NO". Si el conjunto de datos se clasifica (es decir, SÍ), se proporciona información adicional en la salida de CONTENIDOS DE PROC después de la descripción de las variables del conjunto de datos. Por ejemplo, cuando uso PROC CONTENTS en el dominio DM para Nicardipine, obtengo la siguiente fila en la salida: "Ordenado por STUDYID USUBJID". Estos metadatos se almacenan en el conjunto de datos con formato SAS; Las variables utilizadas para la clasificación del conjunto de datos es lo que JMP Clinical utiliza para definir las claves para un estudio.
Entonces, ¿cómo se pueden guardar estos valores en los metadatos de un conjunto de datos? Prueba cualquiera
PROC SORT data = DM out = out.DM;
por STUDYID USUBJID;
correr;
o
data out.DM (ordenado por = STUDYID USUBJID);
establecer DM;
correr;
Si los dominios de estudio no tienen los metadatos SORTEDBY asociados con los conjuntos de datos, JMP Clinical intenta obtener las claves basándose en las sugerencias proporcionadas en la Guía de implementación de SDTM. Sin embargo, las claves generadas pueden no ser el conjunto óptimo para un dominio dado.
Entonces, ¿eso sucede si las claves suministradas no definen los registros (filas) de forma única? Cuando el estudio se agrega por primera vez a JMP Clinical, se proporciona un informe duplicado para cada dominio afectado que detalla los registros (filas) que no se pueden determinar de forma única. Estos registros (filas) aún se etiquetarán como nuevos en JMP Clinical. Sin embargo, cualquier nota de nivel de registro que sea generada por el sistema o el usuario se asociaría con dos o más registros. Esto puede estar bien si hay pocos duplicados con los que lidiar, pero cualquier duplicado debe revisarse como posibles errores de datos (datos que se ingresaron por error dos veces). Cuando se actualizan los datos del estudio y persisten las redundancias, JMP Clinical no tiene forma de igualar estos registros. En otras palabras, no puede evaluar si se hicieron cambios a los registros o no. Nuevamente, si hay pocos duplicados, estos registros (filas) pueden revisarse en múltiples instantáneas para verificar su corrección.
Algunos otros consejos importantes:
(1) Cuando agregue un estudio por primera vez, examine el informe duplicado. Identifique las claves para cada dominio y asegúrese de que todos los duplicados se mantengan al mínimo (idealmente, no presente). De lo contrario, la funcionalidad de revisión no será tan útil como podría ser en última instancia. Por ejemplo, si el dominio de signos vitales (VS) fue clasificado solo por STUDYID y USUBJID utilizando el código PROC SORT anterior, todos los registros del sujeto se considerarán duplicados. Esto incluiría múltiples pruebas (como frecuencia cardíaca, presión arterial sistólica y diastólica) o registros que pertenecen a diferentes visitas.
(2) Si realiza (1) y existen numerosas duplicaciones para todos los dominios, elimine el estudio de JMP Clinical y vuelva a agregar una vez que se hayan aplicado claves definidas de manera apropiada a los conjuntos de datos. Es importante corregir este paso antes de que se actualice el estudio a nuevas instantáneas o se generen notas de nivel de registro.
(3) Trate de elegir el menor número posible de variables para definir las claves y elija las variables que probablemente no cambien los valores. Si un registro tiene un cambio en una de las variables que conforman las claves, no habría manera de hacer coincidir el registro con las versiones anteriores del registro. Sin embargo, dado que todos los registros tienen un Identificador de asunto único (USUBJID), es posible ver todas las notas a nivel de sujeto. Utilice la Guía de implementación de CDISC para recomendaciones.
(4) Dado (3), no usaría términos basados en codificación médica como parte de las claves (es decir, AEDECOD basado en MedDRA o CMDECOD basado en WHODRUG). Hay dos razones para esto. Primero, la codificación médica puede no estar disponible de inmediato. Esto brinda la oportunidad de que un valor faltante de AEDECOD cambie a un término codificado no faltante más adelante. Además, a veces, en el transcurso de un estudio, los términos codificados pueden cambiar según los nuevos conocimientos del equipo clínico. Recomendaría el uso de términos literales como AETERM o CMTRT.
(5) Las variables xxSEQ o STUDYID, USUBJID y xxSEQ configuradas pueden ser buenas claves, ya que es poco probable que estos valores cambien. SIN EMBARGO, la variable xxSEQ debe mantenerse cuidadosamente para que el número nunca cambie para un registro en particular. Por ejemplo, supongamos que un conjunto de datos de CM contiene dos registros:
CMSEQ CMTRT CMSTDTC
1 ASPIRIN 03-20-1974
2 IBUPROFEN 03-27-1974
y se actualiza a través de la consulta con un nuevo med que realmente se encuentra entre los dos primeros en función de la fecha:
CMSEQ CMTRT CMSTDTC
1 ASPIRIN 03-20-1974
2 IBUPROFEN 03-27-1974
3 VITAMINA C 03-24-1974
Es importante que todos los registros nuevos se peguen al final (y para continuar la secuencia de CMSEQ). Alternativamente, si se borra un registro:
CMSEQ CMTRT CMSTDTC
2 IBUPROFEN 03-27-1974
3 VITAMINA C 03-24-1974
El número de secuencia debe mantenerse constante (es decir, 1 nunca se puede usar de nuevo). Si su empresa tiende a definir xxSEQ como un 1 a N directo para todos los registros o 1 a n yo para cada tema sin preocuparse por lo que es la fila, usar xxSEQ como clave no es una buena opción.
(6) Alternativamente, se puede incluir una sola variable que no sea CDISC en cada dominio y agregarse a los metadatos de SORTEDBY. Una buena elección puede incluir una salida variable de identificador de registro de cualquier sistema de administración de datos.
La próxima semana, examinaremos un ejemplo en detalle.
