L archivage dans KaliSil Table des matières 1 Problématique... 2 1.1 État des lieux... 2 1.2 Problématique... 2 2 Périmètre légal... 2 3 Périmètre technique... 3 3.1 Base de données... 3 3.2 Fichiers... 3 4 Pistes envisagées... 4 4.1 Extraction de données... 4 4.2 Traces par années... 4 4.3 Conservation de données minimalistes... 4 5 Questions ouvertes... 5 5.1 Que faut-il archiver?... 5 5.1 Combien de temps avant d archiver?... 5 5.2 Comment conserver la cohérence des données?... 5 L archivage dans KaliSil avril 2016 Page 1 / 5
1 Problématique 1.1 État des lieux L archivage comme actuellement défini dans KaliSil est ce qu on appelle un archivage «logique» des données : les demandes sont à l état «archivé», à la différence d un archivage «physique» : les données sont déplacées dans un autre lieu. La politique d archivage logique actuelle est la suivante : Toutes les demandes validées biologiquement et soldées en facturation, sont archivées si elles n ont pas été accédées depuis un temps paramétrable entre 6 et 24 mois. Une demande archivée est uniquement accessible aux ayant-droit, chaque accès à une demande archivée est tracé. Une demande archivée peut être désarchivée par les ayant-droit, ce qui a pour effet de la repasser à l état «validée» pour la période suscitée. L ensemble des données d une demande archivée (base de données + fichiers + scans) restent sur le serveur de production. 1.2 Problématique L archivage dans son état actuel conserve l ensemble des données de la production sur le serveur principal. Le volume des données de production (i.e. tout ce qui est lié à une demande) augmente donc au minimum de manière linéaire, voire plus encore selon la croissance du laboratoire. Le principal objectif de l archivage physique est donc de supprimer des données de production (avec un déplacement éventuel dans un autre lieu défini) afin de maîtriser le volume de données géré par le serveur de production. Le gain pour le serveur, en dehors du gain d espace disque, est également un gain de performances car la base de données augmentera moins, voire pas du tout. 2 Périmètre légal Légalement, l archivage «logique» est suffisant. En effet, il est précisé dans les documents abordant la question la durée légale pendant laquelle les données doivent être accessibles et dans quelle mesure elles peuvent être visualisables mais rien n impose de laisser les données sur le serveur dans leur état initial. Les données accessibles au-delà de 3 ans concernent uniquement les résultats et la facturation appliquée (source : SH GTA02). L ordonnance est à conserver pour les besoins de la facturation, mais au-delà de 18 mois peut être supprimée définitivement. Le journal légal est également à conserver pour 10 ans. On peut en déduire que les données minimales de KaliSil à conserver au-delà de 3 ans sont : L identité du patient La facturation appliquée Les fichiers PDF liés à la demande (compte-rendu, facture, résultats sous-traités, ) Les analyses réalisées (journal légal) Le reste des données (traces complètes de la demande, tubes utilisés, scans d ordonnance, colisage, réactifs utilisés, ) ne sont pas obligatoires. L archivage dans KaliSil avril 2016 Page 2 / 5
3 Périmètre technique 3.1 Base de données La base de données est divisée en 2 parties ayant approximativement la même taille : Les traces Tout le reste (paramétrage et production de KaliSil) La base de données est relationnelle : toutes les données sont liées entre elles. Exemple : Une demande est liée aux analyses la composant, elles-mêmes liées à leur fiche de paramétrage Si on supprime cette demande de la base de données (ou si on la déplace ailleurs), il n y a plus de liaison entre la demande et sa fiche de paramétrage On n a donc plus de possibilité de savoir que cette analyse a été réalisée ce jour-là depuis la base de production Par contre on peut toujours accéder à la demande archivée pour la consultation L archivage physique autorise la consultation par un moyen ou par un autre. Le principal problème concerne la recherche et l exploitation des données archivées. Il ne sera plus possible de sortir une statistique de production détaillée sur des données archivées puisque vu du serveur de production, elles ne seront plus là. L autre problème concerne les liaisons entre les demandes : Une demande est facturée à un correspondant demandeur Cette demande est liée à 1500 autres dans une facture globale correspondant Si on supprime (ou déplace) une partie de ces demandes, la facture dans son ensemble devient incohérente Il en va de même pour tout ce qui lie 2 demandes : règlements multiples, groupes sanguins, admissions, L archivage physique a donc une nécessité de cohérence dans sa sélection des demandes à archiver. 3.2 Fichiers Les fichiers liés à la production sont les suivants : Toutes les impressions stockées en PDF Les scans liés en image Ces fichiers sont actuellement stockés au long terme dans des archives ZIP mensuelles, ce qui permet de les consulter indéfiniment. L archivage dans KaliSil avril 2016 Page 3 / 5
4 Pistes envisagées Plusieurs pistes sont à l étude concernant ce sujet d archivage qui devra obligatoirement être traité prochainement. Ces pistes peuvent être cumulatives. 4.1 Extraction de données Un outil a été testé pour permettre d extraire les données de production d un site sur une année entière. Ces données (tables de production, traces, fichiers, scans) sont supprimées du serveur principal et exportées à un format exploitable sur un support externe. Il est ensuite possible d accéder au travers d une interface minimaliste à ces données pour faire une recherche de patient (nom, prénom ) ou de date et d accéder à chaque demande avec les informations de base (identité patient, facture appliquée) ainsi que tous les fichiers et scans joints. Aucune donnée technique ou de paramétrage n est exportée. Ces données peuvent être enregistrées sur un support (DVD, disque, serveur). Il n est plus possible d exploiter de quelque manière que ce soit les données extraites sur le serveur de production. 4.2 Traces par années La base de donnes de trace peut facilement s adapter à un découpage par années car les données en trace de changent pas. La base pourrait donc être annuellement déplacée vers une base «Traces-2012» lors du passage en 2013 où en 2014. Cela permet d éviter l augmentation perpétuelle de la taille de la base (donc de performance) mais ne règle pas la volumétrie sur le disque du serveur. Les anciennes bases pourraient être supprimées au bout de X années par la suite, lorsqu on estime ne plus avoir besoin d y accéder. 4.3 Conservation de données minimalistes Quelle que soit la méthode utilisée pour supprimer les données du serveur de production, une solution au problème de statistiques consisterait à enregistrer une version «réduite» des demandes supprimées, mais tout de même exploitables. Cela conserverait par exemple la facture (4 parts), les analyses réalisées, et l identité du patient ce qui permettrait de toujours pouvoir sortir le chiffre d affaires sur une année archivée ou le nombre d analyses réalisées. Les données conservées devraient être minimalistes pour ne pas perdre l intérêt de l archivage. L archivage dans KaliSil avril 2016 Page 4 / 5
5 Questions ouvertes Au vu de ces différentes pistes, plusieurs questions restent en suspens et nécessitent débat. 5.1 Que faut-il archiver? Quelles données conserver pour la consultation sur un support tiers? Quelles sont les statistiques à conserver sur les années archivées? Quelles sont les données que l on peut purement et simplement supprimer? 5.1 Combien de temps avant d archiver? Pour chacune des données ci-dessus, combien de temps laisse-t-on passer avant de procéder à l archivage? 5.2 Comment conserver la cohérence des données? Dans le cas de la facture globale précédemment évoqué : faut-il attendre que toutes les demandes de la facture soient archivables pour archiver l ensemble du «groupe»? L archivage dans KaliSil avril 2016 Page 5 / 5