Comment écrire des edit checks pour un eCRF

Un edit check est une condition que l’EDC vérifie quand un centre enregistre une valeur. Si la valeur ne la remplit pas, le centre voit un message et corrige la saisie avant que votre data manager n’ouvre une query. Pour écrire de bons edit checks, listez-les d’abord dans une spécification. Construisez et testez ensuite chacun au regard du protocole.

Ce que couvre un edit check

La plupart des edit checks appartiennent à cinq familles. Les edit checks de plage comparent une valeur aux limites attendues, par exemple une température corporelle entre 35,0 et 42,0 °C. Les champs obligatoires empêchent une donnée clé de rester vide. Les edit checks de date gardent les événements dans l’ordre, comme une visite après la date de consentement. Les edit checks croisés comparent deux réponses : un test de grossesse chez un participant enregistré comme homme, par exemple. Les edit checks de calcul comparent une valeur dérivée, comme l’IMC, aux champs dont elle provient.

Écrire des edit checks en 6 étapes

1. Listez les données critiques. Partez des critères de jugement, des critères d’éligibilité et des données de sécurité. Placez-y vos premiers edit checks : ces champs décident de la validité des résultats.
2. Écrivez une ligne de spécification par edit check. Notez le formulaire, le champ, la condition en langage naturel, le message et l’action : avertissement, query ou blocage.
3. Choisissez l’action avec soin. Utilisez un avertissement pour les valeurs rares mais possibles. Réservez les edit checks bloquants aux valeurs qui ne peuvent pas exister, comme une date de visite dans le futur.
4. Rédigez le message pour le centre. Dites ce qui ne va pas et ce qu’il faut vérifier : « La température dépasse 42,0 °C. Vérifiez l’unité et le dossier source. » Laissez de côté les codes et le jargon de data manager.
5. Construisez et testez. Pour chaque edit check, saisissez une valeur qui doit passer et une valeur qui doit échouer. Consignez le résultat dans votre journal de tests.
6. Versionnez les edit checks. Quand le protocole change, mettez à jour la spécification, relancez les tests concernés et conservez la version précédente dans l’audit trail.

Les erreurs qui noient les centres sous les queries

• Trop d’edit checks. Un edit check sur chaque champ habitue les centres à fermer les avertissements sans les lire. Vérifiez ce dont l’analyse a besoin.
• Des messages vagues. « Valeur invalide » oblige le coordinateur à chercher. Indiquez la limite et la source à vérifier.
• Bloquer des valeurs plausibles. Un blocage sur un résultat réel mais inhabituel pousse le centre à saisir une fausse valeur.
• Des edit checks ajoutés après la mise en production. Chaque ajout tardif ouvre des queries sur des données saisies il y a plusieurs semaines.

Les edit checks dans Datacapt

Dans Datacapt, vous définissez des plages et des edit checks de cohérence sur le champ. Le formulaire signale une valeur hors plage pendant que le centre la saisit. Quand une valeur ne passe pas un edit check, le centre voit votre message et Datacapt ouvre une query sur cette donnée. Vous choisissez l’affichage du message : information, avertissement ou exclusion. Aucun des trois ne bloque la saisie. Avant qu’une modification n’atteigne vos centres, le build check montre ce qu’elle casserait. Les champs dérivés comme l’IMC ou les scores viennent d’une expression que vous écrivez dans le formulaire.

Pour aller plus loin

• Comment concevoir un cahier d’observation (CRF)
• 3 façons d’améliorer la qualité des données dans les essais cliniques
• Toutes les fonctionnalités EDC de Datacapt