Migration CDS et LIMS : données historiques, pistes d’audit et rapprochement

Une migration importe tous les résultats attendus, mais les relie à la version actuelle de la méthode plutôt qu’à celle utilisée lors de l’analyse. Le comptage est correct ; l’histoire du laboratoire change. La vérification doit donc couvrir contenu, relations et signification, au-delà de la présence des lignes.

Changer de CDS ou de LIMS exige de décider quoi transférer, quoi garder dans une archive accessible et comment gérer la transition. Cet article propose des critères et essais éditoriaux pour un environnement dédié ; il n’exécute pas de migration et n’autorise pas la suppression des sources.

1. Définir ce qui migre et ce qui reste accessible

Partir de l’usage futur des données. Certains enregistrements servent encore aux processus actifs ; d’autres doivent rester consultables pour conservation, investigations ou inspections. Tout déplacer dans le nouveau modèle n’est pas la seule stratégie : une archive maîtrisée peut convenir si elle préserve contenu, accès et fonctions nécessaires.

Décrire population incluse, exclusions justifiées, période et critères. Attribuer à chaque catégorie une destination et un responsable. Les données non convertibles ne doivent pas disparaître du plan : documenter solution d’accès, limites et évaluation de l’impact.

La planification de l’archive doit précéder le retrait du système. Garder un ancien poste allumé sans contrôles ne démontre pas une stratégie de conservation.

2. Inventorier objets, relations et transformations

Inclure échantillons, résultats, unités, spécifications, méthodes et versions, fichiers natifs, traitements, pistes d’audit, signatures et identités historiques. Distinguer les identités nécessaires à l’attribution des activités passées des comptes à activer aujourd’hui. Conserver le nom de l’auteur n’exige pas de maintenir son ancien accès actif.

La spécification de correspondance doit préciser source, destination, type de donnée, transformation, traitement des valeurs manquantes et conditions d’erreur. Vérifier décimales, précision, unités, caractères, dates et fuseaux ; ne pas convertir implicitement un champ vide en zéro. Si le sens d’un code évolue, préserver le contexte de la version concernée.

Identifier aussi les relations un-à-plusieurs : un échantillon peut comporter plusieurs essais, traitements et décisions. Une table finale aplatie peut masquer cette histoire. La gestion des versions des données de référence LIMS apporte le contexte à préserver pendant le transfert.

3. Vérifier le sens avec une matrice de rapprochement

Cette matrice originale relie risque et preuve. Définir critères et couverture avant le transfert ; aucun pourcentage d’échantillonnage ne convient à toutes les migrations.

Utiliser comptages pour omissions et doublons, contrôles d’intégrité pour copies identiques si pertinents, comparaisons de champs et relations pour contenus transformés. Une somme de contrôle différente après conversion ne prouve pas seule une erreur ; une somme identique sur un fichier ne vérifie pas son lien avec le bon échantillon.

4. Planifier la bascule et le retour maîtrisé

La bascule correspond au transfert opérationnel convenu entre source et destination. Définir quand la population est figée, quelles activités continuent et comment récupérer les modifications ultérieures. Préciser quel système fait autorité à chaque étape, sans modifications concurrentes non rapprochées.

Prévoir prérequis, responsabilités, fenêtre opérationnelle et critères de poursuite ou d’arrêt. La continuité du laboratoire doit couvrir échantillons en cours, séquences ouvertes et résultats en revue. Les enregistrements créés pendant une interruption doivent rejoindre un flux maîtrisé, avec rapprochement ultérieur.

Le retour à la source peut devenir plus complexe après création de nouveaux enregistrements dans la destination. Définir conditions et limites du retour arrière, protection des copies et traitement des données intermédiaires. Redémarrer l’ancien serveur ne suffit pas à reconstituer un état cohérent.

5. Cas simulé : 240 résultats, mauvaises relations

Un transfert d’essai comprend 240 résultats. Source et destination affichent chacune 240 lignes. Le contrôle des relations révèle pourtant que des résultats obtenus avec la méthode M17 version 2 pointent désormais vers la version 3 : la correspondance utilisait le code méthode sans sa version.

L’équipe refuse de conclure sur le seul comptage. Elle identifie la règle défectueuse, recherche toute la population potentiellement concernée et conserve les preuves de l’essai. Elle corrige la correspondance pour distinguer identité et version de méthode, puis répète transfert et contrôles pertinents dans l’environnement dédié.

L’acceptation exige que les résultats conservent version appliquée, paramètres et liens vers les preuves originales. Les relations impossibles à reconstituer restent des exceptions à évaluer et résoudre : aucune version historique plausible ne doit être inventée. La source reste protégée selon le plan.

6. Approuver les exceptions et démontrer l’accès historique

Le rapprochement combine contrôles techniques et usage par un réviseur : partir d’un échantillon, ouvrir les données, comprendre traitements et décisions, exporter le nécessaire. Inclure résultats corrigés, versions obsolètes, identités d’anciens utilisateurs et horodatages avec décalages différents.

Pour chaque exception, enregistrer objets concernés, cause, impact, action, essai répété et décision autorisée. Spécifier les différences intentionnelles ; investiguer les inattendues. La qualité des preuves compte davantage qu’une déclaration générique de migration « réussie à 100 % ».

Avant de retirer la source, confirmer accès, lisibilité, conservation, récupération et responsabilités de la nouvelle organisation. Conserver inventaire, correspondances versionnées, essais et décisions, en distinguant données originales et transformées. Clore le projet ne supprime pas les obligations sur l’historique.

Sources et statut — vérification : 2 octobre 2026. Annexe 11 des BPF UE, janvier 2011, §§4.8, 7, 10, 16–17 ; PIC/S PI 041-1, 1er juillet 2021, §§9.4 et 9.9, guide d’inspection ; FDA Data Integrity, guidance finale non contraignante, décembre 2018, Q1(b), Q9–10 ; 21 CFR Part 11, §§11.10(b–c), 11.70, selon applicabilité. Matrice et cas sont des exemples originaux, sans pourcentage ni protocole universels.