Bonjour,
Je souhaite mettre en place un logiciel de gestion de cabinet médical
(gestion de dossiers médicaux, facturation, rendez-vous, ...)
fonctionnant sous apache.
Quelqu'un a-t-il une idée?
Bonjour,
Je souhaite mettre en place un logiciel de gestion de cabinet médical
(gestion de dossiers médicaux, facturation, rendez-vous, ...)
fonctionnant sous apache.
Quelqu'un a-t-il une idée?
Bonjour,
Je souhaite mettre en place un logiciel de gestion de cabinet médical
(gestion de dossiers médicaux, facturation, rendez-vous, ...)
fonctionnant sous apache.
Quelqu'un a-t-il une idée?
Le Mon, Feb 05, 2007 at 11:51:35AM +0100, Patrice TOSSAVI a écrit :
> Bonjour,
>
> Je souhaite mettre en place un logiciel de gestion de cabinet médical
> (gestion de dossiers médicaux, facturation, rendez-vous, ...)
> fonctionnant sous apache.
>
> Quelqu'un a-t-il une idée?
Bonjour,
Il y a une liste de logiciels libres, empaquetés ou non, dans les pages
du projet Debian-Med.
http://www.debian.org/devel/debian-med/practice.fr.html
Bonne journée,
--
Charles Plessy
http://charles.plessy.org
Wako, Saitama, Japan
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Le Mon, Feb 05, 2007 at 11:51:35AM +0100, Patrice TOSSAVI a écrit :
> Bonjour,
>
> Je souhaite mettre en place un logiciel de gestion de cabinet médical
> (gestion de dossiers médicaux, facturation, rendez-vous, ...)
> fonctionnant sous apache.
>
> Quelqu'un a-t-il une idée?
Bonjour,
Il y a une liste de logiciels libres, empaquetés ou non, dans les pages
du projet Debian-Med.
http://www.debian.org/devel/debian-med/practice.fr.html
Bonne journée,
--
Charles Plessy
http://charles.plessy.org
Wako, Saitama, Japan
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org
Le Mon, Feb 05, 2007 at 11:51:35AM +0100, Patrice TOSSAVI a écrit :
> Bonjour,
>
> Je souhaite mettre en place un logiciel de gestion de cabinet médical
> (gestion de dossiers médicaux, facturation, rendez-vous, ...)
> fonctionnant sous apache.
>
> Quelqu'un a-t-il une idée?
Bonjour,
Il y a une liste de logiciels libres, empaquetés ou non, dans les pages
du projet Debian-Med.
http://www.debian.org/devel/debian-med/practice.fr.html
Bonne journée,
--
Charles Plessy
http://charles.plessy.org
Wako, Saitama, Japan
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Le 05/02/07, Charles Plessy
a écrit :
> Le Mon, Feb 05, 2007 at 11:51:35AM +0100, Patrice TOSSAVI a écrit :
> > Bonjour,
> >
> > Je souhaite mettre en place un logiciel de gestion de cabinet médic al
> > (gestion de dossiers médicaux, facturation, rendez-vous, ...)
> > fonctionnant sous apache.
> >
> > Quelqu'un a-t-il une idée?
>
> Bonjour,
>
> Il y a une liste de logiciels libres, empaquetés ou non, dans les pag es
> du projet Debian-Med.
>
> http://www.debian.org/devel/debian-med/practice.fr.html
>
> Bonne journée,
>
> --
> Charles Plessy
> http://charles.plessy.org
> Wako, Saitama, Japan
>
>
> --
> Lisez la FAQ de la liste avant de poser une question :
> http://wiki.debian.net/?DebianFrench
> Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
> "Reply-To:"
>
> To UNSUBSCRIBE, email to
> with a subject of "unsubscribe". Trouble? Contact
>
>
Attention pour le cote facturation, si c'est une aide a la facturation, p as
de problemes, mais si c'est une teletranssmision, il faut que le logiciel
soit agree par la secu. Dans ce cas, il faut se renseigner avant d'avoir des
problemes ;)
Bon courage
Le 05/02/07, Charles Plessy
<charles-debian-nospam@plessy.org> a écrit :
> Le Mon, Feb 05, 2007 at 11:51:35AM +0100, Patrice TOSSAVI a écrit :
> > Bonjour,
> >
> > Je souhaite mettre en place un logiciel de gestion de cabinet médic al
> > (gestion de dossiers médicaux, facturation, rendez-vous, ...)
> > fonctionnant sous apache.
> >
> > Quelqu'un a-t-il une idée?
>
> Bonjour,
>
> Il y a une liste de logiciels libres, empaquetés ou non, dans les pag es
> du projet Debian-Med.
>
> http://www.debian.org/devel/debian-med/practice.fr.html
>
> Bonne journée,
>
> --
> Charles Plessy
> http://charles.plessy.org
> Wako, Saitama, Japan
>
>
> --
> Lisez la FAQ de la liste avant de poser une question :
> http://wiki.debian.net/?DebianFrench
> Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
> "Reply-To:"
>
> To UNSUBSCRIBE, email to
debian-user-french-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org
>
>
Attention pour le cote facturation, si c'est une aide a la facturation, p as
de problemes, mais si c'est une teletranssmision, il faut que le logiciel
soit agree par la secu. Dans ce cas, il faut se renseigner avant d'avoir des
problemes ;)
Bon courage
Le 05/02/07, Charles Plessy
a écrit :
> Le Mon, Feb 05, 2007 at 11:51:35AM +0100, Patrice TOSSAVI a écrit :
> > Bonjour,
> >
> > Je souhaite mettre en place un logiciel de gestion de cabinet médic al
> > (gestion de dossiers médicaux, facturation, rendez-vous, ...)
> > fonctionnant sous apache.
> >
> > Quelqu'un a-t-il une idée?
>
> Bonjour,
>
> Il y a une liste de logiciels libres, empaquetés ou non, dans les pag es
> du projet Debian-Med.
>
> http://www.debian.org/devel/debian-med/practice.fr.html
>
> Bonne journée,
>
> --
> Charles Plessy
> http://charles.plessy.org
> Wako, Saitama, Japan
>
>
> --
> Lisez la FAQ de la liste avant de poser une question :
> http://wiki.debian.net/?DebianFrench
> Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
> "Reply-To:"
>
> To UNSUBSCRIBE, email to
> with a subject of "unsubscribe". Trouble? Contact
>
>
Attention pour le cote facturation, si c'est une aide a la facturation, p as
de problemes, mais si c'est une teletranssmision, il faut que le logiciel
soit agree par la secu. Dans ce cas, il faut se renseigner avant d'avoir des
problemes ;)
Bon courage
Bien sûr qu'il faut que ce soit agréé par la sécu, et là j'ai un
doute. Les logiciels dont il est question ne sont déjà pas traduits en
français. Ceci a le dont d'exaspérer les 50 médecins avec lesquels je
travaillent, même si la langue de Shakespeare fait partie de leur
quotidien. Par contre, ces logiciels ont le mérite d'exister et il
faudrait un groupe de travail pour les prendre en main, les faire
évoluer, et les passer à la certification de la sécu, voire du GIP
CPS.
Bien sûr qu'il faut que ce soit agréé par la sécu, et là j'ai un
doute. Les logiciels dont il est question ne sont déjà pas traduits en
français. Ceci a le dont d'exaspérer les 50 médecins avec lesquels je
travaillent, même si la langue de Shakespeare fait partie de leur
quotidien. Par contre, ces logiciels ont le mérite d'exister et il
faudrait un groupe de travail pour les prendre en main, les faire
évoluer, et les passer à la certification de la sécu, voire du GIP
CPS.
Bien sûr qu'il faut que ce soit agréé par la sécu, et là j'ai un
doute. Les logiciels dont il est question ne sont déjà pas traduits en
français. Ceci a le dont d'exaspérer les 50 médecins avec lesquels je
travaillent, même si la langue de Shakespeare fait partie de leur
quotidien. Par contre, ces logiciels ont le mérite d'exister et il
faudrait un groupe de travail pour les prendre en main, les faire
évoluer, et les passer à la certification de la sécu, voire du GIP
CPS.
Le Mon, Feb 05, 2007 at 06:01:47PM +0100, Patrice OLIVER a écrit :
> Bien sûr qu'il faut que ce soit agréé par la sécu, et là j'ai un
> doute. Les logiciels dont il est question ne sont déjà pas traduits en
> français. Ceci a le dont d'exaspérer les 50 médecins avec lesquel s je
> travaillent, même si la langue de Shakespeare fait partie de leur
> quotidien. Par contre, ces logiciels ont le mérite d'exister et il
> faudrait un groupe de travail pour les prendre en main, les faire
> évoluer, et les passer à la certification de la sécu, voire du GI P
> CPS.
Bonjour à tous,
apparemment, des anglophones sont en train de monter un projet européen .
Un filon à creuser ?
http://lists.debian.org/debian-med/2007/01/msg00033.html
Autre filon à creuser, la communauté Ubuntu, peut-être plus orient ée
«coup de main» que «développement». Peut-être s'y trouve-t-il des
traducteurs en herbe ?
http://linuxforclinics.org/
Enfin, s'il y a du nouveau, n'hésitez pas à tenir debian-med au
courant:
http://lists.debian.org/debian-med/
Bonne journée,
--
Charles Plessy
http://charles.plessy.org
Wako, Saitama, Japan
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact .org
Le Mon, Feb 05, 2007 at 06:01:47PM +0100, Patrice OLIVER a écrit :
> Bien sûr qu'il faut que ce soit agréé par la sécu, et là j'ai un
> doute. Les logiciels dont il est question ne sont déjà pas traduits en
> français. Ceci a le dont d'exaspérer les 50 médecins avec lesquel s je
> travaillent, même si la langue de Shakespeare fait partie de leur
> quotidien. Par contre, ces logiciels ont le mérite d'exister et il
> faudrait un groupe de travail pour les prendre en main, les faire
> évoluer, et les passer à la certification de la sécu, voire du GI P
> CPS.
Bonjour à tous,
apparemment, des anglophones sont en train de monter un projet européen .
Un filon à creuser ?
http://lists.debian.org/debian-med/2007/01/msg00033.html
Autre filon à creuser, la communauté Ubuntu, peut-être plus orient ée
«coup de main» que «développement». Peut-être s'y trouve-t-il des
traducteurs en herbe ?
http://linuxforclinics.org/
Enfin, s'il y a du nouveau, n'hésitez pas à tenir debian-med au
courant:
http://lists.debian.org/debian-med/
Bonne journée,
--
Charles Plessy
http://charles.plessy.org
Wako, Saitama, Japan
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian .org
Le Mon, Feb 05, 2007 at 06:01:47PM +0100, Patrice OLIVER a écrit :
> Bien sûr qu'il faut que ce soit agréé par la sécu, et là j'ai un
> doute. Les logiciels dont il est question ne sont déjà pas traduits en
> français. Ceci a le dont d'exaspérer les 50 médecins avec lesquel s je
> travaillent, même si la langue de Shakespeare fait partie de leur
> quotidien. Par contre, ces logiciels ont le mérite d'exister et il
> faudrait un groupe de travail pour les prendre en main, les faire
> évoluer, et les passer à la certification de la sécu, voire du GI P
> CPS.
Bonjour à tous,
apparemment, des anglophones sont en train de monter un projet européen .
Un filon à creuser ?
http://lists.debian.org/debian-med/2007/01/msg00033.html
Autre filon à creuser, la communauté Ubuntu, peut-être plus orient ée
«coup de main» que «développement». Peut-être s'y trouve-t-il des
traducteurs en herbe ?
http://linuxforclinics.org/
Enfin, s'il y a du nouveau, n'hésitez pas à tenir debian-med au
courant:
http://lists.debian.org/debian-med/
Bonne journée,
--
Charles Plessy
http://charles.plessy.org
Wako, Saitama, Japan
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact .org
Le Mon, Feb 05, 2007 at 11:51:35AM +0100, Patrice TOSSAVI a écrit :Bonjour,
Je souhaite mettre en place un logiciel de gestion de cabinet médical
(gestion de dossiers médicaux, facturation, rendez-vous, ...)
fonctionnant sous apache.
Quelqu'un a-t-il une idée?
Bonjour,
Il y a une liste de logiciels libres, empaquetés ou non, dans les pag es
du projet Debian-Med.
http://www.debian.org/devel/debian-med/practice.fr.html
Bonne journée,
Le Mon, Feb 05, 2007 at 11:51:35AM +0100, Patrice TOSSAVI a écrit :
Bonjour,
Je souhaite mettre en place un logiciel de gestion de cabinet médical
(gestion de dossiers médicaux, facturation, rendez-vous, ...)
fonctionnant sous apache.
Quelqu'un a-t-il une idée?
Bonjour,
Il y a une liste de logiciels libres, empaquetés ou non, dans les pag es
du projet Debian-Med.
http://www.debian.org/devel/debian-med/practice.fr.html
Bonne journée,
Le Mon, Feb 05, 2007 at 11:51:35AM +0100, Patrice TOSSAVI a écrit :Bonjour,
Je souhaite mettre en place un logiciel de gestion de cabinet médical
(gestion de dossiers médicaux, facturation, rendez-vous, ...)
fonctionnant sous apache.
Quelqu'un a-t-il une idée?
Bonjour,
Il y a une liste de logiciels libres, empaquetés ou non, dans les pag es
du projet Debian-Med.
http://www.debian.org/devel/debian-med/practice.fr.html
Bonne journée,
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.
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.
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 ...).
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.
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 ...
Bonne journée,
Patrice.
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.
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.
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 ...).
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.
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 ...
Bonne journée,
Patrice.
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.
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.
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 ...).
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.
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 ...
Bonne journée,
Patrice.
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 notati ons
d'actes sont, à ma connaissance, TRES différentes d'un pays à l'au tre
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 dan s
> 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 Personne l),
> 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 tr avail
> national pour élaborer un cahier des charges décrivant les
> fonctionnalités des logiciels de cabinets médicaux, éventuellemen t
> décliné selon les spécialité. On y aurait inclus / imposé des normes
> concernant les échanges de façon à viser l'interopérabilité d es
> produits. Ces normes auraient ensuite été imposées aux éditeurs . Je
> conviens que ce travail a déjà été en partie réalisé. On au rait 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 d es
> 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 l e
> 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 organn e
> de collecte / référencement des informations à partager. On aurai t
> 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 ? :)
> 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 doi t
> commencer à prendre en compte la problématique 'par le bas', c'est à
> dire sur la base de cet existant ...
C'est un peu antinomique !
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 notati ons
d'actes sont, à ma connaissance, TRES différentes d'un pays à l'au tre
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 dan s
> 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 Personne l),
> 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 tr avail
> national pour élaborer un cahier des charges décrivant les
> fonctionnalités des logiciels de cabinets médicaux, éventuellemen t
> décliné selon les spécialité. On y aurait inclus / imposé des normes
> concernant les échanges de façon à viser l'interopérabilité d es
> produits. Ces normes auraient ensuite été imposées aux éditeurs . Je
> conviens que ce travail a déjà été en partie réalisé. On au rait 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 d es
> 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 l e
> 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 organn e
> de collecte / référencement des informations à partager. On aurai t
> 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 ? :)
> 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 doi t
> commencer à prendre en compte la problématique 'par le bas', c'est à
> dire sur la base de cet existant ...
C'est un peu antinomique !
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 notati ons
d'actes sont, à ma connaissance, TRES différentes d'un pays à l'au tre
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 dan s
> 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 Personne l),
> 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 tr avail
> national pour élaborer un cahier des charges décrivant les
> fonctionnalités des logiciels de cabinets médicaux, éventuellemen t
> décliné selon les spécialité. On y aurait inclus / imposé des normes
> concernant les échanges de façon à viser l'interopérabilité d es
> produits. Ces normes auraient ensuite été imposées aux éditeurs . Je
> conviens que ce travail a déjà été en partie réalisé. On au rait 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 d es
> 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 l e
> 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 organn e
> de collecte / référencement des informations à partager. On aurai t
> 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 ? :)
> 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 doi t
> commencer à prendre en compte la problématique 'par le bas', c'est à
> dire sur la base de cet existant ...
C'est un peu antinomique !
Patrice OLIVER a écrit :
> 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 étan t
> 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.
une solution issue du logiciel libre :-) c'est de monter ce groupe de
travail et de faire développer ce logiciel libre à plusieurs. En gros
regrouper de nombreux médecin près à payer quelques centaines d'eur o
chacun pour un logiciel qui leur conviendra vraiment.
--
Thomas Clavier http://www.tcweb.org
Lille Sans Fil http://www.lillesansfil.org
+33 (0)6 20 81 81 30 JabberID :
Patrice OLIVER a écrit :
> 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 étan t
> 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.
une solution issue du logiciel libre :-) c'est de monter ce groupe de
travail et de faire développer ce logiciel libre à plusieurs. En gros
regrouper de nombreux médecin près à payer quelques centaines d'eur o
chacun pour un logiciel qui leur conviendra vraiment.
--
Thomas Clavier http://www.tcweb.org
Lille Sans Fil http://www.lillesansfil.org
+33 (0)6 20 81 81 30 JabberID : tom@jabber.tcweb.org
Patrice OLIVER a écrit :
> 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 étan t
> 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.
une solution issue du logiciel libre :-) c'est de monter ce groupe de
travail et de faire développer ce logiciel libre à plusieurs. En gros
regrouper de nombreux médecin près à payer quelques centaines d'eur o
chacun pour un logiciel qui leur conviendra vraiment.
--
Thomas Clavier http://www.tcweb.org
Lille Sans Fil http://www.lillesansfil.org
+33 (0)6 20 81 81 30 JabberID :
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).
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).
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).