CliniGA CRO

Blog CliniGA CRO

Après une panne d’API : repérer les données manquantes au retour de la connexion

Après une panne d’API, rapprocher la période d’interruption des données sources permet de repérer les enregistrements manquants.

Photographie représentative de la catégorie : Après une panne d’API : repérer les données manquantes au retour de la connexion
Photo: Happi Raphael · Licence: CC BY-SA 4.0 · Image recadrée et redimensionnée.
Publication
Mise à jour

Une interface rétablie ne démontre pas que tous les enregistrements créés pendant une panne sont arrivés. La connexion peut sembler fonctionner correctement alors que certaines heures, certains questionnaires ou dossiers de participants manquent encore dans le système destinataire.

Préserver le sens des données

Suivre séparément la connectivité et l’exhaustivité des données dans le plan de reprise. Établir une relation explicable entre les requêtes échouées, les enregistrements en attente, les enregistrements acceptés et les exceptions de traitement. Définir comment traiter, lors du rejeu, les enregistrements modifiés à la source pendant une panne. Le point de départ de la reprise ne doit pas dépendre uniquement de l’horodatage de la dernière connexion réussie.

Exemple pratique

Par exemple, une interface ePRO tombe en panne pendant la nuit. Son tableau de bord passe au vert le matin, mais certains questionnaires remplis restent bloqués dans une file d’attente. L’équipe rapproche la liste source des questionnaires, la file de livraison et le journal de réception EDC au moyen des identifiants des participants et des questionnaires. Chaque différence non résolue reçoit un responsable désigné et une prochaine action documentée.

Points de contrôle

  • Établir indépendamment la population des enregistrements sources affectés par la panne.
  • Confirmer que les livraisons rejouées ne créent pas d’observations en double.
  • Maintenir visibles les enregistrements dont la reprise échoue dans une liste d’exceptions.

Acceptation et limites

L’acceptation signifie que chaque enregistrement de la population concernée est accepté, exclu avec un motif ou identifié comme un point ouvert. Cet exemple n’exige pas une architecture technique unique de file d’attente pour toutes les interfaces. Choisir des preuves proportionnées aux données critiques de l’étude. L’équipe de l’étude doit évaluer séparément tout effet sur les délais cliniques ; la reprise technique ne peut pas remplacer ce jugement.

Questions fréquentes

Pourquoi un test de connectivité est-il insuffisant ?
Il montre l’accès actuel, mais pas les enregistrements historiques perdus, retardés ou restés en attente.
Que faire si un enregistrement manquant arrive plus tard ?
Conserver son heure initiale de recueil et expliquer comment le retard affecte l’examen des données concernées.

Sources

  1. FDA — Systèmes, enregistrements et signatures électroniques dans les investigations cliniques
  2. MHRA — Recommandations sur l’intégrité des données GxP