Qualité des données

Pour faire suite au billet sur l’absence de définition consensuelle d’étude prospective. Le débat sémantique sur le terme cache les vrais problèmes de qualité de données.

Ainsi, je vous propose de vous poser les questions suivantes lorsque vous évaluez la qualité d’une donnée :

  1. La donnée a-t-elle été renseignée de manière systématique (faible nombre de données manquantes) ; sinon, le manquement des données est-il fortement corrélé à la valeur de la donnée.
  2. La donnée a-t-elle été évaluée de manière standardisée ou selon la pratique courante ; en cas d’évaluation subjective, les deux options peuvent chacune avoir un intérêt (meilleure validité interne ou meilleure validité externe)
  3. À quel point la donnée est-elle évaluateur-dépendant ?
  4. La donnée est-elle soumise à un biais de mémorisation ?
  5. La donnée est-elle soumise à des biais d’évaluation par absence d’aveugle d’une exposition ou d’une intervention
  6. De bonnes pratiques de saisie, monitoring et gestion des données ont-elles été mises en place afin de garantir l’absence de l’erreur de saisie ou de recopie entre la donnée source et la donnée finale qui a été présentée dans l’article publié
  7. Le monitoring et la gestion de données ont-ils montré des erreurs fréquentes : écarts entre données saisies et données sources, incohérences des données saisies.

L’élément N°7 est en pratique impossible à retrouver dans les articles publiés, parce qu’il n’y a pas de paragraphe « gestion de données » dans les articles biomédicaux. Il est pourtant important de limiter au minimum le nombre de recopies, faire double saisie aux étapes clés ; il faudrait toujours garder un audit trail (historique des modifications) de la base de données ou des bases de données. Il faut savoir que la durée d’hospitalisation, qui est une information médico-administrative que l’on peut extraire de manière fiable à partir des données du département d’information médicale, est parfois recopiée depuis des comptes-rendus, avec des erreurs et des données manquantes !

J’ai vu des base de données Excel évolutives et immondes : tout ce qui pouvait être incohérent l’était de manière massive même pour des choses considérées comme « fiables », comme l’anatomie pathologique. C’est-à-dire, que la moitié des « Adénocarcinomes in situ » étaient de stade T1a (alors que ça devrait être Tis), avec le détail du T, du N et du M qui n’était pas en cohérence avec le stade TNM synthétique ; par ailleurs, selon que l’on analysait la « version finale N°1 » ou la « version finale N°2 » du fichier Excel, on avait des cellules qui se vidaient (apparition d’une donnée manquante), d’autres qui se remplissaient, des incohérences qui apparaissaient, d’autres qui disparaissaient. Sans compter les problèmes de décrépitude des fichiers informatiques : les caractères accentués qui passent à du double ou triple UTF-8 (Modéré qui devient Modéré puis Modéré) ou qui au contraire, passe de l’UTF-8 à l’ISO-8859-1 de manière répétée, conduisant à la disparition des caractères accentués ou à leur remplacement par des points d’interrogation.

Et puis il y a les grands classiques d’Excel et des mauvaises pratiques de gestion des données associées :

  1. Les données qui sont saisies dans la colonne voisine à la colonne dans lesquelles elles sont censées être saisies ;
  2. Les colonnes qui sont triées mais en oubliant d’étendre la sélection aux autres colonnes, de telle sorte qu’il y a une perte totale de la correspondance des lignes entre les colonnes, ce qui décorrèle complètement les données ;
  3. Les données qui sont interprétées à tort comme des dates alors qu’elles n’ont rien à voir
  4. Les dates qui se décalent de quatre ans à cause d’un copier-coller depuis un tableur créé sur Macintosh ;
  5. Les inversions mois/jours des dates à cause du mélange des dates américaines (MM/JJ/AAAA) et françaises (JJ/MM/AAAA) ;
  6. Les blocs de cellules qui sont copiées depuis un autre tableur Excel, mais les lignes n’étant pas dans le même ordre, les données sont interverties entre les lignes ;
  7. Le suppression des lignes des patients exclus qui rend impossible la création d’un flow chart ; à la fin, on ne sait même plus pourquoi certains patients avaient été exclus ;
  8. Les multiples corrections de données (p.e. erreurs de saisies corrigées), mais avec une perte de la trace des modifications et de leur raison avec un travail en parallèle sur plusieurs fichiers : je crois que le tableur N°1 est « bon » pour les colonnes 1 à 5 et le tableur N°2 est « bon » pour les colonnes 6 à 8… à moins que ce ne soit l’inverse ;
  9. Les corrections qui portent sur certaines données mais pas d’autres : « j’ai corrigé l’IMC mais j’ai gardé le mauvais poids… C’est l’IMC qu’il faut regarder… sauf pour le patient N°8 dont j’ai corrigé le poids mais pas l’IMC… » ;
  10. Les données redondantes incohérentes telles que : « ah, la colonne groupe ne doit pas être prise en compte parce que j’ai arrêté de la remplir au bout d’un moment : il faut juste regarder la couleur des lignes : en vert ce sont les malades suivis jusqu’au bout, en violet, ce sont les malades perdus de vue et en orange ce sont les sujets sains ».

Et puis, il y a ce qui se passe durant la rédaction du rapport d’analyse statistique : cette fois-ci, le statisticien est à blâmer. Le logiciel SAS, quand on lui demande de sortir le pourcentage de A (variable binaire) parmi B (variable binaire), en affiche 27 différents, parce qu’il affiche un tableau de contingence 3×3 (OUI, NON, TOTAL) avec 3 pourcentages (en ligne, en colonne, sur total général) par cellule. Pour ceux qui recopient à la main le pourcentage dans le rapport d’analyse, il faut choisir le seul bon pourcentage sur les 27 présentés. Ensuite, il y a la pratique de remplissage des tableaux cellule par cellule, copiant un à un les résultats des sorties logicielles dans le tableau. Il y a même la pratique d’inversion des risques relatifs ou odds ratio, présentés à l’envers par le logiciel, à la calculatrice. Enfin, lors d’une mise à jours de la base de données, il est nécessaire de recalculer toutes les statistiques du rapport. L’idéal est de générer le rapport d’analyse entièrement à partir du script (p.e. avec R markdown), mais ce genre de pratique n’est pas rapporté dans les articles.

Ensuite, il y a les erreurs de recopie du rapport d’analyse dans l’article : avec les mauvais doigts, il est même possible de copier-coller un tableau complet en rajoutant des erreurs en plein milieu du tableau. Bien sûr, le texte est l’endroit où il y a le plus d’erreurs de recopie possible, notamment sur le contexte entourant un chiffre. Par exemple, la phrase « le pourcentage de diabétiques parmi les insuffisants rénaux de stade III qui ont survécu au-delà de deux ans de suivi était estimé à X% », deviendra « le pourcentage d’insuffisants rénaux parmi les diabétiques était de X% ».

Il est dommage que le travail des vrais gestionnaires de données, techniciens d’étude clinique et attachés de recherche clinique ne soit pas valorisé dans les articles ; il faudrait aussi publier les rapports d’analyse statistique.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *