Migrer les données d’un ancien système

Dans chaque passage d’un système à un autre, il y a un moment où quelqu’un dit : il suffit de migrer les données. Cette phrase masque la partie difficile. Les données ne sont pas des fichiers qui passent d’un endroit à un autre ; ce sont du sens conservé dans une structure donnée, et l’on peut perdre du sens même quand toutes les lignes ont été copiées intégralement.

D’abord : qu’est-ce qui doit vraiment migrer

L’hypothèse que tout doit migrer est coûteuse et le plus souvent inutile. Une séparation pratique en trois groupes :

Groupe	Ce qu’il comprend	Approche
Obligatoire, structuré	Patients actifs, allergies, médicaments, diagnostics, rendez-vous futurs	Conversion complète vers la structure du nouveau système
Important, comme texte ou document	Comptes rendus de visite historiques, courriers, anciens résultats	Le plus souvent suffisant comme document lisible rattaché au patient et à la date
Laissé derrière	Ancien historique financier, journaux système, brouillons, données internes du système	Accès en lecture dans l’ancien système pour une période définie

La distinction entre la première et la deuxième ligne est la plus importante. Une donnée structurée est une donnée sur laquelle le système peut agir — une allergie qui déclenche une alerte face à une ordonnance, un médicament qui apparaît dans une liste active. La même information sous forme de texte libre à l’intérieur d’un compte rendu paraît identique à l’œil humain et n’a aucune valeur pour le système. C’est pourquoi les allergies et les médicaments reçoivent la priorité la plus haute dans une conversion structurée, même s’ils représentent une petite quantité de données.

Les pièges qui reviennent presque toujours

1. Numéro d’identité avec zéro en tête

Un numéro d’identité conservé comme nombre et non comme texte perd ses zéros en tête. Un patient dont le numéro commence par zéro devient un nombre à huit chiffres, et alors la validation du chiffre de contrôle échoue, la correspondance avec la caisse de santé se brise, et des doublons se créent. C’est la défaillance la plus fréquente dans les migrations en Israël, et il est facile de la contrôler à l’avance.

2. Dates au format mixte

Un fichier où une partie des dates a été écrite en jour-mois-année et une autre en mois-jour-année passera la conversion sans erreur, et produira des dates de naissance erronées dans tous les cas où le jour est inférieur à 13. Le contrôle : compter combien de dates de naissance tombent dans une plage invraisemblable, et examiner la répartition par mois.

3. Encodage des caractères

De l’hébreu enregistré dans un ancien encodage et lu comme un autre encodage devient du charabia. Parfois c’est flagrant, et parfois cela ne touche que certains caractères comme l’apostrophe ou des signes de ponctuation, et se découvre tardivement.

4. Caractères de contrôle cachés

Les systèmes qui affichent de l’hébreu à côté de chiffres ajoutent parfois des caractères de contrôle de direction invisibles. S’ils ont été enregistrés avec la donnée et non seulement à l’affichage, ils migreront et briseront la recherche et la correspondance exacte : un nom paraîtra identique à l’écran mais ne sera pas trouvé à la recherche. Il vaut la peine de les nettoyer explicitement.

5. Listes de valeurs qui ne correspondent pas

Statuts, types de rendez-vous, catégories de documents — chaque système a ses propres listes. Leur mise en correspondance est un travail manuel incontournable. Mieux vaut le faire tôt, car il révèle le plus souvent que l’ancienne liste a grandi sans ordre et comporte des valeurs en double.

6. Doublons de patients

Dans presque tout système ancien, il y a des patients en double : une fois avec un nom en hébreu et une fois en caractères latins, une fois avec un passeport et une fois avec un numéro d’identité. Une conversion migre les doublons tels quels. L’instant qui précède la migration est la meilleure occasion de les fusionner.

Comment on travaille concrètement

1. Un premier export tôt. Avant même la décision finale, demander un export à titre d’exemple. Il révèle ce qu’il est possible d’extraire, et cela influence la décision.
2. Une conversion d’essai sur une copie. Exécuter la conversion dans son intégralité vers un environnement de test, et la parcourir. Ne pas sauter cette étape.
3. Un contrôle manuel par échantillon. Choisir vingt patients — y compris des cas extrêmes : nom long, patient avec passeport, nourrisson, patient à long historique — et comparer écran par écran.
4. Des contrôles de dénombrement. Combien de patients, combien de visites, combien de documents, combien d’allergies — avant et après. Tout écart exige une explication.
5. La conversion finale dans une fenêtre définie. En fin de semaine, avec un point de retour défini à l’avance et une décision sur qui déclare la réussite.
6. Un accès en lecture à l’ancien système. Pour une période définie. C’est le filet de sécurité qui permet de dormir la nuit.

Un contrôle qu’il vaut toujours la peine de faire : prendre cinq patients et s’assurer que la somme des facturations, le nombre de visites et la liste des allergies sont identiques dans les deux systèmes. Si quelque chose ne colle pas sur cinq, cela ne collera pas sur cinq mille.

Qui fait quoi

Une migration réussie exige trois rôles clairs. Le fournisseur sortant fournit les données et explique leur structure. Le fournisseur entrant réalise la conversion et est responsable du résultat technique. Et la clinique — c’est la partie qu’on a tendance à sauter — tranche les questions de sens : ce qui compte comme patient actif, comment mettre en correspondance un ancien statut sans équivalent, et que faire des enregistrements qui se contredisent. Ce ne sont pas des questions techniques, et aucun fournisseur ne peut y répondre à votre place.

Il vaut la peine d’y consacrer un temps explicite. Une journée de travail de quelqu’un qui connaît les données, tôt dans le processus, épargne des semaines de corrections après coup.

Que faire des données non convertibles

Toute migration laisse un sillage : enregistrements à champs manquants, valeurs sans équivalent, documents corrompus. La tentation est de les jeter en silence. La bonne approche est de les répartir en trois tas. Ce qui peut être corrigé manuellement en quantité raisonnable — le corriger. Ce qui n’est pas critique — le consigner et le laisser. Et ce qui est critique et non convertible — le migrer comme document joint avec une note, pour qu’au moins l’information soit accessible à l’œil humain.

Ce qui importe, c’est que le troisième tas soit connu et documenté. L’écart dangereux n’est pas une donnée qui manque, mais une donnée que tout le monde suppose présente.

Que documenter

À la fin de la migration, il vaut la peine qu’il subsiste un court document décrivant ce qui a migré, ce qui n’a pas migré, comment les listes de valeurs ont été mises en correspondance, et ce que l’on sait des données qu’il n’a pas été possible de convertir. Dans deux ans, quand quelqu’un demandera pourquoi il manque une documentation d’une année donnée, ce document épargnera une journée de travail et des malentendus.

Et enfin, ce qu’on ne peut pas migrer

Une partie du savoir de la clinique n’est pas dans le système mais dans la tête des gens : qui sont les patients sensibles, pourquoi tel rendez-vous est conservé, comment se déroule tel processus. Le passage à un nouveau système est une bonne occasion d’en écrire une partie. Non pour documenter pour documenter, mais parce que pendant la migration on réexamine de toute façon chaque processus — et c’est la seule fois en une décennie où cela arrive.

Retour au blog