Tonio M. a écritBonjour,
Je viens de télécharger MedinTux afin de tester la version php de ce logiciel. Je me permets de vous faire un retour d'un novice quant à l'installation du logiciel afin d'offrir aux développeurs un nouveau point de vue. J'ai souhaité installer ce logiciel dans l'optique d'une prise de rendez-vous d'un centre hospitalier fictif ... Formateur, mon objectif est de proposer à des stagiaires de travailler sur ce logiciel.
Pourquoi pas...
Tonio M. a écritJ'ai été assez surpris de la non installation des bases de données dans la version php. Je n'ai pas très bien compris la nécessité d'installer une version client lourd du logiciel sur une machine qui fait office de serveur web et de fait ne dispose pas d'interface graphique ! J'ai donc installé les bases en ligne de commande à partir des dump sql disponibles dans le répertoire set_bases. Pour ma part, je trouverai beaucoup plus intuitif un et seul fichier sql qui contiendrait l'ensemble des commandes dont les
CREATE DATABASE et les GRANT ALL.
Oui, mais la séparation des bases permet d'installer ou réinstaller tout ou partie au choix.
Tonio M. a écritAu bout de 2 heures, c'est le premier retour que je me permets de vous indiquer. La lecture de la documentation m'a ensuite permis de comprendre quelque peu l'historique du projet et l'objectif du module php qui, si j'ai bien compris, n'a pas vocation à être le module principal mais uniquement un moyen d'accès pour le nomadisme des médecins libéraux.
Entre autres.
C'est aussi un moyen simple d'ajouter un tas de fonctions utiles à MedinTux sans mettre le bazar dans le code (pour moi, le C++, c'est un peu du chinois).
Tonio M. a écritEnfin, est-ce que mon idée de projet serait réalisable avec Med'In Tux ? Avez-vous des utilisateurs du logiciel qui sont des CHU et qui prennent les rendez-vous de leur patient avec ce logiciel ou est-il inapproprié pour ces grandes structures et est-il plus adapté à des cabinets médicaux d'une dizaine de médecins ?
Le problème des CHU est double.
D'abord un problème de mentalités.
Je suis atterré de voir des médecins perdre du temps à dicter des compte-rendus qui seront saisis on ne sait quand (des délais de 6 mois existent !), alors qu'il iraient au moins aussi vite avec une saisie assistée par ordinateur pour saisir eux-mêmes leurs conte-rendus.
Il y a énormément de prés carrés dans ce genre de structure.
Ensuite, le problème de l'administration.
Du fait que l'argent ne sort pas de la poche des décideurs, rien n'est jamais assez cher.
Et un logiciel libre, qui plus est gratuit, ça ne fait pas classe.
Certes, MedinTux/PHP peut gérer des carnets de rendez-vous pour un hôpital entier, mais personne n'est prêt à fonctionner comme ça (personnellement, je pense que n'importe qui dans un hôpital devrait pouvoir prendre des rendez-vous pour n'importe qui à tout moment, charge aux médecins de laisser des instructions claires - je trouve invraisemblable devant la quantité de personnel d'attendre la fin de la pause de midi pour pouvoir prendre un rdv avec un médecin donné).
Pour le moment, MedinPHP a fait la preuve de son efficacité pour une gestion des plannings par secrétariat en simultanéité avec le médecin, mais pas sur une grande échelle.
Tonio M. a écritEn espérant avoir été constructif dans mes remarques,
Bien cordialement,
--
Tonio
Il existe des logiciels de planning beaucoup plus complets, avec affichage graphique, affichage simultané de plusieurs plannings, circulation par calendrier, que sais-je encore.
Il y a encore tant de fonctions qui mériteraient d'être développées dans MedinPHP, comme :
-création de documents et de prescriptions
-gestion des interactions médicamenteuses du Vidal
-création de terrains
-création des utilisateurs, des mots de passe, des types de rendez-vous
-lecture et intégration des images
-accès distant par un couple patient-médecin correspondant
Comme vous l'avez compris dans la doc, la finalité de MedinPHP a été initialement, d'accéder aux données depuis la rue, le domicile du patient, le domicile du médecin ou sa maison de campagne, etc.
Dans ces conditions, n'ont été implémentées que des fonctions qu'on ne pouvait pas effectuer avant la tournée à l'extérieur.
Le logiciel est déjà beaucoup plus développé que ce n'était projeté au début.
J'essaye aussi de le garder simple, afin de minimiser le temps d'apprentissage, et d'assurer un fonctionnement sur des plates-formes aussi variées que possible (par exemple, le javascript est toujours facultatif).
Espérant avoir répondu à certaines de vos questions, je vous remercie de votre intérêt
Gérard
