Passer de YouEDC 0.2

Comment les études et leurs données passent de YouEDC 0.2, et les trois vérifications.

Les études de YouEDC 0.2 passent dans YouEDC Capture en entier : avec l’équipe, l’eCRF, les patients, les données, les queries et la piste d’audit. L’administrateur du serveur fait le transfert avec une seule commande. Les utilisateurs n’ont rien à faire : ils se connectent sur youedc.com avec le même e-mail et le même mot de passe et retrouvent leurs études.

Ce qui est transféré

• Les comptes passent avec le même e-mail et le même mot de passe. Quand un compte avec cet e-mail existe déjà dans le portail, il reste tel quel, avec son mot de passe du portail. Les comptes désactivés dans 0.2 restent désactivés.
• Les études passent avec leurs centres, l’équipe, les rôles et les restrictions d’accès par centre. Les invitations pas encore acceptées passent aussi.
• L’eCRF : visites, formulaires, champs avec leurs plages et conditions d’affichage, règles de contrôle.
• Les patients passent avec leur statut et leur lien ePRO personnel. Les liens remis aux patients dans 0.2 continuent de fonctionner.
• Les données : chaque formulaire avec son statut (brouillon, rempli, SDV), les valeurs et les marques « pas de données ».
• Les queries passent avec leurs échanges et leur statut, et les queries automatiques restent liées à leurs règles.
• L’historique des imports et celui des exports sont conservés.
• La piste d’audit passe en entier, avec l’heure et l’adresse IP d’origine de chaque enregistrement. La piste d’audit de chaque étude reçoit un dernier enregistrement « Import · YouEDC 0.2 » qui dit ce qui a été transféré et en quelle quantité.

Les trois contrôles

1. La piste d’audit 0.2 avant le transfert. On vérifie d’abord la chaîne d’empreintes de la piste d’audit 0.2 sur la copie de la base. Si la chaîne est rompue, le transfert ne commence pas.
2. Le nombre de lignes. Chaque table de 0.2 doit avoir autant de lignes après le transfert : comptes, études, centres, patients, formulaires, valeurs, queries, enregistrements d’audit.
3. Cellule par cellule. Chaque étude est exportée comme 0.2 l’aurait exportée, puis par l’export du portail. On le fait deux fois, avec les codes et avec les textes des réponses. Les fichiers sont comparés cellule par cellule.

Les enregistrements d’audit transférés sont aussi comparés à ceux de 0.2, et les chaînes d’audit du portail sont vérifiées. La commande de contrôle échoue dès qu’elle trouve une seule différence. Elle montre chaque différence par son adresse « étude / feuille / ligne / colonne », sans les valeurs. On peut donc transmettre sa sortie sans risque : elle ne contient aucune donnée patient.

Le transfert et le contrôle d’une copie de test de la base 0.2 : tout concorde.

Exemple : une copie de test de 0.2

La capture ci-dessus montre le transfert d’une base 0.2 de test avec des personnes inventées. Elle contient deux études : le registre de l’insuffisance cardiaque CARD-01 (2 centres, 4 patients, 11 formulaires saisis, 5 queries) et l’enquête de qualité de vie EPRO-2, dont la base était déjà gelée. La sortie se lit ainsi :

• YouEDC 0.2 audit chain: 99 records, OK : la piste d’audit 0.2 est intacte, avec 99 enregistrements.
• Accounts: 6 added, 0 already here : 6 comptes transférés, aucun e-mail déjà présent.
• Study 1 of 2 (CARD-01): new study; sites 2, … : ce qui a été transféré pour chaque étude.
• Moved: studies 2, patients 5, … : le total.
• Dans le contrôle, chaque table affiche match, et les exports de CARD-01 (7 feuilles, 888 cellules) et d’EPRO-2 aussi. La dernière ligne est RESULT: everything matches.

Après le transfert, CARD-01 garde son historique des exports de 0.2, marqué « YouEDC 0.2 », et sa piste d’audit contient les enregistrements de 0.2 avec leur heure d’origine.

L’historique des exports de CARD-01 : les exports faits dans 0.2.

La piste d’audit de CARD-01 : l’enregistrement du transfert en haut, ceux de 0.2 avec leur heure d’origine en dessous.

Relancer, et codes déjà pris

• Relancer le transfert ne duplique rien : ce qui est déjà transféré est ignoré. Si quelque chose a été modifié dans 0.2 après le transfert, le contrôle montre une différence.
• Si le code d’une étude 0.2 est déjà utilisé par un autre projet du portail, le transfert s’arrête avant toute modification et cite ces codes. Renommez le projet du portail, ou lancez le transfert avec --rename-conflicts : l’étude reçoit alors un code terminé par -2 (par exemple CARD-01-2).
• Un essai avec --dry-run fait le même travail et affiche les nombres, puis annule tout.

Commandes pour l’administrateur

Les commandes tournent sur le serveur du portail, sur une copie de la base 0.2 (le fichier SQLite d’une sauvegarde de 0.2) :

• flask --app wsgi import-v02 --dry-run /tmp/v02.db fait un essai qui n’enregistre rien ;
• flask --app wsgi import-v02 /tmp/v02.db transfère les données ;
• flask --app wsgi import-v02 --verify /tmp/v02.db ou flask --app wsgi verify-v02 /tmp/v02.db fait le contrôle et ne modifie rien.

Tout est d’abord répété dans une copie temporaire de la base du portail, sur le serveur même. Le vrai transfert ne se fait qu’après une répétition propre. Après le transfert, 0.2 reste sur old.youedc.com en lecture seule, comme filet de sécurité, et la saisie continue dans YouEDC Capture.