Discussion :

[sekaijin]

Bonjour

j'ai besoin de faire rapidement un démonstrateur pour un entrepôt centralisé de fichiers.

Il s'agit de compte-rendu médicaux (bio, génétique, imagerie, médecine etc)
Donc l'aspect sécurité sera une enjeux important.
Mais ce n'est pas sur ce point que le démonstrateur doit intervenir

Aujourd'hui chaque "producteur" (un labo une radio, un scanner etc) produit ces comptes rendus dans son logiciel et les stocke localement
mais il doivent entrer dans le dossier médical du patient donc une copie est envoyé au logiciel de gestion des dossier médicaux

l'outil d'analyse des interaction médicamenteuse en a besoin donc on lui envoie une copie
l'outil de validation des actes (ce qui permet de facturer) en a aussi besoin il en reçoit une copie

etc. Du coup on constate que le document est copié un nombre important de fois (très important)
Nous avons proposé que les document produit soient tous enregistré dans un même espace.
Mais beaucoup considèrent que ce n'est pas possible pour plusieurs raison.
Un labo qui délègue une analyse à un autre est le seul à pouvoir délivrer le compte rendu les labo s'opposent donc à ce que les CR soit ailleurs que dans leur espace.
Nous avons expliqué que cela était aussi possible avec une gestion centralisée mais visiblement sans le voir...
autre objection la volumétrie. nous avons bien tenté d'expliqué qu'on allait diviser par 30 environs la volumétrie du au fait qu'on ne copie plus beaucoup ne croient pas qu'on puisse gérer 100 000 000 de document par an

Nous avons pensé à MongoDB et GridFS
Côté techno avez vous connaissance de la mis een place d'une gestion de ce type même hors monde de la santé ?

merci

[SQLpro]

Pour information j'ai beaucoup utilisé SQL Server et le type de données FILESTREAM pour des GED à haut volume avec indexation du contenu des documents électronique.
Notamment dans le domaine de l'assurance ou la volumétrie des doc était de plusieurs dizaine de To par an.
https://docs.microsoft.com/fr-fr/sql...l-server-ver15

Si cela n'est pas suffisant, SQL Server permet d'utiliser des bibliothèques de stockage de document via RBS (Remote Blob Storage). Et nous avions envisagé cela pour une grosse compagnie d'assurance, mais le volume attendu pour passer à RBS c'est un minimum de 100 To voire beaucoup plus...
https://docs.microsoft.com/fr-fr/sql...l-server-ver15

Dans le monde de la santé, le point critique est la sécurité qui est généralement mal gérée actuellement dans la plupart des solutions NoSQL.... et est en force dans SQL Server (chiffrement TDE, salage automatique, clés hiérarchisées dépendantes, chiffrement avec boitier externe (HSM), chiffrement de bout en bout avec ou non enclave sécurisé...)
https://docs.microsoft.com/fr-fr/sql...l-server-ver15
https://docs.microsoft.com/fr-fr/sql...l-server-ver15
https://docs.microsoft.com/fr-fr/sql...l-server-ver15
https://docs.microsoft.com/fr-fr/sql...l-server-ver15
https://docs.microsoft.com/fr-fr/sql...l-server-ver15




A +

[sekaijin]

merci pour cette réponse.

Cordialement

[mach1974]

Vous pouvez aussi utiliser HADOOP et HIVE dans le domaine bancaire, ça se fait pour un TO de donnée . Hive permet le mode SQL sur HADOOP

[SQLpro]

ATTENTION : HADOOP comme HIVE ne supportent pas les contraintes d'unicité.... C'est le problème de tous les services distribués comme donc dans tout le noSQL en général...

A +