Structure des données et appel de fonction pour les données d'événements récurrents avec des variables dépendantes du temps


9

J'essaie d'estimer l'effet de 2 médicaments ( drug1, drug2) sur la probabilité de chute d'un patient ( event). Les patients peuvent tomber plus d'une fois et peuvent être mis ou retirés des médicaments à tout moment.

Ma question est de savoir comment les données doivent être structurées en fonction de la période (jours), en particulier s'il doit y avoir un chevauchement entre les jours. Il y a deux raisons pour lesquelles je pense que ma structure est mauvaise, la première étant apparemment incorrecte N. Je reçois également des erreurs lorsque la période de temps est un seul jour (c. time1=4-à- d . time2=4) Et je ne sais pas comment celles-ci doivent être codées. L'heure de début des entrées suivantes doit-elle être l'heure de fin de l'entrée précédente? Je l'ai essayé dans les deux sens (avec et sans chevauchement), et bien que le chevauchement supprime l'avertissement, le Nest toujours incorrect.

Warning message:
In Surv(time = c(0, 2, 7, 15, 20, 0, 18, 27, 32, 35, 39, 46, 53,  :
  Stop time must be > start time, NA created

En ce moment, j'ai mis en place les données où le début de la prochaine entrée est le lendemain. Les patients uniques sont identifiés par leur chart numbers.

Time1    Time2    Drug1    Drug2   Event    ChartNo
    0        2        1        0       0        123
    3       10        1        1       1        123
   11       14        1        1       1        123
    0       11        0        1       0        345
    0       19        1        0       1        678
    0        4        0        1       0        900
    5       18        1        1       0        900

Le patient 123 était sous médicament1 du début au jour 2, après quoi il a ajouté du médicament2. Ils sont passés du jour 3 au jour 10 avec les deux drogues avant de tomber la première fois, puis sont tombés une deuxième fois au jour 14 alors qu'ils prenaient toujours les deux drogues. Le patient 345 a pris 11 jours de drogue2 sans tomber (puis a été censuré), etc.

L'estimation réelle ressemble à ceci:

S <- Srv(time=time1, time2=time2, event=event)
cox.rms <- cph(S ~ Drug1 + Drug2 + cluster(ChartNo), surv=T)

Ma principale préoccupation est que le npour mon analyse serait 2017(le nombre de lignes dans les données), alors qu'en réalité je n'ai que 314des patients uniques. Je ne suis pas sûr que ce soit normal ou le résultat d'une erreur que j'ai commise en cours de route.

> cox.rms$n
Status
No Event    Event 
    1884      133 

La même chose est vraie lors de l'utilisation à coxph()partir du package de survie.

 n= 2017, number of events= 133

Le nombre d'événements est cependant correct.

Ce message semble l'avoir mis en place avec le `` chevauchement '' que j'ai décrit, mais je ne suis pas sûr du N, et ils ne semblent pas être regroupés ID.


Le +cluster(ChartNo)terme doit prendre en compte la préoccupation des observations répétées. Une autre approche serait d'ajouter + (1|subject)à une analyse coxme :: coxme.
DWin

Réponses:


1

La mise en forme de vos données est correcte.

Vous avez plusieurs dossiers par patient en raison d'événements récurrents et de la complexité supplémentaire du médicament qui est une covariable variant dans le temps. La sortie que vous avez imprimée headest utile pour comprendre ces données.

L'approche typique pour analyser les événements récurrents ainsi que les covariables variant dans le temps, consiste à formater les données pour qu'elles soient dans un format «long» où chaque ligne représente un intervalle d'observations de covariables au risque. Par exemple, nous voyons que le patient 123 est sous Drug1 seul du temps 0 au temps 2, puis change pour prendre à la fois le médicament 1 et le médicament 2 à partir du moment 3. À ce stade, ils n'avaient pas connu de chute, donc leur observation de 0-2 est censuré à ce stade parce que nous ne savons pas combien de temps leur chute se prolongerait s’ils continuaient à prendre le médicament 1 seul. Au moment 3, ils sont réintégrés dans la cohorte codée comme patient prenant les deux médicaments pendant 7 unités de temps, après quoi ils subissent leur première chute. Ils subissent une deuxième chute sur la même combinaison de médicaments seulement 4 unités de temps après.

Le nombre d'enregistrements n'est pas un résumé utile des données de cohorte. Il n'est pas surprenant que le nombre de rangées soit bien supérieur au nombre de patients. Au lieu de cela, additionnez les temps du début à la fin et enregistrez-les en tant que temps-personne à risque. Le dénominateur de cohorte est utile pour comprendre l'incidence. Il est également utile de résumer le nombre brut de patients, mais gardez à l'esprit que les données sont au format "long", ce qui est inférieur au nombre de lignes de votre ensemble de données.

Pour l'erreur, je pense que vous devrez peut-être ajouter 1 unité à la date "d'arrêt". Si le patient 123 prend le médicament 1 pendant les jours 0, 1 et 2 et commence ensuite le médicament 2 le jour 3, alors il a connu 3 jours à risque de chutes avec le médicament 1. Cependant, 2-0 = 2 et ce n'est pas le bon dénominateur.

Ce que l'argument «cluster» fait (typiquement), c'est imposer une fragilité, qui est un type d'interception aléatoire qui tient compte de ce qui peut être des différences de risque proportionnelles attribuables à plusieurs facteurs de risque non mesurés. Je ne fais pas souvent d'analyses avec des faiblesses. Vous pouvez omettre la commande "cluster" et interpréter les résultats comme des taux d'incidence. Vous pouvez alternativement adapter le modèle cox pour le temps jusqu'à la première chute chez tous les patients et interpréter les ratios de risque comme des ratios de risque. Je pense que le résultat de la fragilité devrait se situer quelque part entre ces deux, et je n'ai jamais été très clair sur ce que devrait être l'interprétation.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.