Nella settimana scorsa inviare, abbiamo discusso alcune delle caratteristiche imminenti di JMP Clinical 4.1 che identifica i record nuovi e modificati quando vengono aggiornati i dati della sperimentazione clinica. Questi strumenti possono accelerare notevolmente le revisioni cliniche, consentendo al medico, alla statistica o al gestore dati di concentrarsi esclusivamente su record non verificati. Qui discutiamo i dettagli di come JMP Clinical rende ciò possibile.
Capire la discussione di seguito farà molto per garantire che la tua esperienza di revisione clinica JMP sia il più efficiente e piacevole possibile. Anche se la presentazione sembra un po 'tecnica, il team responsabile della generazione dei set di dati SDTM o ADaM dovrà aggiungere un singolo passaggio di elaborazione (se non lo sta già eseguendo). Altrimenti, molti di noi possono rimanere beatamente inconsapevoli dei passaggi aggiuntivi.
In breve, si tratta di chiavi .
Le chiavi di solito ci danno accesso a qualcosa, che si tratti di una scatola chiusa o di una stanza. Quando si discutono insiemi di dati, le chiavi ci danno un'idea dell'unicità di una riga di record o set di dati. Il CDISC SDTM La guida all'implementazione definisce i seguenti termini:
Chiave naturale è una o più variabili il cui contenuto distingue in modo univoco ogni record (riga) nel set di dati. Ad esempio, ogni riga del dominio DM dovrebbe rappresentare un argomento diverso. Le chiavi naturali in questa istanza potrebbero essere Study Identifier (STUDYID) e Unique Subject Identifier (USUBJID). Chiave surrogata è un identificatore a variabile singola stabilito artificialmente che identifica in modo univoco le righe. Questo potrebbe includere qualsiasi delle variabili xxSEQ. Ad esempio, se il set di dati sui segni vitali contiene 200 record, la variabile VSSEQ potrebbe essere numerata da 1 a 200 per identificare in modo univoco le righe.In alternativa, xxSEQ può essere fatto parte di una chiave naturale in modo che xxSEQ possa contare da 1 a n io , dove n io è il numero totale di record per un argomento. Qui le chiavi sarebbero STUDYID, USUBJID e xxSEQ.
Quindi perchè è importante? Bene, per esaminare un record (riga) per le differenze tra due istantanee, ci deve essere un modo per collegare insieme queste due versioni del record. Qui è dove arrivano le chiavi. In caso contrario, JMP Clinical non ha modo di sapere quali record abbinare. Inoltre, per salvare o accedere alle note per un particolare record, è necessario un modo per archiviare la nota in modo che sia accessibile in un secondo momento quando si ritorna al record. Di nuovo, è qui che entrano le chiavi.
Quindi, come può un utente fornire a JMP Clinical le chiavi per tutti i domini dati per uno studio? Questo è in realtà abbastanza banale. Se hai mai utilizzato PROC CONTENTS, l'intestazione di output per un set di dati contiene varie informazioni sul set di dati. Una di queste informazioni è "SORTED: YES / NO". Se il set di dati è ordinato (cioè, SÌ), vengono fornite ulteriori informazioni nell'output PROC CONTENTS dopo la descrizione delle variabili del set di dati. Ad esempio, quando utilizzo PROC CONTENTS nel dominio DM per Nicardipine, ottengo la seguente riga nell'output: "Sortedby STUDYID USUBJID". Questi metadati sono memorizzati nel set di dati formattato SAS; le variabili utilizzate per l'ordinamento dei set di dati sono quelle utilizzate da JMP Clinical per definire le chiavi per uno studio.
Quindi, come possono questi valori essere salvati nei metadati di un set di dati? Prova entrambi:
Dati PROC SORT = DM out = out.DM;
di STUDYID USUBJID;
correre;
o
data out.DM (ordinatoby = STUDYID USUBJID);
imposta DM;
correre;
Se i domini di studio non hanno i metadati SORTEDBY associati ai set di dati, JMP Clinical tenta di ricavare le chiavi in base ai suggerimenti forniti nella Guida all'implementazione di SDTM. Tuttavia, le chiavi generate potrebbero non essere l'insieme ottimale per un determinato dominio.
Quindi ciò accade se le chiavi fornite non definiscono i record (righe) in modo univoco? Quando lo studio viene aggiunto per la prima volta a JMP Clinical, viene fornito un rapporto duplicato per ogni dominio interessato che specifica i record (righe) che non possono essere determinati in modo univoco. Questi record (righe) saranno ancora etichettati come nuovi in JMP Clinical. Tuttavia, qualsiasi nota a livello di record generata dal sistema o dall'utente verrebbe associata a due o più record. Questo può essere OK se ci sono pochi duplicati con cui fare i conti, ma eventuali duplicati dovrebbero essere rivisti come potenziali errori di dati (dati erroneamente inseriti due volte). Quando i dati dello studio vengono aggiornati e le ridondanze rimangono, JMP Clinical non ha modo di abbinare questi record. In altre parole, non può valutare se siano state apportate modifiche ai record o meno. Anche in questo caso, se ci sono pochi duplicati, questi record (righe) possono essere rivisti in più istantanee per correttezza.
Alcuni altri suggerimenti importanti:
(1) Quando si aggiunge per la prima volta uno studio, esaminare il rapporto duplicato. Identifica le chiavi per ciascun dominio e assicurati che i duplicati siano ridotti al minimo (idealmente, non presente). In caso contrario, la funzionalità di revisione non sarà così utile come potrebbe essere in definitiva. Ad esempio, se il dominio dei segni vitali (VS) è stato ordinato solo da STUDYID e USUBJID utilizzando il codice PROC SORT sopra riportato, tutti i record relativi all'argomento saranno considerati duplicati. Ciò includerebbe più test (come la frequenza cardiaca, la pressione sanguigna sistolica e diastolica) o record appartenenti a visite diverse.
(2) Se si esegue (1) e vi sono numerose duplicazioni per tutti i domini, rimuovere lo studio da JMP Clinical e riaggiungere altre chiavi appropriatamente definite sono state applicate ai set di dati. È importante correggere questo passaggio prima che lo studio venga aggiornato alle nuove istantanee o che vengano generate note a livello di record.
(3) Provare a scegliere il numero minimo di variabili possibili per definire le chiavi e scegliere le variabili che non sono suscettibili di modificare i valori. Se un record ha una variazione in una delle variabili che compongono le chiavi, non ci sarebbe alcun modo per abbinare il record alle versioni precedenti del record. Tuttavia, poiché tutti i record hanno Identificatore oggetto univoco (USUBJID), è possibile visualizzare tutte le note a livello di oggetto. Utilizzare la Guida all'implementazione CDISC per consigli.
(4) Dato (3), non userei termini che si basano sulla codifica medica come parte delle chiavi (ad esempio, AEDECOD basato su MedDRA o CMDECOD basato su WHODRUG). Ci sono due ragioni per questo. Innanzitutto, la codifica medica potrebbe non essere immediatamente disponibile. Ciò fornisce un'opportunità per un valore mancante di AEDECOD di passare a un termine codificato non mancante in seguito. Inoltre, a volte nel corso di uno studio, i termini codificati possono cambiare in base a nuove intuizioni del team clinico. Consiglierei di usare termini letterali come AETERM o CMTRT.
(5) Le variabili xxSEQ o STUDYID, USUBJID e xxSEQ possono essere buone chiavi da utilizzare poiché è improbabile che questi valori cambino. TUTTAVIA, la variabile xxSEQ deve essere attentamente mantenuta in modo che il numero non cambi mai per un particolare record. Ad esempio, supponiamo che un set di dati CM contenga due record:
CMSEQ CMTRT CMSTDTC
1 ASPIRIN 03-20-1974
2 IBUPROFEN 03-27-1974
e viene aggiornato tramite query con un nuovo med che cade effettivamente tra i primi due in base alla data:
CMSEQ CMTRT CMSTDTC
1 ASPIRIN 03-20-1974
2 IBUPROFEN 03-27-1974
3 VITAMIN C 03-24-1974
È importante che tutti i nuovi record vengano aggiunti alla fine (e per continuare la sequenza di CMSEQ). In alternativa, se un record viene cancellato:
CMSEQ CMTRT CMSTDTC
2 IBUPROFEN 03-27-1974
3 VITAMIN C 03-24-1974
Il numero di sequenza deve essere mantenuto coerente (ovvero, 1 non può essere più utilizzato). Se la tua azienda tende a definire xxSEQ come una scala da 1 a N per tutti i record o da 1 a n io per ogni argomento senza preoccuparsi di quale sia la riga, usare xxSEQ come chiave non è una buona scelta.
(6) In alternativa, una singola variabile non CDISC può essere inclusa in ciascun dominio e aggiunta ai metadati SORTEDBY. Una buona scelta può includere un output di variabile identificatore del record da qualsiasi sistema di gestione dei dati.
La prossima settimana esamineremo un esempio in dettaglio.
Revisioni cliniche veramente efficienti - profilo del paziente in JMP Clincal ha scritto:
[...] nel prossimo JMP Clinical 4.1. Se sei nuovo nella conversazione, sentiti libero di raggiungerlo qui, qui e qui. La capacità di JMP Clinical di identificare dati nuovi o modificati dall'istantanea all'istantanea, [...]
