IRC logs of #tryton-fr for Sunday, 2012-04-22

chat.freenode.net #tryton-fr log beginning Sun Apr 22 00:00:02 CEST 2012
bechamel__efx__: salut15:11
__efx__salut15:11
bechamel__efx__: ce que j'essayais d'expliquer c'est que en passant par proteus.js, on attaque directement le serveur15:13
bechamelet si on veux donner acces au patient, il faut etre sur de bien configurer les droit d'acces des utilisateurs15:14
__efx__et l'acces de base est l'acces admin15:14
bechamell'acces db, a priori sera derrière un firewall15:14
bechamelet pour l'acces admin, en effet vu que le serveur sera accessible par tout le monde, il y a le risque d'attaques15:15
__efx__mais si le mdp admin est definis directement dans un fichier js c'est tres dangereu non ?15:16
cedk__efx__: en fait, c'est simple, on ne gere pas les access d'un employe, que l'access du user lambda15:16
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 :)15:17
cedk__efx__: quand tu a un compte gmail, tu n'a pas un compte sur le system de google15:17
__efx__:) donc le Proteus.connect peut etre appelé avec n'importe quel utilisateur present dans la base de donnees trytond15:18
bechamel__efx__: oui puisqu'il interagi directement avec le server15:18
__efx__et les droit seront octroyé par le serveur trytond15:18
__efx__donc a quel niveau est-ce que je dois definir des regles d'acces ?15:19
bechamel__efx__: dans un module tryton15:20
__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 ?15:21
bechamel__efx__: en quelque sorte oui15:24
-!- Telesight(~chatzilla@s537751a5.adsl.wanadoo.nl) has left #tryton-fr15:25
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é15:26
__efx__d'accord tres bien15: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 droits15:27
__efx__peut-etre devrais-je m'inspirer d'un module existant15:28
cedk__efx__: je vais le redire une dernier fois, mais pour moi aller dans cette direction est casse-gueule15:29
bechamel__efx__: effectivement il n'y a rien dans la doc sur les droit d'acces, mais se sont essentiellement de la configuration15:31
__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 ?15:32
cedk__efx__: sur une install minimal, il y a plus de 200 objects à configurer vs une simple page html15:33
cedk__efx__: niveau sécurité, y a pas photo15:33
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'operationel15:35
bechamel__efx__: et au final bloquer l'hopital15:36
__efx__quel horreur15:36
__efx__bon donc avoir des pages statiques serait donc la meilleurs solutions15:36
bechamel__efx__: autre question à se poser: comment vont etre validé les modif des patient: avec page statique plus mail c'est trivial15:36
__efx__se serait donc des assistantes qui se chargerait de gérer les mails et de faire les modif15:37
cedk__efx__: par static on entend générée du coté serveur avec un outil comme django15:37
bechamelvia 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 valider15:37
cedkbechamel: ça peut être un peu plus sofistiquer avec just une queue de changement et il suffit de valider15: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 sur15:38
__efx__et ensuite je pourrais aussi faire des petits scripts qui se chargerait de valider les infos et les ajouter sur le serveur15:39
bechamel__efx__: le premier avantage c'est de pouvoir mettre en place un serveur qui ne fera que ça15:39
bechamelet de facilement l'isoler du reste de l'infrastructure15:39
__efx__oui cela me parait etre un avantage indeniable15:40
bechamelcomme ç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)15:40
cedkbechamel: et même plusieurs serveur pour être webscale :-)15:40
bechamels/pirater/piraté/15:40
__efx__je pense qu avec ca je vais reussir a convaincre mon employeur ^^15:40
cedkbechamel: pour ce protéger niveau DB, il faudrait travailler avec une duplication mais ça devient compliqué15:42
__efx__donc le serveur web ne ferait qu une seule connection au serveur tryton pour generer les pages des patients15: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 support15:43
bechamel__efx__: genre des appel à l'aide "j'ai fais une modif mais je voulais pas vraiment la faire"15:43
bechamel__efx__: "ça marcha pas dans IE6" etc15:43
__efx__oui j'imagine, on part d'une idee de limiter le travail de support et finalement on a l'effet inverse15:44
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 idiotes15:45
__efx__he bein j'ose pas imaginer avec des "patients" lambda15:45
__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 ??15:46
bechamel__efx__: a priori non, il faut mettre en place une gestion des acces15:47
__efx__d'accord donc reellement séparé de tryton.. c'est mieu comme ca !15:47
cedk__efx__: ça depend ce que tu entends pas "géré"15:47
bechamel__efx__: est-ce qu'il y a dejà eu une réflexion sur ce point ?15:47
bechamel__efx__: est-ce que chaque patient aurra un login/password ? ou alors un espece de token unique ?15:48
bechamel__efx__: carte à puce ? :)15:48
__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 profile15:49
cedk__efx__: pourquoi pas OpenID ou OAuth15:50
bechamelcedk: et une intégratin facebook tant qu'on y est ! :)15:50
__efx__^^15:50
__efx__dans le meilleur des mondes15:51
__efx__mais est-ce que les patients auront le courage de se creer une OpenID ?15:51
__efx__peut on le faire a leur place ?15:51
cedkbechamel: pq pas, Facebook c'est OpenID je pense15: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)15:51
bechamelet ensuite en extra une zone de texte libre pour signaler d'autres modif15:52
cedk__efx__: justement l'interet d'OpenID est de ne pas le faire à la place de l'utilisateur15:52
bechamelmais c'est clair que dans ce cas l'hopital dois connaitre le num de tel du patient pour pouvoir poser des questions complémentaires15:53
cedkbechamel: de plus une intergration facebook permetrait surement d'avoir plus d'info sur le patient: date de naissance, addresse, activité etc.15:53
__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, ...)15:54
cedkbechamel: je pense qu'il y avait un projet un peu comme ça de Google15:54
bechamelcedk: tu rigole ? un hopital qui fait ça, il a une plainte sur le dos directement15:54
cedkbechamel: je rigole pas et je ne comprend pas pq une plainte15: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 perso15:55
__efx__je me demandes comment mettre ca en place avec tryton15:56
cedkbechamel: je dis pas que l'hopital doit pusher des données sur facebook mais l'inverse reprendre les donnée accessible publiquement15:56
cedk__efx__: "mélanger" qu'est-ce que ça veut dire?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 :)15:56
bechamelcedk: qu'est-ce qui se passe si facebook me permet de m'authentifier en tant qu'un autre user ?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 medicale15:57
bechamelcedk: qu'est qui empecherait Mark Z. de se faire passer pour Bill G. ?15:58
cedkbechamel: ben ça c'est le problème de l'utilisateur s'il délègue son authentification à facebook15:58
bechamelcedk: c'est le principe d'openid15:58
cedkbechamel: ben oui chaqu'un est responsable de sa sécurité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émentation15:59
cedk__efx__: comprend pas: entre ah tient une personne et ses donnees medicale16:00
bechamelcedk: 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é)16:00
cedkbechamel: et quoi donner un mot de passe, c'est pas la même chose !16:00
__efx__pardon le "ah tient" n'avait rien a faire la16:00
bechamelcedk: ben sur facebook  il y a deja un mdp16:01
cedk__efx__: alors ce que tu demande me parait completement illusoir16:01
cedk__efx__: si pas impossible16:01
bechamelcedk: de toute façon comment s'assurer qu'une personne est bien celle qu'elle prétend être en faisant de l'openid ?16:02
__efx__c'est pas moi qui demande :/ c'est ces docteurs :'( ils se rendent pas compte16:02
cedk__efx__: il faut bien à un moment qu'on ait le lien16:02
__efx__oui mais ce lien devrait simplement etre crypté16:02
__efx__avec le password du patient16:02
__efx__par exemple16:02
__efx__ou son token16:02
cedk__efx__: ben c'est des experts qui doivent faire les specifications pas des ignorants16:03
cedk__efx__: mais c'est encore plus stupide16:03
__efx__cedk: pourquoi ?16:03
bechamelcedk: __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)16:03
cedk__efx__: il faut alors demander le mot de passe du patient pour pouvoir faire ça facture? ou bien consulter son dossier16:03
__efx__non on fait la meme chose pour tout ceux qui doivent pouvoir faire le lien16:04
bechamelmais alors le login ça doit etre un chiffre ou une suite de lettre sans lien avec le nom16:04
cedk__efx__: donc pour chaque patients il faut crypter le lien pour 200 médecins16:05
cedk__efx__: je parle pas des performance de se genre d'usine à gaz16:05
__efx__non en general chaque client n'est le patient que de au plus 3-5 medecins16:05
__efx__le generaliste et les specialistes si présent16:06
cedk__efx__: ha oui et comment on fait quand un nouveau medecin arrive pour un patient ?16:06
__efx__bein soit le patient peut decider de lui donner l'acces si c'est un changement de medecin principal16:07
bechamelcedk: pq faire un lien pour chaque médecin ? ils doivent tous avoir acces aux patients16:08
cedk__efx__: ha oui donc, le medecin doit demander au patient d'encoder son mot de passe dans le system !?!?!16:08
__efx__cedk: effectivement ca ne fait absolument pas sens16:09
cedket puis le patient oublie son mot de passe etc.16:09
cedkon marche sur la tête16:09
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 passe16:10
bechamel__efx__: par contre il faut un systeme de controle à posteriori16:11
__efx__en fait nous sommes au niveau d'un cabinet medicale16:11
bechamelpar 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 justifier16:11
bechamel__efx__: c'est p-e plus simple alors16:13
bechamel__efx__: comment fonctionnent-ils actuellement ? comment les info sont partagées (ou pas)16:14
bechamel?16:14
__efx__c'est l'horreur, tout est un peu partout, papier / emails / EMR (plutot pour les factures)16:15
__efx__le dossier medical du patient n'est pas informatisé16:16
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)?16:18
__efx__oui absolument16:19
bechamel__efx__: donc a priori les données peuvent donc etre partagées, ça va pas mal simplifier la situation16:20
__efx__donc vous pensez que l'idee de separer les donnees personnelles du patients de ces donnees medicales est quelque chose d'inimplementable ?16:23
__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é)16:24
bechamel__efx__: ça ne me semble pas impossible, mais c'est difficile à dire sans connaitre tt les détails16:25
__efx__quels sont a ton avis les détails principaux qu'ils manquent ici ?16:28
__efx__et sinon avez-vous deja tester l'interface client de tryton sur un tablette ? est-ce que cela fonctionne ?16:30
bechamel__efx__: la premiere question que me viens à l'esprit c'est la modelisation de la db16:30
bechamel__efx__: si je devais la faire naivement, les données perso et médicale ne serait pas forcément bien séparée16:31
cedkbechamel: sur GNUHealth c'est dans des tables différentes: Party et Patient16:31
cedkje pense que c'est bien et suffisant16:32
bechamel__efx__: hors si on veux un synchro avec les autres cabinet, il faut pouvoir stocker des données "incomplètes"16:32
bechamelcedk: ok16:32
__efx__cedk: merci pour l'info, les donnees sont deja dans des tables séparé16:32
cedkje pense qu'il existe un format standard d'échange de donnée médical de patient16: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 ?16:33
__efx__oui le format HL7 peut le faire16:33
bechamelquid d'un patient qui change de cabinet16:33
cedkbechamel: il prend son fichier sur cle USB ;-)16:34
cedkje pense pas qu'il faut faire une synchro mais plus un export/import avec gestion de conflit16:34
bechamelcedk: clé USB: pq pas en fait16:36
bechamelafk16:39
cedk__efx__: je pense qu'il faut avoir une idée plus précise des functionnalité attendue16:44
cedk__efx__: et tu devrais aussi demander sur GNUHealth si des personnes ont déjà eu le même genre de cas16:45
cedk__efx__: au fait, c'est toi qui a envoyé un email sur sales at b2ck.com ?16:45
__efx__oui oui ^^16:45
__efx__je vais aller faire un tour sur GNUHealth pour voir ce qu'ils en pensent16:46
cedk__efx__: donc pas besoin de te répondre par email :-)16:47
__efx__non vous avais ete plus que clair ici, d'ailleurs je vous en remercie !16:47
__efx__en fait les fonctionnalités sont assez precise :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 consultation16:48
__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 analyses16:49
__efx__jusque la avec ce que nous ov16:49
__efx__jusque la avec ce que nous avons discuté tout me parait tres clair sur l'implementation16:50
__efx__il y a juste cette question de securite des donnees patients qui me bloque16:50
bechamel__efx__: pour le support tablette, c'est la que proteus.js devient intéressant :)16:52
cedkbechamel: oui kivy :-)16:53
cedks/oui/ou/16:53
__efx__est-ce que kivy tourne sur iOS ?16:56
__efx__javascript vs python16:57
__efx__?16:58
__efx__Avez-vous deja eu une experience de developpement d'interface pour tryton utilisant une bibliotheque UI js ou Pyjama ou kivy ?17:00
bechamel__efx__: en js, j'utilise jquery-ui17:02
cedk__efx__: j'ai commencé à un peu jouer avec kivy17:05
cedk__efx__: pour moi, pyjamas ne va pas dans une bonne direction17:06
__efx__cedk: a quels niveaux ?17:06
cedk__efx__: compilation python vers js17:07
__efx__cedk: donc GWT a les memes defaut ?17:11
cedk__efx__: GWT, il y a tout Google derrier17:13
cedk__efx__: mais actuellement, je pense pas que ce soit encore pertinent17:13
__efx__bechamel: merci pour toutes ses infos18:51

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!