chat.freenode.net #tryton-fr log beginning Sun Apr 22 00:00:02 CEST 2012 | ||
2012-04-22 15:11 <bechamel> __efx__: salut | ||
2012-04-22 15:11 <__efx__> salut | ||
2012-04-22 15:13 <bechamel> __efx__: ce que j'essayais d'expliquer c'est que en passant par proteus.js, on attaque directement le serveur | ||
2012-04-22 15:14 <bechamel> et si on veux donner acces au patient, il faut etre sur de bien configurer les droit d'acces des utilisateurs | ||
2012-04-22 15:14 <__efx__> et l'acces de base est l'acces admin | ||
2012-04-22 15:14 <bechamel> l'acces db, a priori sera derrière un firewall | ||
2012-04-22 15:15 <bechamel> et pour l'acces admin, en effet vu que le serveur sera accessible par tout le monde, il y a le risque d'attaques | ||
2012-04-22 15:16 <__efx__> mais si le mdp admin est definis directement dans un fichier js c'est tres dangereu non ? | ||
2012-04-22 15:16 <cedk> __efx__: en fait, c'est simple, on ne gere pas les access d'un employe, que l'access du user lambda | ||
2012-04-22 15:17 <bechamel> __efx__: c'est juste le script de test qui contient le mdp, dans une vraie implémentation on demande à l'utilisateur de le taper :) | ||
2012-04-22 15:17 <cedk> __efx__: quand tu a un compte gmail, tu n'a pas un compte sur le system de google | ||
2012-04-22 15:18 <__efx__> :) donc le Proteus.connect peut etre appelé avec n'importe quel utilisateur present dans la base de donnees trytond | ||
2012-04-22 15:18 <bechamel> __efx__: oui puisqu'il interagi directement avec le server | ||
2012-04-22 15:18 <__efx__> et les droit seront octroyé par le serveur trytond | ||
2012-04-22 15:19 <__efx__> donc a quel niveau est-ce que je dois definir des regles d'acces ? | ||
2012-04-22 15:20 <bechamel> __efx__: dans un module tryton | ||
2012-04-22 15:21 <__efx__> Est-ce que sur tryton je peux dire: l'entrée XX du module A ne peut etre vu que par l'utilisateur X et l'entrée YY du module A que par l'utilisateur Y ? | ||
2012-04-22 15:24 <bechamel> __efx__: en quelque sorte oui | ||
2012-04-22 15:25 -!- Telesight(~chatzilla@s537751a5.adsl.wanadoo.nl) has left #tryton-fr | ||
2012-04-22 15:26 <bechamel> __efx__: typiquement il faut un modèle qui permet de lier un utilisateur à un patient et ensuite ajouter des règles qui exprime le fait qu'un utilisateur ne peux voir que les données du patient auquel il est lié | ||
2012-04-22 15:27 <__efx__> d'accord tres bien | ||
2012-04-22 15:27 <__efx__> j'ai deja survoler la doc pour le design de modules tryton mais je n'ai pas vu de tuto pour la gestion des droits | ||
2012-04-22 15:28 <__efx__> peut-etre devrais-je m'inspirer d'un module existant | ||
2012-04-22 15:29 <cedk> __efx__: je vais le redire une dernier fois, mais pour moi aller dans cette direction est casse-gueule | ||
2012-04-22 15:31 <bechamel> __efx__: effectivement il n'y a rien dans la doc sur les droit d'acces, mais se sont essentiellement de la configuration | ||
2012-04-22 15:32 <__efx__> cedk: a quelle niveau aurais-je des problemes si je suis cette piste.. Car si je comprends bien si les regles sont bien definies au niveau de tryton il n'y a pas vrmt de risque ? Je me trompes ? | ||
2012-04-22 15:33 <cedk> __efx__: sur une install minimal, il y a plus de 200 objects à configurer vs une simple page html | ||
2012-04-22 15:33 <cedk> __efx__: niveau sécurité, y a pas photo | ||
2012-04-22 15:35 <bechamel> __efx__: un autre risque c'est que le server sois saturé par les connections (légitime ou pas) venant du web et rendant le serveur très lent ou inaccessible pour l'operationel | ||
2012-04-22 15:36 <bechamel> __efx__: et au final bloquer l'hopital | ||
2012-04-22 15:36 <__efx__> quel horreur | ||
2012-04-22 15:36 <__efx__> bon donc avoir des pages statiques serait donc la meilleurs solutions | ||
2012-04-22 15:36 <bechamel> __efx__: autre question à se poser: comment vont etre validé les modif des patient: avec page statique plus mail c'est trivial | ||
2012-04-22 15:37 <__efx__> se serait donc des assistantes qui se chargerait de gérer les mails et de faire les modif | ||
2012-04-22 15:37 <cedk> __efx__: par static on entend générée du coté serveur avec un outil comme django | ||
2012-04-22 15:37 <bechamel> via une interface web il faudrait développer un module qui permet l'edition des données sans vraiment les changer, + une interface permettant au médecin de comprendre de manière claire ce que le patient à changé pour lui premetre de valider | ||
2012-04-22 15:38 <cedk> bechamel: ça peut être un peu plus sofistiquer avec just une queue de changement et il suffit de valider | ||
2012-04-22 15:38 <__efx__> d'accord je crois que je commence a comprendre les risques encourues et pk une page "statique" sur un serveur web et beaucoup plus sur | ||
2012-04-22 15:39 <__efx__> et ensuite je pourrais aussi faire des petits scripts qui se chargerait de valider les infos et les ajouter sur le serveur | ||
2012-04-22 15:39 <bechamel> __efx__: le premier avantage c'est de pouvoir mettre en place un serveur qui ne fera que ça | ||
2012-04-22 15:39 <bechamel> et de facilement l'isoler du reste de l'infrastructure | ||
2012-04-22 15:40 <__efx__> oui cela me parait etre un avantage indeniable | ||
2012-04-22 15:40 <bechamel> comme ça s'il est pirater, seul les info qui sont dessus sont perdue (ce qui est deja grave mais moins qu'une db copiée et effacée par exemple) | ||
2012-04-22 15:40 <cedk> bechamel: et même plusieurs serveur pour être webscale :-) | ||
2012-04-22 15:40 <bechamel> s/pirater/piraté/ | ||
2012-04-22 15:40 <__efx__> je pense qu avec ca je vais reussir a convaincre mon employeur ^^ | ||
2012-04-22 15:42 <cedk> bechamel: pour ce protéger niveau DB, il faudrait travailler avec une duplication mais ça devient compliqué | ||
2012-04-22 15:43 <__efx__> donc le serveur web ne ferait qu une seule connection au serveur tryton pour generer les pages des patients | ||
2012-04-22 15:43 <bechamel> __efx__: et d'expérience, laisser des gens externes accéder à une page web ou ils peuvent encoder des données ça fait exploser le travail de support | ||
2012-04-22 15:43 <bechamel> __efx__: genre des appel à l'aide "j'ai fais une modif mais je voulais pas vraiment la faire" | ||
2012-04-22 15:43 <bechamel> __efx__: "ça marcha pas dans IE6" etc | ||
2012-04-22 15:44 <__efx__> oui j'imagine, on part d'une idee de limiter le travail de support et finalement on a l'effet inverse | ||
2012-04-22 15:45 <bechamel> __efx__: j'ai fais un formulaire d'inscription en ligne pour des universitaire qui font des la programmation, donc normalement à l'aise avec l'IT, et bien je peu te dire que j'ai deja eu bcp de questions idiotes | ||
2012-04-22 15:45 <__efx__> he bein j'ose pas imaginer avec des "patients" lambda | ||
2012-04-22 15:46 <__efx__> si j'utilise cette strategie de pages statiques, l'acces au ressources (page perso du patient) sera tout de meme géré via tryton ?? | ||
2012-04-22 15:47 <bechamel> __efx__: a priori non, il faut mettre en place une gestion des acces | ||
2012-04-22 15:47 <__efx__> d'accord donc reellement séparé de tryton.. c'est mieu comme ca ! | ||
2012-04-22 15:47 <cedk> __efx__: ça depend ce que tu entends pas "géré" | ||
2012-04-22 15:47 <bechamel> __efx__: est-ce qu'il y a dejà eu une réflexion sur ce point ? | ||
2012-04-22 15:48 <bechamel> __efx__: est-ce que chaque patient aurra un login/password ? ou alors un espece de token unique ? | ||
2012-04-22 15:48 <bechamel> __efx__: carte à puce ? :) | ||
2012-04-22 15:49 <__efx__> En fait dans le cahier des charges, il aurait une espece de token unique (sur une carte) donnant acces aux informations medicales (en cas par exemples d'accidents) et un login/password lui permettant de demander des changements sur son profile | ||
2012-04-22 15:50 <cedk> __efx__: pourquoi pas OpenID ou OAuth | ||
2012-04-22 15:50 <bechamel> cedk: et une intégratin facebook tant qu'on y est ! :) | ||
2012-04-22 15:50 <__efx__> ^^ | ||
2012-04-22 15:51 <__efx__> dans le meilleur des mondes | ||
2012-04-22 15:51 <__efx__> mais est-ce que les patients auront le courage de se creer une OpenID ? | ||
2012-04-22 15:51 <__efx__> peut on le faire a leur place ? | ||
2012-04-22 15:51 <cedk> bechamel: pq pas, Facebook c'est OpenID je pense | ||
2012-04-22 15:51 <bechamel> __efx__: en fait s'il y a des cas d'utilisations clair et bien cadré, ça pourrait etre pas mal de laisser les utilisateur encoder des données dans l'interface web (j'imagine par exemple un changement d'adresse, ou de status social) | ||
2012-04-22 15:52 <bechamel> et ensuite en extra une zone de texte libre pour signaler d'autres modif | ||
2012-04-22 15:52 <cedk> __efx__: justement l'interet d'OpenID est de ne pas le faire à la place de l'utilisateur | ||
2012-04-22 15:53 <bechamel> mais c'est clair que dans ce cas l'hopital dois connaitre le num de tel du patient pour pouvoir poser des questions complémentaires | ||
2012-04-22 15:53 <cedk> bechamel: de plus une intergration facebook permetrait surement d'avoir plus d'info sur le patient: date de naissance, addresse, activité etc. | ||
2012-04-22 15:54 <__efx__> oui c'est vrai mais cela me rappel une des contraintes imposé : les medecins veulent une "separation" des donnees patients (nom, prenoms, statut social, ...) des donnes medicales (alcoolemie, allergies, ...) | ||
2012-04-22 15:54 <cedk> bechamel: je pense qu'il y avait un projet un peu comme ça de Google | ||
2012-04-22 15:54 <bechamel> cedk: tu rigole ? un hopital qui fait ça, il a une plainte sur le dos directement | ||
2012-04-22 15:55 <cedk> bechamel: je rigole pas et je ne comprend pas pq une plainte | ||
2012-04-22 15:55 <__efx__> les donnees ne doivent pas pouvoir etre utilisé contre le patient, c'est la principale regles donc il faut faire attention a ne pas mélanger les donnees sensibles (medicale) des donnees perso | ||
2012-04-22 15:56 <__efx__> je me demandes comment mettre ca en place avec tryton | ||
2012-04-22 15:56 <cedk> bechamel: je dis pas que l'hopital doit pusher des données sur facebook mais l'inverse reprendre les donnée accessible publiquement | ||
2012-04-22 15:56 <cedk> __efx__: "mélanger" qu'est-ce que ça veut dire? | ||
2012-04-22 15:56 <bechamel> __efx__: sinon, si tu veux vraiment jouer avec proteus.js; une solution serait de mettre en place un second server tryton ne contenant qu'un module de gestions des modifs, et permettraus aux utilisateur d'encoder leurs changement, et il faudrait ensuite un mecanisme qui appliquerait cas changement d'un serveur à l'autre :) | ||
2012-04-22 15:57 <bechamel> cedk: qu'est-ce qui se passe si facebook me permet de m'authentifier en tant qu'un autre user ? | ||
2012-04-22 15:57 <__efx__> c'est a dire que si par malheur qqn a acces a la base de donnees tryton il ne doit pas pouvoir faire de lien entre ah tient une personne et ses donnees medicale | ||
2012-04-22 15:58 <bechamel> cedk: qu'est qui empecherait Mark Z. de se faire passer pour Bill G. ? | ||
2012-04-22 15:58 <cedk> bechamel: ben ça c'est le problème de l'utilisateur s'il délègue son authentification à facebook | ||
2012-04-22 15:58 <bechamel> cedk: c'est le principe d'openid | ||
2012-04-22 15:59 <cedk> bechamel: ben oui chaqu'un est responsable de sa sécurité | ||
2012-04-22 15:59 <bechamel> __efx__: en fait il faut d'abord faire une liste des modification qu'un patient peu faire et sur base de celle-ci décider de l'implémentation | ||
2012-04-22 16:00 <cedk> __efx__: comprend pas: entre ah tient une personne et ses donnees medicale | ||
2012-04-22 16:00 <bechamel> cedk: on parle de données médicales, "ben oui chaqu'un est responsable de sa sécurité" ça marche pour les geeks (en bonne santé) | ||
2012-04-22 16:00 <cedk> bechamel: et quoi donner un mot de passe, c'est pas la même chose ! | ||
2012-04-22 16:00 <__efx__> pardon le "ah tient" n'avait rien a faire la | ||
2012-04-22 16:01 <bechamel> cedk: ben sur facebook il y a deja un mdp | ||
2012-04-22 16:01 <cedk> __efx__: alors ce que tu demande me parait completement illusoir | ||
2012-04-22 16:01 <cedk> __efx__: si pas impossible | ||
2012-04-22 16:02 <bechamel> cedk: de toute façon comment s'assurer qu'une personne est bien celle qu'elle prétend être en faisant de l'openid ? | ||
2012-04-22 16:02 <__efx__> c'est pas moi qui demande :/ c'est ces docteurs :'( ils se rendent pas compte | ||
2012-04-22 16:02 <cedk> __efx__: il faut bien à un moment qu'on ait le lien | ||
2012-04-22 16:02 <__efx__> oui mais ce lien devrait simplement etre crypté | ||
2012-04-22 16:02 <__efx__> avec le password du patient | ||
2012-04-22 16:02 <__efx__> par exemple | ||
2012-04-22 16:02 <__efx__> ou son token | ||
2012-04-22 16:03 <cedk> __efx__: ben c'est des experts qui doivent faire les specifications pas des ignorants | ||
2012-04-22 16:03 <cedk> __efx__: mais c'est encore plus stupide | ||
2012-04-22 16:03 <__efx__> cedk: pourquoi ? | ||
2012-04-22 16:03 <bechamel> cedk: __efx__ : on peu imaginer des page anonymes, cad un liste de données médicale mais sans le noms du patient (ni adresse ou numero de tel) | ||
2012-04-22 16:03 <cedk> __efx__: il faut alors demander le mot de passe du patient pour pouvoir faire ça facture? ou bien consulter son dossier | ||
2012-04-22 16:04 <__efx__> non on fait la meme chose pour tout ceux qui doivent pouvoir faire le lien | ||
2012-04-22 16:04 <bechamel> mais alors le login ça doit etre un chiffre ou une suite de lettre sans lien avec le nom | ||
2012-04-22 16:05 <cedk> __efx__: donc pour chaque patients il faut crypter le lien pour 200 médecins | ||
2012-04-22 16:05 <cedk> __efx__: je parle pas des performance de se genre d'usine à gaz | ||
2012-04-22 16:05 <__efx__> non en general chaque client n'est le patient que de au plus 3-5 medecins | ||
2012-04-22 16:06 <__efx__> le generaliste et les specialistes si présent | ||
2012-04-22 16:06 <cedk> __efx__: ha oui et comment on fait quand un nouveau medecin arrive pour un patient ? | ||
2012-04-22 16:07 <__efx__> bein soit le patient peut decider de lui donner l'acces si c'est un changement de medecin principal | ||
2012-04-22 16:08 <bechamel> cedk: pq faire un lien pour chaque médecin ? ils doivent tous avoir acces aux patients | ||
2012-04-22 16:08 <cedk> __efx__: ha oui donc, le medecin doit demander au patient d'encoder son mot de passe dans le system !?!?! | ||
2012-04-22 16:09 <__efx__> cedk: effectivement ca ne fait absolument pas sens | ||
2012-04-22 16:09 <cedk> et puis le patient oublie son mot de passe etc. | ||
2012-04-22 16:09 <cedk> on marche sur la tête | ||
2012-04-22 16:10 <bechamel> __efx__: si je me souvient bien, dans les hopitaux, le personnel médical à acces à tous les patients car en cas d'urgence on ne peut pas attendre de faire des modifs d'acces ou de mot de passe | ||
2012-04-22 16:11 <bechamel> __efx__: par contre il faut un systeme de controle à posteriori | ||
2012-04-22 16:11 <__efx__> en fait nous sommes au niveau d'un cabinet medicale | ||
2012-04-22 16:11 <bechamel> par ex, si un médecin consulte un ou plusieur fois la fiche d'un patient dont il n'a pas la charge, il devra se justifier | ||
2012-04-22 16:13 <bechamel> __efx__: c'est p-e plus simple alors | ||
2012-04-22 16:14 <bechamel> __efx__: comment fonctionnent-ils actuellement ? comment les info sont partagées (ou pas) | ||
2012-04-22 16:14 <bechamel> ? | ||
2012-04-22 16:15 <__efx__> c'est l'horreur, tout est un peu partout, papier / emails / EMR (plutot pour les factures) | ||
2012-04-22 16:16 <__efx__> le dossier medical du patient n'est pas informatisé | ||
2012-04-22 16:18 <bechamel> __efx__: je me présente au cabinet et mon medecin habituel est absent, est-ce que le médecin qui me reçoit a accès à mon dossier (papier)? | ||
2012-04-22 16:19 <__efx__> oui absolument | ||
2012-04-22 16:20 <bechamel> __efx__: donc a priori les données peuvent donc etre partagées, ça va pas mal simplifier la situation | ||
2012-04-22 16:23 <__efx__> donc vous pensez que l'idee de separer les donnees personnelles du patients de ces donnees medicales est quelque chose d'inimplementable ? | ||
2012-04-22 16:24 <__efx__> elle peuvent etre partagé mais dans une moindre mesures, c'est a dire qu'elle peuvent etre partagé au seins d'un cabinet mais pas entre les cabinets (sauf si autorisé) | ||
2012-04-22 16:25 <bechamel> __efx__: ça ne me semble pas impossible, mais c'est difficile à dire sans connaitre tt les détails | ||
2012-04-22 16:28 <__efx__> quels sont a ton avis les détails principaux qu'ils manquent ici ? | ||
2012-04-22 16:30 <__efx__> et sinon avez-vous deja tester l'interface client de tryton sur un tablette ? est-ce que cela fonctionne ? | ||
2012-04-22 16:30 <bechamel> __efx__: la premiere question que me viens à l'esprit c'est la modelisation de la db | ||
2012-04-22 16:31 <bechamel> __efx__: si je devais la faire naivement, les données perso et médicale ne serait pas forcément bien séparée | ||
2012-04-22 16:31 <cedk> bechamel: sur GNUHealth c'est dans des tables différentes: Party et Patient | ||
2012-04-22 16:32 <cedk> je pense que c'est bien et suffisant | ||
2012-04-22 16:32 <bechamel> __efx__: hors si on veux un synchro avec les autres cabinet, il faut pouvoir stocker des données "incomplètes" | ||
2012-04-22 16:32 <bechamel> cedk: ok | ||
2012-04-22 16:32 <__efx__> cedk: merci pour l'info, les donnees sont deja dans des tables séparé | ||
2012-04-22 16:33 <cedk> je pense qu'il existe un format standard d'échange de donnée médical de patient | ||
2012-04-22 16:33 <bechamel> __efx__: un autre point: les flux de données, est-ce qu'il faut des syncho pairs à pairs des données entre les cabinets ? | ||
2012-04-22 16:33 <__efx__> oui le format HL7 peut le faire | ||
2012-04-22 16:33 <bechamel> quid d'un patient qui change de cabinet | ||
2012-04-22 16:34 <cedk> bechamel: il prend son fichier sur cle USB ;-) | ||
2012-04-22 16:34 <cedk> je pense pas qu'il faut faire une synchro mais plus un export/import avec gestion de conflit | ||
2012-04-22 16:36 <bechamel> cedk: clé USB: pq pas en fait | ||
2012-04-22 16:39 <bechamel> afk | ||
2012-04-22 16:44 <cedk> __efx__: je pense qu'il faut avoir une idée plus précise des functionnalité attendue | ||
2012-04-22 16:45 <cedk> __efx__: et tu devrais aussi demander sur GNUHealth si des personnes ont déjà eu le même genre de cas | ||
2012-04-22 16:45 <cedk> __efx__: au fait, c'est toi qui a envoyé un email sur sales at b2ck.com ? | ||
2012-04-22 16:45 <__efx__> oui oui ^^ | ||
2012-04-22 16:46 <__efx__> je vais aller faire un tour sur GNUHealth pour voir ce qu'ils en pensent | ||
2012-04-22 16:47 <cedk> __efx__: donc pas besoin de te répondre par email :-) | ||
2012-04-22 16:47 <__efx__> non vous avais ete plus que clair ici, d'ailleurs je vous en remercie ! | ||
2012-04-22 16:48 <__efx__> en fait les fonctionnalités sont assez precise : | ||
2012-04-22 16:48 <__efx__> il y a un coté personnel medicale, la il faut qqch qui soit exactement comme le client tryton mais ils souhaiterais egalement une compatibilité tablettes pour faciliter l'entree des donnees patients lors de la consultation | ||
2012-04-22 16:49 <__efx__> et un coté patient qui permettent au patient de voire son dossier medical en ligne avec des fcts comme rappel de vaccins possiblite de voire le fichier pdf envoyé par les laboratoires si il y a eu des analyses | ||
2012-04-22 16:49 <__efx__> jusque la avec ce que nous ov | ||
2012-04-22 16:50 <__efx__> jusque la avec ce que nous avons discuté tout me parait tres clair sur l'implementation | ||
2012-04-22 16:50 <__efx__> il y a juste cette question de securite des donnees patients qui me bloque | ||
2012-04-22 16:52 <bechamel> __efx__: pour le support tablette, c'est la que proteus.js devient intéressant :) | ||
2012-04-22 16:53 <cedk> bechamel: oui kivy :-) | ||
2012-04-22 16:53 <cedk> s/oui/ou/ | ||
2012-04-22 16:56 <__efx__> est-ce que kivy tourne sur iOS ? | ||
2012-04-22 16:57 <__efx__> javascript vs python | ||
2012-04-22 16:58 <__efx__> ? | ||
2012-04-22 17:00 <__efx__> Avez-vous deja eu une experience de developpement d'interface pour tryton utilisant une bibliotheque UI js ou Pyjama ou kivy ? | ||
2012-04-22 17:02 <bechamel> __efx__: en js, j'utilise jquery-ui | ||
2012-04-22 17:05 <cedk> __efx__: j'ai commencé à un peu jouer avec kivy | ||
2012-04-22 17:06 <cedk> __efx__: pour moi, pyjamas ne va pas dans une bonne direction | ||
2012-04-22 17:06 <__efx__> cedk: a quels niveaux ? | ||
2012-04-22 17:07 <cedk> __efx__: compilation python vers js | ||
2012-04-22 17:11 <__efx__> cedk: donc GWT a les memes defaut ? | ||
2012-04-22 17:13 <cedk> __efx__: GWT, il y a tout Google derrier | ||
2012-04-22 17:13 <cedk> __efx__: mais actuellement, je pense pas que ce soit encore pertinent | ||
2012-04-22 18:51 <__efx__> bechamel: merci pour toutes ses infos |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!