Bonjour,

Je développe un logiciel sous Java, jusqu'à présent je me contentais de sauvegarder mes données grâce à la Sérialisation où mon Objet ( Patient )  contenant d'autres Objets ( Infos personnelles, Antécédents, ... ) était sauvegardé dans des fichiers ( 1 fichier = 1 Patient ).

À partir de maintenant je voudrais créer une base de donnée pour que la sauvegarde soit plus simple à réaliser, et que je puisse faire des modifications de mes données ( Infos personnelles, Antécédents, ... ) sans avoir à recréer un fichier Patient entier. Il est peut-être possible de le faire grâce à la Sérialisation mais je n'ai pas vraiment cherché à le savoir car je souhaite de toute manière créer une base de donnée.

Bref, ce que j'aimerais, serait de savoir quelle base de donnée pourrait être le plus intéressant à utiliser pour mon projet. J'ai déjà utilisé Oracle avec Java mais il me semble que pour un usage professionnel avec un gros stockage disponible il faut payer. Mon projet sera dans le futur un logiciel en vente gérant la patientelle de plusieurs milliers de professionnels dans le meilleur des cas, mais dans tous les cas 1 seul professionnel peut gérer plus de 500 patients à lui tout seul, ce qui fait que la base de donnée doit pouvoir contenir beaucoup de donnée tout en étant gratuite ( en tout cas au début ).

Au final, parmis Oracle, MySQL, PostgreSQL, MongoDB, etc, quelle serait la base de donnée sur laquelle je devrait me tourner au début ?

Merci

PS : Si jamais il est intéressant, dans mon cas, de gérer son propre serveur je suis également preneur.

PPS : Je ne connais pas tous les termes des bases de données, je viens ici pour m'informer sur ce qui me serait utile, ne me jeter pas la pierre si vous voyez des incohérences dans mes propos.

-
Edité par Mrshlle 6 octobre 2018 à 23:02:00

Bonjour,

La question est très vaste ...

Il est clair que de stocker des données sérialisée dans un fichier par patient n'est pas idéale. Utiliser un SGBD me paraît plus pertinent.

Au vu des quelques éléments donnés, une base de données relationnelle me semble tout à fait adaptée. PostGreSQL pourrait être une réponse à première vue. Je ne pense pas qu'une solution NoSQL (tu as cité MongoDB) soit conseillée ...

Après, pour la question du serveur, il faut savoir si le logiciel en question sera un logiciel local ou distant. Vas-tu développer une solution à installer sur chaque poste avec sa propre base de données, ou un logiciel client/serveur avec une base de données distante, ou un logiciel full-web ...

Merci pour ta réponse,

Mon logiciel va être un logiciel à installer sur son propre poste, je ne me suis jamais posé la question de la base de donnée propre au logiciel. Je ne connaissais pas ça, je pense que ça pourrait être intéressant car les patients stockés doivent rester assez confidentiels.

Au début je pensais avoir ma base de donnée stockée dans des serveurs qui seraient à termes dans mes locaux, dans tous les cas, que ma base de donnée soit stockée chez moi ou chez eux, quel serait le mieux ? Qu'apporte PostGreSql de plus qu'une autre base de donnée ?

De plus, je développe également une application à côté pour pouvoir accéder au logiciel sur mobile, de ce fait il me faudra une API pour appeler ma BDD que ce soit avec mon logiciel ou mon application, est-ce qu'une base de donnée en particulier serait plus approprié ou cela ne change rien au choix ?

Merci

Dans quel langage développes-tu ?

Marshlle a écrit:

Qu'apporte PostGreSql de plus qu'une autre base de donnée ?

C'est un SGBDR stable et robuste qui respecte bien la norme SQL. Il est libre et gratuit, et dispose d'une grande communauté. Il n'a rien à envier à Oracle ou MS SQL Server ...

Marshlle a écrit:

je développe également une application à côté pour pouvoir accéder au logiciel sur mobile, de ce fait il me faudra une API pour appeler ma BDD que ce soit avec mon logiciel ou mon application

Attention tu mets le doigt dans un domaine plus complexe ...

Tu ne pourras pas accéder à une base de données locale (directement sur le poste du client) depuis l’extérieur (application mobile). Il faudra mettre en place un système de synchronisation entre la base locale et une base distante accessible depuis Internet ...

Par ailleurs, il faudra assurer une synchronisation au cas où le le poste local du client n'a pas d'accès Internet (ponctuellement ou non) ...

Selon ce que le client pourra faire depuis l'application mobile (consulter et/ou modifier) et ses exigences sur la fiabilité des données consultées, l'architecture de l'ensemble devra être adaptée ...

Dans tous les cas tu auras besoin d'une base de données hébergées sur un serveur, qui dispose d'un système d'API (type REST). Via l'API tu pourras interroger la base depuis l'application mobile.

La grosse question c'est comment sera tenues à jour cette base, notamment dans le cas où le client n'a pas d'accès Internet sur son poste local ... et comment les données du poste local seront mises à jour si le client peut agir sur ses données depuis l'application mobile ...

-
Edité par Benzouye 7 octobre 2018 à 18:32:42

Pour le logiciel c'est en Java, pour l'application mobile on verra, pour l'instant j'apprend les différentes technologies que je trouve.

J'avoue que je ne pourrais pas répondre aux questions que tu me pose actuellement, je pense que faire des sauvegardes régulières peut être une bonne approche mais n'y connaissant pas grand chose je ne sais pas vraiment.

De base je pensais faire en sorte de pouvoir accéder au logiciel sur ordinateur en ligne ou non, j'avais donc déjà en tête qu'un professionnel peut enregistrer sur son PC puis, s'il se connecte en ligne, un message s'affiche pour lui signaler de faire la sauvegarde des patients qu'il aura ajouté hors ligne. Dans ce cas créer directement une base de donnée en ligne et une locale serait certainement plus approprié, dans le cas ou l'utilisateur est connecté à internet directement sauvegarder en ligne sinon en local.

Donc dans le cas où l'utilisateur n'aura pas accès à internet, lui laisser un message lorsqu'il se connecte pour sauvegarder en ligne directement en comparant les deux bases de données de l'utilisateur.

Si je récapitule, tu me conseilles d'utiliser pgSQL et il serait mieux de créer une base de donnée en ligne, gérer par un serveur ainsi qu'une base de donnée locale gérer par l'ordinateur de l'utilisateur.

-
Edité par Mrshlle 7 octobre 2018 à 18:58:50

Marshlle a écrit:

tu me conseilles d'utiliser pgSQL

Oui, au moins pour la partie serveur. Côté local (et app mobile), il n'est pas être pas nécessaire d'installer PostGreSQL, peut-être qu'un simple SQLite pourrait suffire.

Marshlle a écrit:

il serait mieux de créer une base de donnée en ligne

Ce n'est pas que cela serait mieux, c'est obligatoire si tu veux utiliser une app mobile ... Car l'app mobile ne pourra pas se connecter sur la base de données locale du client ...

Discussion intéressante. Mais avant de choisir la technologie, il faut bien définir le périmètre. Benzouye t'as déjà largement aider à débroussailler à le terrain, et je vais y rajouter mon petit grain de sel

Déjà en parlant de "patient", cela fait sonner dans ma tête : attention à la protection des données. En effet, si on parle bien de données médicale, il s'agit de données sensible ! Si tu héberge toi même les données, alors tu en sera responsable ! Il faut donc bien prévoir tout l’aspect sécurité du logiciel, de la base de données, des serveurs etc... Si les données sont sur site, ce n'est plus directement de ta responsabilité, mais de celui qui installe le logiciel.

Concernant le type de base de données, il y a différente approches :

- la sérialisation. La plus basique. Trop surement. Car il faut charger et réécrire toute la fiche pour une simple modification. La recherche et quasiement impossible (il faudrait ouvrir et lire chaque fiche une à une), et enfin la sauvegarde / restauration en cas de problème peut êtr difficile (quand on copie le dossier, comment s'assurer que tous les fichiers soient bien copiés, dans leurs totalité, et sans erreur ?)

- Les base de données NoSQL. Leur avantage est de pouvoir modifier des fiches sans les réécrire dans leur totalité, et d'avoir une vraie procédure de sauvegarde. par contre, la recherche peut être limité, du fait que les schéma ne sont pas fixe entre toutes les fiches. De plus, elles sont généralement faite pour avoir de la disponibilité, au détriment de l'intégrité des données (pour une requête, il vaut mieux avoir une réponse incomplète / fausse, que pas de réponse du tout). Et ça, ce n'est pas forcément acceptable pour tous les projets.

- Une base de données SQL. L'avantage est d'avoir des données structurées, sur lesquelles ont peut faire des requêtes complexes. Elle s'assure aussi de pouvoir avoir des données toujours valides. L'inconvénient est d'être généralement un SPOF (single point of failure). Si la base de données tombe, plus rien ne marche (bien qu'on puisse limiter cela avec des base de données répliquées). PostgreSQL / Oracle / MSSQL Server sont particulièrement adapté aux serveurs, car ils peuvent gérer plusieurs requêtes simultanément. SQLite est quand à lui mono-connexion, mais peut être intégré à une application (c'est le plus indiqué pour avoir une base de données embarquée dan une application).

Clairement, comme Benzouye, je pousserais vers du SQL.

Pour l'architecture globale, je ne suis pas aussi catégorique : si tu veux une app mobile, tu n'es pas obligé d'avoir la base de données en ligne !

Pour comprendre, il faut revenir aux bases.

Le plus simple est effectivement  d'avoir un serveur accessible par internet. Ce serveur a une addresse IP publique direct, et une adresse DNS ( http://monsite.com/ ). Ainsi, tout ordinateur / mobiel connecté à internet pour l'interroger.

Si tu souhaite que l'application soit installé directement chez l'utilisateur, c'est le PC où sera installé le logiciel qui fera officle de serveur. Il faut donc que l'app Mobile puisse se connecter dessus. Ca veut dire, rendre le logiciel installé accessible depuis internet. Au menu: récupération de l'IP publique de la connexion internet, configuration de redirection de ports etc... Enfonçons les portes ouvertes : c'est quasiment impossible de demander à un utilisateur lambda de faire ce genre de chose directement. Mais on peut l'y aider.

L'idée, et de créer un serveur sur internet, qui ne fait que de la redirection. En somme un proxy. Le schéma est le suivant :

- on a un serveur globale, accessible sur internet

- le logicel installé chez l'utilisateur se connecte au serveur

- le mobile se connecte sur le serveur

- le serveur fait transiter les informations du mobile vers le logiciel installé chez le client, et inversement

Grace à ça, aucune donnée sensible n'est stocké / géré par ce serveur. Mais ça reste un gros boulot, car ce serveur doit avoir la liste des logiciel installé, et des mobiles autorisé à y accéder de manière sécurisée (chiffrement  de bout en bout par exemple).

-
Edité par Sebajuste 8 octobre 2018 à 10:59:13

Sebajuste a écrit:

rendre le logiciel installé accessible depuis internet

Cela impose de laisser le poste local allumé et connecté à Internet en permanence si l'on veut y accéder depuis l'extérieur ... Je ne suis pas certain que ce soit envisageable lorsque l'on parle de profession libérale ... à voir ...

-
Edité par Benzouye 8 octobre 2018 à 11:03:45

Effectivement, tout le monde ne le fait peut être pas pas...

Ceci dit mon père est médecin, et c'est comme cela qu'il procède. L'une des machines fait office de serveur sur le réseau local, et reste allumé pour que les autres machines du réseau puisse l'interroger.

Bonjour Sebajuste et merci pour ton commentaire,

Tout ce que tu dis est très intéressant mais c'est vrai qu'un professionnel ne pensera certainement pas à laisser un poste ( du moins s'il est fixe ) allumé lorqu'il n'est pas à son cabinet. Cela serait contraignant pour lui et pour moi de devoir lui demander de le faire.

Je pense plutôt partir sur une base de donnée stockée sur mes serveurs ainsi qu'une en locale uniquement lorsque l'utilisateur n'est pas connecté à internet. De cette manière il n'aura qu'à renvoyer les informations ajoutées lorsqu'il était hors connexion.

Sebajuste a écrit:

Déjà en parlant de "patient", cela fait sonner dans ma tête : attention à la protection des données. En effet, si on parle bien de données médicale, il s'agit de données sensible ! Si tu héberge toi même les données, alors tu en sera responsable ! Il faut donc bien prévoir tout l’aspect sécurité du logiciel, de la base de données, des serveurs etc... Si les données sont sur site, ce n'est plus directement de ta responsabilité, mais de celui qui installe le logiciel.

Tu fais bien de le préciser car c'est quelque chose de primordiale dans mon projet, tout doit être extrêmement protégé. C'est pourquoi l'idée de donner la responsabilité au client me paraissait intéressant pour ne pas avoir trop de problème de mon côté. Malgré tout, étant donné que je vais m'occuper de tout gérer au sein de mes serveurs, il faudra évidemment que j'apprenne à crypter et protéger mes données. Si vous avez des cours sur lesquels je pourrais m'appuyer pour apprendre tout ça n'hésitez pas.

Merci pour vos réponses, je pense partir sur PostGreSQL, avec une base de donnée stockée dans un serveur pour tout gérer ainsi qu'une plus petite stockée en local pour la connexion hors ligne. Pour la plus petite du SQLite du coup ? Une idée d'une autre BDD intéressante pour un petit stockage ?

Je ne connais pas le soft utilisé dans le cabinet de mon père, mais je sais qu'il est conçu par Thales. Autant dire pas des débutants (même si ils poussent de plus en plus vers la migration vers le cloud, donc sur leurs propres serveurs). Mais ils ont les moyens.

Car si tu veux héberger toi même les données, il va falloir passer par l'administration et les certifications : http://www.dsih.fr/article/2758/certification-hebergement-donnees-de-sante-un-nouveau-modele-pour-les-infogereurs.html 

De plus, travailler en local sans accès à internet est très difficile : comment synchroniser deux modifications différentes qui ont eu lieu sur deux bases de données locales vers la base de données centrale ? Ce genre de problématique n'est pas pris en compte par les base de données, et ne peut être résolu qu' "à la main" (à la manière d'un git merge après un pull request; si tu connais). Et ça sera bien plus compliqué pour l'utilisateur que de laisser un PC allumé...

-
Edité par Sebajuste 8 octobre 2018 à 22:41:47

C'est vrai que n'ayant que parlé de "professionnel" et de "patient" j'ai laissé un doute planer autour du sujet, ici il s'agit de médecine non conventionnée et donc non reconnue réellement par l'état. Quant aux données, il est donc assez libre de les stocker où bon nous semble, bien qu'il faille garder en vue la confidentialité de chaque patient.

Pour ce qui est de la sauvegarde en local vers la sauvegarde en ligne, ma vision était la suivante :

 - L'utilisateur est hors ligne et enregistre ses patients sur sa base de donnée locale;

 - L'utilisateur retourne sur le logiciel mais cette fois-ci en ligne, le logiciel va donc vérifier la base de donnée locale et celle en ligne pour voir s'il y a concordance des patients. Si non, un message va s'afficher ainsi qu'un bouton permettant de simplement enregistrer le/s patient/s ajouté/s hors ligne de la même manière qu'il aurait ajouté s'il avait été directement en ligne;

 - Lorsque l'utilisateur est en ligne, lors de la connexion, j'imagine une synchronisation automatique des patients en ligne sur la BDD locale afin de toujours avoir accès aux patients.

Pour ce qui est de la synchronisation de deux bases de données locales, j'imagine que s'il est possible de requêter depuis deux postes sur la BDD en même temps il doit être possible d'y créer plusieurs patients en même temps lors de la synchronisation.

Bien sûr si je me trompe dites le moi.

Malgré tout je pense en avoir appris assez par rapport à mon principal sujet et je pense donc pouvoir clore ce sujet, j'attends bien sûr ta réponse Sebajuste :).

Merci Benzouye et Sebajuste pour vos réponses.

Marshlle a écrit:

Pour ce qui est de la sauvegarde en local vers la sauvegarde en ligne, ma vision était la suivante :

 - L'utilisateur est hors ligne et enregistre ses patients sur sa base de donnée locale;

 - L'utilisateur retourne sur le logiciel mais cette fois-ci en ligne, le logiciel va donc vérifier la base de donnée locale et celle en ligne pour voir s'il y a concordance des patients. Si non, un message va s'afficher ainsi qu'un bouton permettant de simplement enregistrer le/s patient/s ajouté/s hors ligne de la même manière qu'il aurait ajouté s'il avait été directement en ligne;

 - Lorsque l'utilisateur est en ligne, lors de la connexion, j'imagine une synchronisation automatique des patients en ligne sur la BDD locale afin de toujours avoir accès aux patients.

La logique me paraît bonne, mais c'est une synchronisation qui sera assez complexe (et gourmande) à mettre en oeuvre. Il faudrait concevoir ta base de données en fonction de cela pour pouvoir rapidement identifier ce qui est à jour d'un côté et de l'autre. J'imagine une colonne dans chaque table de ta base te permettant d'identifier la date et l'heure de mise à jour et l'auteur de cette mise à jour ...

Mais cela pose de vrai question d'accès concurrentiel ... Imagine que l'utilisateur est connecté en local et qu'il modifie les données du client 1 sans être connecté à Internet. La base de données distante n'a pas connaissance de ces modifications ...

Ensuite il part de son bureau, ouvre l'appli mobile et consulte la fiche du client 1. Il voit les données sans les dernières mises à jour faites en local. Il décide de quand même modifier cette fiche et de l'enregistrer ... La base distante a donc des données différentes de la base locale, mais sans pour autant pouvoir déterminer laquelle des versions de la fiche client 1 est la bonne ... en fait aucune des deux ne l'est ...

Selon moi il faut trancher sur quelle est la base maître et bloquer les mises à jour de données sur l'esclave tant qu'une synchronisation n'est pas faite ... Il y a là des notions de verrou, de transactions, etc.

-
Edité par Benzouye 9 octobre 2018 à 9:40:54

Marshlle a écrit:

C'est vrai que n'ayant que parlé de "professionnel" et de "patient" j'ai laissé un doute planer autour du sujet, ici il s'agit de médecine non conventionnée et donc non reconnue réellement par l'état. Quant aux données, il est donc assez libre de les stocker où bon nous semble, bien qu'il faille garder en vue la confidentialité de chaque patient.

Attention, c'est ton interprétation ! La définition de la CNIL est beaucoup plus large https://www.cnil.fr/fr/quest-ce-ce-quune-donnee-de-sante 

les informations relatives à une personne physique collectées lors de son inscription en vue de bénéficier de services de soins de santé ou lors de la prestation de ces services

Le fait que ce soit une médecine alternative / non conventionnée n'entre pas en ligne de compte en ce qui concerne la nature des informations récoltées. 

Marshlle a écrit:

Pour ce qui est de la synchronisation de deux bases de données locales, j'imagine que s'il est possible de requêter depuis deux postes sur la BDD en même temps il doit être possible d'y créer plusieurs patients en même temps lors de la synchronisation.

Le problème situe si deux praticiens créent sur leur base de données locale le même patient ! Il vont avoir des ID d'identifiant différents, et lors de la synchronisation, la base de données centrale verra deux patient différents, alors qu'il s'agit du même.

La solution naïve est de comparer nom / prénom, etc... pour vérifier si des patients sont en double. Mais c'est un leurre, car on se heurte d'une part aux problème de saisi (si l'un des praticiens a fait une faute de frappes), ou aux homonymes.

En réalité, seule l'intervention humaine peut solutionner le problème : proposer les deux fiches patient et demander à un humain de créer deux fiches, ou d'en garder qu'une seule sur les deux, ou des les merger (ce qui peut arriver si l'un des praticiens n'a pas rempli tous les champs optionnels, et que l'autres fiches du même client si).

De manière générale, ce problème se posera sur tous les types d'informations : patients, examens, prescriptions, etc...

Oui, un triage des patients en fonction des dates de modification et vérification que les dernières date correspondent dans la BDD locale et principale devrait faire l'affaire, on verra ça au moment de gérer ce problème.

Benzouye a écrit:

Mais cela pose de vrai question d'accès concurrentiel ... Imagine que l'utilisateur est connecté en local et qu'il modifie les données du client 1 sans être connecté à Internet. La base de données distante n'a pas connaissance de ces modifications ...

Ensuite il part de son bureau, ouvre l'appli mobile et consulte la fiche du client 1. Il voit les données sans les dernières mises à jour faites en local. Il décide de quand même modifier cette fiche et de l'enregistrer ... La base distante a donc des données différentes de la base locale, mais sans pour autant pouvoir déterminer laquelle des versions de la fiche client 1 est la bonne ... en fait aucune des deux ne l'est ...

Selon moi il faut trancher sur quelle est la base maître et bloquer les mises à jour de données sur l'esclave tant qu'une synchronisation n'est pas faite ... Il y a là des notions de verrou, de transactions, etc.

-
Edité par Benzouye il y a environ 4 heures

Effectivement, c'est un problème sur lequelle je vais sérieusement me pencher. Ceci étant dit, je pense qu'aujourd'hui nous avons tous un smartphone, et l'utilisateur préferera peut être utiliser son téléphone comme modem plutôt que d'utiliser le logiciel hors ligne, on peut imaginer qu'il veut consulter d'autres choses que juste le logiciel, comme naviguer sur internet par exemple, et que donc il lui faudra forcément internet. Malgré tout il va falloir gérer ça :/.

Sebajuste a écrit:

Marshlle a écrit:

C'est vrai que n'ayant que parlé de "professionnel" et de "patient" j'ai laissé un doute planer autour du sujet, ici il s'agit de médecine non conventionnée et donc non reconnue réellement par l'état. Quant aux données, il est donc assez libre de les stocker où bon nous semble, bien qu'il faille garder en vue la confidentialité de chaque patient.

Attention, c'est ton interprétation ! La définition de la CNIL est beaucoup plus large https://www.cnil.fr/fr/quest-ce-ce-quune-donnee-de-sante 

les informations relatives à une personne physique collectées lors de son inscription en vue de bénéficier de services de soins de santé ou lors de la prestation de ces services

Le fait que ce soit une médecine alternative / non conventionnée n'entre pas en ligne de compte en ce qui concerne la nature des informations récoltées. 

C'est possible, après tout je n'ai pas vraiment vérifié ce que je disais, mais quoi qu'il en soit, que j'ai besoin de déclarer ma BDD quelque part ou que j'ai besoin d'un logiciel tiers pour pouvoir faire cela, je le ferai car mon projet comprend le stockage de données personnelles et que donc je ferai tout ce qu'il faut pour rester dans la légalité.

Sebajuste a écrit:

Marshlle a écrit:

Pour ce qui est de la synchronisation de deux bases de données locales, j'imagine que s'il est possible de requêter depuis deux postes sur la BDD en même temps il doit être possible d'y créer plusieurs patients en même temps lors de la synchronisation.

Le problème situe si deux praticiens créent sur leur base de données locale le même patient ! Il vont avoir des ID d'identifiant différents, et lors de la synchronisation, la base de données centrale verra deux patient différents, alors qu'il s'agit du même.

La solution naïve est de comparer nom / prénom, etc... pour vérifier si des patients sont en double. Mais c'est un leurre, car on se heurte d'une part aux problème de saisi (si l'un des praticiens a fait une faute de frappes), ou aux homonymes.

En réalité, seule l'intervention humaine peut solutionner le problème : proposer les deux fiches patient et demander à un humain de créer deux fiches, ou d'en garder qu'une seule sur les deux, ou des les merger (ce qui peut arriver si l'un des praticiens n'a pas rempli tous les champs optionnels, et que l'autres fiches du même client si).

De manière générale, ce problème se posera sur tous les types d'informations : patients, examens, prescriptions, etc...

C'est un problème qui se pose également en étant connecté sur la base de donnée principale, si un patient est créé, il sera impossible de savoir s'il a déjà était créé sauf en vérifiant toutes les informations de celui-ci, et si cela n'est pas trop lourd à vérifier, ce sera fait, sinon, plusieurs même patients seront créés. Là où cela ne me pose pas tant de problème c'est qu'un patient est lié à un professionnel, et que donc de toute manière il s'agit d'un nouveau patient pour ce professionnel. Si cela avait été un tout nouveau patient, il aurait également été créé dans la BDD, donc cela me semble être un problème à résoudre seulement lorsque mon logiciel sera bien avancé, au sein de MAJ par exemple, car comme tu le dis, cela se pose sur tous les types d'informations et qu'il y aurait trop de données à vérifier.

Marshlle a écrit:

Là où cela ne me pose pas tant de problème c'est qu'un patient est lié à un professionnel, et que donc de toute manière il s'agit d'un nouveau patient pour ce professionnel.

Ceci n'est pas vrai dans l'absolu. En cas de vacances, il est très courant dans un cabinet que l'autre patricien prenne les patients de son collègue. Ce qui imblique dans la base de données de pouvoir voir / interagir avec des clients qui ne nous sont pas liés directement.

Si tu veux vraiment avoir une base de données centralisées, j'espère que tu en as les moyens. As-tu bien lu les liens que je t'ai donnés ?

Le modèle de certification désormais proposé par la DSSIS (Délégation à la Stratégie des Systèmes d’Information de Santé) et l'ASIP Santé cherche à accroître la confiance envers les hébergeurs, en instaurant un audit sur site réalisé par un tiers indépendant. Et ceci aux frais de l'hébergeur.

Tu devra demander à une boite externe (le tiers indépendant) d'auditer ton code et ton architecture. As-tu déjà participé à projet devant être éditer ? Il s'agit avant tout de responsabilité. C'est l'entreprise tierce qui s'engage sur la fiabilité de l'architecture après avoir effectuer son audit. Ca veut dire qu'en cas de pépin, c'est elle qui devra payer, puisque toi tu pourra te protéger derrière l'argument "nous avions obtenus la certification que notre produit était correct".

Ainsi, le but d'une société qui réalise de tels audit est:

- de ne prendre aucun risque. Ca chipote sur un rien

- de faire payer au maximum son client. Si un audit ne passe pas, il faut le refaire, et donc repayer.

-
Edité par Sebajuste 9 octobre 2018 à 14:48:48

Ce que tu dis est totalement vrai, et c'est une chose qui m'était sortie de l'esprit mais maitenant que tu m'en parles, il me semble en avoir parlé avec mes partenaires et il serait facile d'avoir dans le logiciel un onglet ou quoi que ce soit qui permette d'accéder aux patients d'un collègue dans le cas de vacances, congés, etc...

Merci de me l'avoir rappelé.

Et bien sûr dans ce cas là il ne s'agit pas de créer un nouveau patient mais uniquement de visualiser ceux du collègue.

Pour ce qui est de l'audit, je mets un bémol ce que j'ai dit plus haut. La nature des données est sensible certes, mais peut être que le respect de RGPD est suffisant, et qu'un audit n'est pas nécessaire. Je vais essayer de me renseigner.

Pour ce qui est des données partagé, à ce niveau il ne faut pas réfléchir en terme d'interface (onglet / fenêtres etc..) mais de normalisation de la base de données.

-
Edité par Sebajuste 9 octobre 2018 à 14:57:14

Oui c'est vrai mais j'imaginais en amont, de la part de l'utilisateur qui est en vacance ou quoi que ce soit, qu'il ai appuyé sur un bouton ou fait une action qui permet de savoir dans la base de donnée quel autre utilisateur serait "lié" à ses patients.