Logiciel Praticien & Serveur agrée santé

Bonjour,

Je suis informaticien et j’ai dans mon entourage des dentistes qui utilisent chacun un logiciel praticien différent : Julie, e-coodentist et Logos principalement. Au fil du temps, j’entends souvent des remarques positives et négatives sur chacun d’eux. On me demande souvent mon avis sur des fonctionnalités, sur des bugs.
A force de répertorier chaque remarque qu’on m’indique, je me suis dit : ‘’serait-il judicieux de réaliser un tel logiciel ?’’

J’ai commencé à me documenter sur la création d’un logiciel praticien, en voyant les pour et les contres, les difficultés auxquelles je serai confronté et comment y remédier.
Parmi toutes ces difficultés, il y en a une qui est assez douteuse car vraiment pas claire, sur chaque source que j’ai arrive à me procurer : il s’agit du serveur sécurisé santé.

Voilà ma question : quelqu’un a-t-il des informations précises sur le principe d’un serveur sécurisé ?

Si on se rend sur le site de ASIP santé, il est spécifié que toutes les données qui sortent du cabinet doivent être sur un serveur sécurisé, et dans le décret 2006-6, cela est également stipulé. Cela signifie que si le serveur est situé physiquement dans le cabinet du praticien et que celui-ci est ouvert sur internet, l’obligation du serveur sécurisé n’est plus nécessaire !!!

Pour mieux cerner le problème, prenons des exemples simples :

Un dentiste est seul dans son cabinet, il a donc un logiciel praticien installé sur son poste. Il n’a donc pas besoin d’un serveur sécurisé. Pour ne pas perdre ses données, il doit effectuer des sauvegardes à partir de son poste avec par exemple un disque dur externe.
Un cabinet dentaire a plusieurs praticiens, chacun a son logiciel installé sur son poste et pour pouvoir se partager les données, il y a un serveur en plus dans le cabinet dentaire (c’est ce que font VisioDent ,Logos). Dans ce cas là également, le cabinet n’a pas besoin d’un serveur sécurisé car les données restent dans le cabinet. Le cabinet, doit toujours, comme dans le premier cas, effectuer des sauvegardes non pas sur chaque poste mais sur le serveur avec par exemple un disque dur externe.

Prenons maintenant le cas, des nouveaux logiciels Full Web comme e-coodentist :
Le cabinet dentaire a un ou plusieurs dentistes, chaque dentiste a son poste. Dans ce cas de figure, le serveur dans le cabinet est inutile car chaque dentiste a son logiciel praticien sur internet ; par conséquent, il n’installe même plus le logiciel sur chaque poste. Avec ce système, inutile d’effectuer des sauvegardes, les serveurs d’ e-coodentist le font. Ce système permet au praticien de ne pas gérer cette contrainte d’avoir un serveur au cabinet et de vérifier que les sauvegardes se sont bien effectuées. Ce système a aussi l’avantage de pouvoir consulter ses données en dehors du cabinet, que ce soit avec un ordinateur, un smartphone ou une tablette. Cela signifie qu’e-coodentist stocke le logiciel et les données sur leur serveur comme n’importe quel site internet sauf qu’en France depuis 2006, ces données doivent être stockées sur des serveurs sécurisés.

Pour expliquer cette notion, expliquons ce que c’est un serveur.
Un serveur est tout simplement un ordinateur : si on veut avoir un petit site internet, on peut utiliser comme serveur un pc de bureau. Si vous avez des centaines d’utilisateurs de votre site internet, vous utilisez un serveur beaucoup plus puissant, c'est à dire un ordinateur fait spécifiquement à cet usage. Et enfin si vous avez plusieurs milliers d’utilisateurs, vous utilisez plusieurs serveurs en parallèle.

Ces serveurs peuvent être stockés chez vous, dans un local que vous avez loué et bien sûr ces serveurs doivent tout le temps être allumés car sinon votre site internet sera coupé.

De plus en plus d’entreprises font appel à un hébergeur qui vous fournira dans ses locaux les serveurs que vous avez choisis. Il existe énormément d'hébergeurs sur le marché. De plus ces hébergeurs proposent un niveau de sécurité accru en fonction de l’utilisation du client.

Nos logiciels de gestion de patients fonctionnent de la même façon… sauf depuis 2006 avec le décret 2006-6.

Ce décret spécifie que pour tous les logiciels ou données qui sont du domaine de la santé, seuls les serveurs sécurisés santé doivent être utilisés.
Voici le lien vers ce décret :
http://legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000000264665&dateTexte=&categorieLien=id

Il décrit ce qu’est un serveur sécurisé santé ; c’est un serveur qui doit avoir :
Un historique des données dans une période précise.
Un système sécurisé pour se connecter sur ce serveur.
Informer le praticien et le patient de comment sont stockées ces données.
et plus rien… !

La suite du décret stipule comment effectuer la demande d’agrément pour que le serveur sécurisé devienne légal en tant que serveur sécurisé agréé santé.
Cette procédure est assez longue.

De plus dans ce décret, les informations sont trop vagues : quand on parle de serveur sécurisé, est-ce uniquement les données ou également le logiciel qui doivent se trouver dessus ?
Les données doivent-elles être cryptées?

Quelle est la différence entre un serveur classique et un serveur santé si ces termes ne sont pas clairement définis ?


Par exemple, reprenons e-coodentist. Vu que l’agrément est assez long et vague à obtenir, e-coodentist a décidé d’héberger leur logiciel chez un hébergeur agrée santé, en l'occurrence IDS. De plus, comme indiqué sur leur convention d’hébergement, c’est IDS qui est tenu d’avoir l’agrément santé et si toutefois elle perdait cet agrément, c’est à IDS de trouver une solution pour e-coodentist :

http://www.ecoodentist.com/cgv/e.cooDentist_Convention_Hebergement.pdf


D’autre part, E-coodentist utilise pour l’agenda, google calendar qui expose le nom et prénom du patient, son adresse et son numéro de téléphone.
Cela signifie que ces informations ne se trouvent pas sur un serveur sécurisé et cela soulève de nouveau la question de ce à quoi correspondent légalement les données sensibles ?

Voilà, si vous avez d’autres informations sur les serveurs sécurisés santés, cela m’intéresse fortement !
Je pense à la possibilité de réaliser un tel logiciel mais avant de me lancer, autant me renseigner sur l’existant…

Merci de votre aide :)

Le concept de serveur sécurité santé date à peu prés du début du projet du Dossier Médical Personnel.
En clair, comment centraliser les données médicales d'un patient pour le traiter efficacement sans examens redondants tout en conservant une confidentialité vis à vis des assureurs, qui souhaitent aussi disposer de ces informations à des fins purement financières.
Une énorme usine à gaz qui démarre très lentement; au bout de 15 ans, il doit y avoir pas beaucoup plus de 500 000 volontaires qui doivent donner leur accord pour chaque type d'information les concernant.
Avant le DMP, il y a eu des serveurs régionaux opérationnels dans des réseaux de cancérologie et de périnatalité; cela s'est sans doute développé dans d'autres domaines, mais le souci de confidentialité demeure.
A toi de voir si tu veux que ton projet de données de santé dentaire
serve à alimenter le DMP.
Le sujet est sensible, un agrément de sécurité a été donné en 2015 pour une durée de un an.

cf google DMP

Un serveur ne peut pas être complètement sécurisé.
A partir du moment ou des datas sont exportées du cabinet via un logiciel au code source fermé, il y a doute.
Clé privée, clé public, clé serveur, celui qui écrit le logiciel n'en a cure puisqu'avant d'être cryptées, les données sont claires.
Ce qui est sur, c'est que celui qui posséderait des information médicales complètes et intimes sur un pays serait très très riche.
Pour moi, il est impossible d'avoir confiance dans un logiciel fermé qui communique via le web.
Nous pourrions utiliser un réseau maillé privé, mais c'est très cher.
Le monde a changé. Les nouvelles mines d'or, ce sont les données sur les personnes.
Le produit à vendre, c'est toi. C'est nous.

Google te vend déjà comme prospect.
Google vend des espaces de pub sur ton pc, celui là même que tu utilises pour lire ce post.
https://support.google.com/adxbuyer/answer/6138000?hl=fr

Et en plus, google peut te vendre ton profil détaillé personnel.
Corrélées à ton portable, géographie, forum, sms, email, etc.... je te laisse imaginer la discrétion.

Par contre, google n'a pas de données médicales.
Sur qu'il aimerait bien en avoir.

ps: google comme microsoft & cie

chicot29

06/04/2016 à 23h17

Ou là. Le principal problème c'est la complexité de la gestion du dossier dentaire par la sécu.
le simple passage à la CCAM a du donner des sueurs froides aux fournisseurs de logiciel. Et je ne te raconte pas la merde que ca va etre quand on va passer au tiers payant généralisé.
Ton histoire de serveur "sécurisés" c'est du pipi de chat. -)
Sans compter que quand on se sert d'un logiciel dentaire depuis des années, il est très difficile de passer à un autre, on n'en change pas sur un coup de tete !

adhoc

07/04/2016 à 01h19

Je suis d'accord avec paradoxe. Si une communication client serveur peut etre cryptée par clefs publiques et privées, en est il de meme pour les base de données des praticiens, localisées sur le serveur?.
Si des milliers de hackers qui shuntent le serveur par deny of services-plein de connexions simultanées- ont quand meme du mal a piquer des fichiers, rien n’empêche un informaticien reseau qui travaille dans la société de piquer les bases de données!
On note que les grosses fuites actuelles,surtout financières, qui ont défrayé les media, par les "lanceurs d'alerte", sont dues a des informaticiens qui ont eu leurs infos "sur place".
Ma question a marcoinformatique
"peut on, a partir d'une clef fournie par le client, crypter par exemple une bbd paradoxe ou mysql et ainsi rendre impossible la lecture des tables par le personnel de la société de stockage de fichiers?"

Bonjour,

Merci beaucoup pour toutes vos réponses.
J'essaie d'avoir le maximum d'informations sur le serveur sécurisé car cela donne vraiment l'impression que c'est assez abstrait.

En ce qui concerne la question de "adhoc" sur le cryptage de données directement à la source, cela est possible mais très coûteux en terme de performance.

Il sera nécessaire à chaque requête de décrypter pour une consultation et de crypter pour chaque enregistrement et je ne parle même pas de chaque mise à jour d'un enregistrement.

Cette manipulation sera forcément effectué par l'application web coté serveur. A un moment, donné le programme aura forcément une fonction de cryptage et de décryptage accessible par le personnel de l'entreprise.

Donc ce n'est pas une bonne idée même pour le personnel car la maintenance sera compliquée.

Par contre sur la plupart des projets, il y a toujours un service production qui ont accès aux serveurs et donc aux "vrais" données. Ils interviennent si il y a un soucis par contre le reste du personnels n'a pas besoin d'avoir accès à ces machines.

Comme cela les développeurs, la moa utiliseront une autre plateforme similaire à la production mais avec des données factices.

Si il y a des fuites, on sait rapidement d'ou cela vient.

Il ne faut pas oublier que de nombreux projets ont recours à des prestataires, des gens qui viennent pendant quelques mois.

Ce qui est choquant, c'est que j'ai vu chez certains clients (même des très grosses entreprises) mettre à la disposition de tout le personnel, y compris les prestataires, l'ensemble de la base de données de production...

http://www.usine-digitale.fr/article/donnees-de-sante-ce-que-change-la-loi-du-26-janvier-2016.N376544

L'environnement est évolutif, on n'a pas encore tout vu.
Avec le tiers payant, nos fichiers patients contiendront des informations concernant leurs mutuelles.
Les assureurs et les mutuelles veulent imposer leurs volontés.

adhoc

07/04/2016 à 13h29

Merci beaucoup marcoinformatique pourb tes excellentes explications techniques.
Je suis programmeur php/mysql/javascript a mes heures de détente, je connais les petits serveurs dédiés mais pas les gros systemes datacenter/grosses bdd de prés!
Donc un un cryptage complet des bdd est illusoire, coute trop cher en ressources par decryptage/cryptages successifs a chaque requete.
La sécurité complete de nos bases n'existe donc pas coté serveur, on dépend quand meme des humains qui y travaillent.

Ce que les gens doivent savoir :-)

Les systemes de securisation visent donc a mettre des murailles entre serveur et hackers, cest tout.
Dans l'histoire, la chute de Constantinople chrétienne a été permise par un traitre qui a donné un plan avec le talon d'achille: les fosses d'aisance des soldats de l'epoque....

Il y a très peu de domaine ou l'homme n'intervient pas à un moment dans la chaîne.

Le vrai problème c'est comment cela est géré..

merci acid pour le lien.

Cela montre que la procédure d'agrément évolue encore.

J'ai envoyé un mail à ASIP Santé pour avoir plus de détail et contacter plusieurs sociétés qui font de l’hébergement de données santé.

Je vous tiens au courant :)

Bonjour !

J’ai pu avoir d’autres informations sur le serveur sécurisé, pour que mon projet soit en adéquation en fonction du décret.

Le cryptage des données :
Cette information va intéresser “adhoc”. Les données sensibles sont cryptées par le logiciel et non directement par la base de données.
A l'enregistrement en base de données, le logiciel crypte l’information sensible et au moment de la lecture, le logiciel décrypte l’information.

De plus, chez l’hébergeur, l’application se trouve sur un serveur et la base de données se trouve sur un autre serveur.

La personne qui s’occupera de la maintenance de la base de données verra uniquement des données cryptées et il ne pourra pas la décrypter car la clef de décryptage sera sur le serveur contenant le logiciel.

Ensuite la méthode de décryptage, c’est l’entreprise qui réalise l’application (dans mon cas moi).

Je trouve une solution simple et efficace.

Sur plusieurs projets auxquels j’ai participé, on utilise souvent une autre technique.
Les informations ne sont pas cryptées mais on a plusieurs bases de données.
Par exemple, une base de données avec les actes médicaux et une autre base de données(ldap) avec le nom, prénom, téléphone, adresse etc.

Ainsi sur la base de données contenant les actes médicaux, il n’y a que des identifiants et pas de nom.

La connexion à l’application :

L’application doit communiquer en “https” et la connexion doit s'effectuer par un certificat électronique installé sur le navigateur internet ou un login et mot de passe avec une identification forte.


Par exemple :
L’utilisateur tape son login et mot de passe.
Il valide, une page s’affiche demandant de renseigner un identifiant.
L’utilisateur reçoit un sms contenant un identifiant valide quelques minutes.
L’utilisateur renseigne l’identifiant reçu par sms et valide.
Il est connecté.


Voici les informations les plus importantes à prendre en compte pour réaliser le logiciel.

L’hébergeur vérifie si l’application respecte toutes les recommandations. Si c’est le cas, l’entreprise (ici moi) a le droit de mettre son application en ligne.


Pour avoir tous les détails voici le lien vers asip santé :
http://esante.gouv.fr/services/referentiels/securite/formulaires-du-referentiel-de-constitution-des-dossiers-de-demande-d

Le document parlant de la sécurité de l’application est le document “P6”.

Maintenant j’ai la majorité des réponses à mes questions :).

Je vais bientôt ouvrir un sujet sur eugenol, vous exposant mon projet et vous demandant si vous êtes actuellement content de votre logiciel, ce que vous attendez d’un logiciel dentaire…

Bonne journée et à bientot ;)