Logo ANAP
Ce site requiert l'activation de javascript pour être utilisé, merci de l'activer.
S'abonner

Avis d'experts

Comprendre comment organiser la reprise des données lors d’un changement de logiciel

 4209 vues

Cet avis d'expert a été rédigé par Patrick BLANCHET.

Solution source : l'application qui va être abandonnée. Elle contient les données de l'activité passée de l'établissement. Les données qu'elle contient devront être, selon les cas, détruites, archivées pour simple consultation ou récupérées dans la nouvelle solution cible.

Contexte et problèmes : un changement de DPI pose quatre grands problèmes :

  • La gestion du changement…mais il est peut-être espéré (problèmes de performances, d’ergonomie…)
  • L’adéquation aux nécessités du projet des contrats passés avec les éditeurs, et surtout avec l’éditeur de la solution source. Problème d’anticipation
  • La pérennité de l’accès aux données produites dans le logiciel source, en partie liée à la nécessité d’accès pour des problèmes de santé publique ou médico-légaux. C’est un problème d’Archivage
  • La reprise des données dans le nouveau logiciel : c’est une démarche de migration de données produites dans un système informatique source (qui va être abandonné après archivage) vers un nouveau système cible (matériel et surtout logiciel). C’est la question posée dans son aspect organisationnel et non technique

Les pistes (il s'agit d'un projet dans le projet)

L’équipe, qui peut s’appuyer sur les ressources humaines de la cellule de crise définie dans le cadre du PRA, va :

  • Définir les données « pertinentes » donnant une bonne connaissance du parcours connu du patient, pour assurer l’optimisation de la continuité des soins après le changement de logiciel. Ce travail doit être fait le plus possible en amont, et aurait même dû être fait lors de l’entrée en production du système source, pour que le paramétrage facilite au mieux la saisie structurée des données, appuyée au mieux sur des nomenclatures qui serviront aussi au système cible. Exemples : les « antécédents », les actes chirurgicaux, les séjours et les consultations réalisés, les documents et courriers produits lors de ces venues…le traitement personnel au long cours connu et actualisé…les événements indésirables attachés au patient, les iatrogénies constatées…
  • Définir les données non pertinentes au parcours patient, à archiver seulement
  • Définir si les données reprises devront être taguées comme telle, voire soumises à validation unitaire pour les données structurées
  • Valider les tests fonctionnels unitaires par donnée une fois la solution technique définie : une donnée est bien reprise de la source dans la cible, au besoin en passant par un entrepôt intermédiaire
  • Valider les tests fonctionnels unitaires par dossier, ce qui permet aussi de vérifier que le système cible répond bien aux attentes avant la migration globale
  • Valider la migration sur des dossiers entiers : exhaustivité difficile, tirage au sort…
  • Archiver les tests et rester en suppor

Synthèse

  • « La reprise peut être longue à développer et à tester, surtout si les schémas de base de données sont structurellement différents et s’il y a beaucoup de nettoyage à faire (formatage, fusion/éclatement de données, …). Mais la reprise des données une fois les tests passés doit être rapide pour ne pas avoir de problème d’actualité des données reprises, au moins à titre unitaire « dossier » : la migration des données à J1 ne sera plus forcément « up to date » si le démarrage du nouveau DPI se fait à J+30. L’organisation des migrations peut donc aller du « big bang » pour une petite structure à un pas à pas pour les gros ES.
  • La reprise des données ne doit pas masquer la reprise aussi nécessaire de tout ou partie du paramétrage
  • La reprise des données ne doit pas masquer la reprise aussi nécessaire de tout ou partie des liens applicatifs ou techniques
  • Donc il faut :
    • Anticiper : les données à reprendre, structures des données, les bases…avec les utilisateurs, les éditeurs et le SIH
    • Organiser : la Cellule de « Crise »
    • Réagir et arbitrer : les tests, les retours techniques peuvent imposer des arbitrages
    • Accompagner : les informaticiens aussi, les utilisateurs d’abord
    • Choisir les éditeurs et contractualiser pour qu’ils soient bien en appui d’un projet de ce type que tous les ES risquent de rencontrer.
  • Points d'attention :
    • Lors de l'acquisition d'une solution informatique, les conditions techniques et financières du transfert de données en fin de cycle doivent faire partie du contrat initial. Si cette précaution avait été prise lors de l'acquisition de la cible, les conditions techniques feront partie de l'appel d'offre pour la solution candidate à la reprise des données.
    • Le respect de la charte BP6 par l'établissement et les éditeurs est un élément facilitant de la reprise des données.

Retrouvez le catalogue des productions des expets HN.

Cette réponse vous paraît-elle utile ?
Date de parution : 11/01/2015

Commentaires - Soyez le premier à déposer un commentaire

Pour ajouter un commentaire vous devez vous identifier

Vous êtes actuellement sur la page consacrée à Comprendre comment organiser la reprise des données lors d’un changement de logiciel (Avis d'experts) qui traite de Technique, Planifier et cadrer, Retirer l'ancien système, Gérer la connaissance, Etablissement sanitaire public, Chef de projet, Mutualisation.

Vous êtes perdu ?

go_to_top

Vous êtes actuellement sur la page consacrée à Comprendre comment organiser la reprise des données lors d’un changement de logiciel (Avis d'experts) qui traite de Technique, Planifier et cadrer, Retirer l'ancien système, Gérer la connaissance, Etablissement sanitaire public, Chef de projet, Mutualisation.

Vous êtes perdu ?