[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: logiciel de gestion de cabinet médical fonctionnant sous apache



Le 06/02/07, Jean-Yves F. Barbier<7ukwn@free.fr> a écrit :
Salut Patrice,

Tu as l'air déjà pas mal impliqué dans ce projet, alors voici
ce que j'ai tiré de mes expériences (la substantifique moëlle, quoi :).

Je ne prétends nullement tout connaitre ni d'ailleurs maitriser, mais
un certain nombre d'années d'informatique (programmation en assembleurs
8 bits, basic, C, script; mais aussi en utilisateur de softs, plus 5 ans
en tant que gérant d'un boite d'informatique) ainsi que l'actuelle
réalisation d'un (petit) ERP sous Postgresql + Gambas me laissent
espérer pouvoir apporter ma pierre à l'édifice:

Patrice OLIVER a écrit :
> Bonjour,
>
> En ce qui me concerne, je suis loin de trouver ce type de projet
> inintéressant. Cependant, pour que les logiciels soient utilisés en
> France, il faut qu'il soit effectivement agréé vitale 1.40, voire
> 1.41. Il faut aussi qu'il puisse utiliser la CPS, d'où le GIP-CPS.
> C'est un boulot important qu'il faut entreprendre de façon structurée,
> en tant que vrai projet. Les contraintes de notre pays ne sont pas
> celles de la Belgique, qui ne sont pas celles de l'Angleterre, etc.

C'est là qu'est, à mon avis, un des plus gros noeud du PB: les notations
d'actes sont, à ma connaissance, TRES différentes d'un pays  à l'autre
cf: les fameux "K" français. <=> 1 module / pays

> Il serait certainement plus intéressant pour les médecins de ville de
> disposer d'une offre de 2 ou 3 produits tout au plus, de façon à
> fédérer plus facilement l'utilisation de l'outil informatique dans
> leurs cabinets. La multitude des offres (j'ai recensé 17 produits dans
> mon secteur) ne fait que renforcer un mode de fonctionnement
> individuel, et rend difficiles les tentatives d'échanges. Ajouté à
> cela la problématique de connexion au DMP (Dossier Médical Personnel),
> et on s'aperçoit très vitre ne prenant du recul que c'est tout
> simplement un beau sac de noeuds.

Je dirais même plus: un seul produit (mais plusieurs modules)
Pour les raisons suivantes:

* Maintenance plus aisée,
* Besoins quantifiables et quasi-équivalents (sauf spécialistes),
* Impatience chronique de la profession,
* En cas de pépin, le praticien ne peut se permettre d'attendre
    longtemps une réponse,
* Compilation des retours des utilisateurs beaucoup plus facile
   s'ils sont en grand nombre.

> Une démarche intéressante aurait été de créer un groupe de travail
> national pour élaborer un cahier des charges décrivant les
> fonctionnalités des logiciels de cabinets médicaux, éventuellement
> décliné selon les spécialité. On y aurait inclus / imposé des normes
> concernant les échanges de façon à viser l'interopérabilité des
> produits. Ces normes auraient ensuite été imposées aux éditeurs. Je
> conviens que ce travail a déjà été en partie réalisé. On aurait aussi
> imposé des normes concernant l'organisation des informations dans les
> 'SGBD' desdits logiciels, ainsi que des méthodes pour les utiliser.
> Cela aurait évité à chacun de réinventer la roue et aurait déjà
> simplifié les échanges entre praticiens. Pour l'exemple, certains des
> médecins qui travaillent avec moi utilisent des systèmes avec des
> données structurées, et d'autres s'aperçoivent que les leurs ne le
> sont pas. Cela rend difficile l'exploitation des données
> (statsistiques, recherche ...).

c'est évident et très important

> Ensuite, on aurait fait le DMP et l'aurait présenté comme un organne
> de collecte / référencement des informations à partager. On aurait
> ainsi fait un système globalement cohérent dans lequel les normes
> auraient été intégrées de facto.

qu'est-ce qu'un DMP ? :)

Le Dossier Médical Personnel, projet lancé par Douste-Blazy sous le
nom de Dossier Médical Partagé.


> Pour ma part, j'ai le sentiment que l'on a commencé à travailler à
> l'envers en tentant de créer le noyau, et en attendant que les
> médecins se rallient aux normes. Mon avis est que lorsqu'il y a un
> existant, avec une volonté de centralisation de l'information, on doit
> commencer à prendre en compte la problématique 'par le bas', c'est à
> dire sur la base de cet existant ...

C'est un peu antinomique !

J'ai dû mal m'exprimer. Le propos est que maintenant les utilisateurs
(médecins) doivent pour majorité (dans ma région) changer leurs
logiciels ... Si les logiciels avaient été écrits, en terme
d'échanges, sur la base des travaux de l'IHE (www.ihe.net), il y
aurait moins de problèmes; Si les développeurs qui ont développé
certains de ces produits étaient de vrais développeurs, ont se
poserait moins de question sur la possibilité d'une reprise de données
(dans certains cas, impossible :( ).

Maintenant, dire que les produits vont "fusionner", où qu'il en
restera moins, c'est un point de vue que je ne partage pas. Par
exemple, la société CEGEDIM, éditeur le plus représenté dans ma
région, y a installé pas moins de 4 produits différents,
commercialisés par des entités différentes. Leur politique étant
d'éviter au maximum les CE, les entités sont petites (< 50 salariés),
et malheuresement autonomes ... Il faut des normes (comme dans le
milieu de la biologie) pour faire du travail utile.

Maintenant, quels que soient les outils de développement et les
languages utilisés, il faut que le produit soit utilisable tout
d'abord sur Windows (95 % des médecins de ma région), sur MacOsX (les
5 % restants), et Linux (pour anticiper éventuellement l'avenir).

Bonne soirée.
Patrice.



Reply to: