Discussion :

[figarojuju]

Bonjour,
je suis kiné et je m'amuse à réaliser un petit logiciel de gestion de cabinet de kiné.
Je pense que l'étape de réflexion préliminaire pour le choix et l'implémentation de la bdd est important et comme j'ai tout mon temps...je me permets de le prendre pour vous demander conseil !!

J'ai réaliser un site roadbook pour mettre ce que j'ai commencé à faire :
http://sites.google.com/site/kinesitheratpie/

Pour l'instant, j'aurais aimé avoir vos réflexions sur la partie MCD et la partie MLD :
http://sites.google.com/site/kinesitheratpie/merise/mcd
http://sites.google.com/site/kinesitheratpie/merise/mld

Je vous joints le schéma de principe :

Bonne journée et @ bientôt

PS : je sais qu'il n'y a pas de t avant le p de kinésithérapie...

[JPhi33]

Bonjour,

Voici quelques remarques après une lecture sommaire.

1) Les types liste devraient être "externalisés" des entités dans lesquelles ils se trouvent, c'est-à-dire qu'ils devraient faire l'objet d'une entité à part entière. Les changements sont beaucoup plus simples à gérer : apparition d'une nouvelle instance, modification d'un terme (changer ALD en XYZ, par exemple), fusion de deux instances de la liste, etc.

J'en ai relevé 2 (entité Ordonnance) :
- Rôle du médecin
- Statut

Ces nouvelles entités contiendraient 2 propriétés :
id_xxx (clé)
libelle_xxx


2) Il serait préférable que certaines propriétés deviennent des listes (donc fassent l'objet de nouvelles entités comme ci-dessus) :
- mutuelle
- spécialité médicale


3) la propriété Type de séance semble contenir plusieurs informations de différentes natures : exercices, bilans. Il faut attribuer 1 propriété à chaque type d'information.


4) Un règlement est relatif à un patient et à une ordonnance. Cette règle n'est pas (est mal) modélisée.


C'est tout pour un premier constat.

Malgré ces remarques, je dois souligner que, pour un non professionnel de l'informatique, c'est un très bon travail.

[figarojuju]

Merci pour cette réponse qui est déjà bien exhaustive !!

j'ai profité que ma femme fait la sieste pour modifier mon MCD et revoir ma formulation des besoins.

Il me reste comme tu me l'as dit à réfléchir mieux comment représenter la facturation...

J'ai joint mon nouveau mcd et j'ai établi les modifications sur mon roadbook.
http://sites.google.com/site/kinesitheratpie/merise/mcd

Merci encore pour les remarques/conseils/suggestions/etc

Je m'y remets demain...

Bonne journée et @bientôt

[figarojuju]

Bonsoir,
j'ai revu un peu ma manière de facturer.
En fait, je facture à mes patients un nombre de séances. Donc, j'ai "attaché" à l'entité seance l'autre entité facturation.

Je pense que ce reglement va être une vraie pierre d'achoppement. Dans mon système, il faut que je puisse facturer mes patients pour un nombre variable de séances (x), qu'à chaque fois que je clique sur facturer, l'ordi sache que le patient en a déjà réglé n-x...

Je pense que je dois laisser un peu décanter tout ça...

Bonne soirée

[JPhi33]

Bonjour,

Cette nouvelle version du MCD amène de nouvelles remarques :

1) Dans la version précédente, le rôle du médecin était une propriété de l'ordonnance. Il faut donc que l'entité Rôle soit rattachée à Ordonnance et non pas à Médecin.


2) Chaque patient peut avoir une ou zero mutuelle. Donc la cardinalité de Souscrire côté Patient doit être 0,1 et non pas 0,n.


3) Le nombre de séances a disparu de l'entité Ordonnance dans le schéma.


4) Les séances sont effectuées par le patient dans le cadre d'une ordonnance. Ne serait-il pas plus judicieux de rattacher les séances à l'ordonnance ?

Un exemple pour éclairer mon propos (nombre de séances réduit pour simplifier) :
- Le patient P1 a une ordonnance pour 3 séances dans le cadre de la pathologie M1 sur l'ordonnance O1.
- Puis il a 2 séances pour une pathologie M2, ordonnance O2.
- Enfin, il revient pour 2 séances avec une ordonnance O3 dans le cadre de la première pathologie M1.

Dans le MLD dérivé de ce MCD, on aura :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Table Ordonnance
idOrdonnance NbSeance ... NumSecu
------------ --------     -------
O1           3            P1
O2           2            P1
O3           2            P1

Table Seance
idSance ... NumSecu
-------     -------
1           P1
2           P1
3           P1
4           P1
5           P1
6           P1
7           P1

Il est impossible de savoir que :
- les séances 1, 2 et 3 sont sont effectuées dans le cadre de l'ordonnance O1
- les séances 4 et 5 pour O2
- les séances 6 et 7 pour O3
On peut en avoir une idée avec les dates des séances mais ce n'est qu'approximatif.

Par contre, en rattachant Séance à Ordonnance, cette information devient accessible. Le lien avec le patient n'est pas perdu puisqu'une ordonnance ne concerne qu'un seul patient. Le schéma est le suivant :

[ Séance ]--1,1----( est exécutée dans le cadre )----1,n--[ Ordonnance ]


5) Il y a une meilleure solution pour modéliser le règlement mais je laisse ceci de côté pour une prochaine fois.

[figarojuju]

Cool cool cool,
merci pour les remarques...je viens de terminé ma première salve de patients !!!
Je me prends mon sandwitch en planchant sur ces informations !!

@bientôt!

[figarojuju]

Re bonjour,
Ayant pris en compte ces sympatiques remarques
Voici mes réflexions :

1/ déjà, je trouve que mon schéma est éloquent sur la centralité des ordonnances dans mon métier. C'est finalement très cohérent avec notre organisation que les ordonnances des médecins soient aussi centrales (voir schéma en pièce jointe).

2/ pour le rôle des médecins, je m'étais posé la question suivante : j'ai 2 solutions, soit je lie le rôle du médecin à l'entité médecin, soit je la lie à l'ordonnance. A la réflexion, je pense qu'il est plus judicieux de la lier à l'ordonnance car les médecins peuvent changer de rôle...ça dépend des fois. Mais c'est toujours relatif à une prescription médicale, donc c'est plus proche de la réalité que de le joindre à une prescription.

3/ je me demandais quel avantage j'aurais finalement à attacher le nombre de séances à l'association qui lie la prescription à l'entité seance...d'un point de vue métier, cela me parait cohérent. On exécute 20 séances pour rééduquer une épaule...Mais je ne vois pas bien l'avantage ni la différence que cela fait de mettre l'attribut nombre de séances dans les deux entités prescrition/ seance ou dans l'assaciation qui les lie... (cette une sorte de question en fait ?)

4/je pense aussi qu'il est plus pertinent d'attacher les séances à l'ordonnance, d'un point de vue métier, c'est bien comme cela que ça se passe.

5/pour les règlements, je ne sais pas si je n'aurais pas intérêt à sortir la date pour en faire une entité propre... j'ai l'intuition que cela pourrait être plus simple par la suite mais je ne vois pas encore très clair la dessus.

Merci encore et très bonne journée

[figarojuju]

Bonjour,
j'ai apporté une petite modification concernant la gestion des dates. J'ai lu que lorsque l'on abordait le problème de la prise en compte du temps dans les MCD et que l'on voulait utiliser un historique, il fallait créer une entité date...

[JPhi33]

Bonsoir,

1/ je trouve que mon schéma est éloquent sur la centralité des ordonnances dans mon métier. C'est finalement très cohérent avec notre organisation que les ordonnances des médecins soient aussi centrales.

Voila qui est rassurant sur la validité du modèle.

3/ je me demandais quel avantage j'aurais finalement à attacher le nombre de séances à l'association qui lie la prescription à l'entité seance...d'un point de vue métier, cela me parait cohérent. On exécute 20 séances pour rééduquer une épaule...Mais je ne vois pas bien l'avantage ni la différence que cela fait de mettre l'attribut nombre de séances dans les deux entités prescrition/ seance ou dans l'assaciation qui les lie... (cette une sorte de question en fait ?)

Je réponds donc à la question. Non seulement, il n'y a aucun avantage à rattacher le nombre de séances à l'association attribuer mais, en outre, ce serait faux.

En effet, lors de la transformation du MCD en MLD, les propriétés faisant éventuellement partie d'une association de type 1,1--*,n (* = 0 ou 1) "migrent" dans la table issue de l'entité qui est côté 1,1. Un schéma est plus explicite :

[ ENTITE_A ]--1,1----( ASSO_X )----0,n--[ ENTITE_B ]

S'il existe une propriété P dans l'association Asso_X, celle-ci devra se trouver dans la table issue de ENTITE_A (appelons-la A) dans le MLD. Voici le MLD dérivé du MCD ci-dessus :

[ A ]-------->[ B ]

On voit que ASSO_X ne donne lieu à aucune table dans le MLD. C'est normal, le lien entre ces deux tables est assuré par une référence (clé étrangère) située dans la table A. Cette référence est la clé de la table B.

Puisqu'il n'y a pas de table issue de ASSO_X, la propriété P ne peut pas trouver sa place. Que doit-on en faire ? P se rapporte au lien entre A et B ; sa place est donc du côté où se situe la clé étrangère, c'est-à-dire dans A.

C'est pour cette raison qu'on considère que placer une propriété dans une association de type 1,1--*,n est une erreur de modélisation. (voir ce même sujet dans la FAQ Merise)

5/pour les règlements, je ne sais pas si je n'aurais pas intérêt à sortir la date pour en faire une entité propre... j'ai l'intuition que cela pourrait être plus simple par la suite mais je ne vois pas encore très clair la dessus.

A propos des réglements, la modélisation actuelle comporte un inconvénient majeur : elle contraint à rattacher un réglement à chaque séance. Non seulement c'est une gestion plutôt lourde mais, de plus, ce lien ne pourra être concrétisé que lorsque le patient aura payé.

Il faut bien comprendre que le MCD interdit de créer une séance sans réglement. C'est une règle sémantique forte.

La question à se poser est la suivante. Est-il absolument nécessaire de savoir que tel réglement a servi à payer telles séances ou bien est-il suffisant de savoir qu'un réglement sert à payer N séances d'une ordonnance ?

Prenons un exemple (volontairement réduit) : l'ordonnance O1 prescrit 10 séances. Le patient règle :
- à la 3e séance -- réglement R1
- puis à la 7e -- réglement R2
- et le solde à la 10e -- réglement R3

Au bout du compte, la table Séance contiendra :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
IdSeance IdReglement
-------- -----------
 1       R1
 2       R1
 3       R1
 4       R2
 5       R2
 6       R2
 7       R2
 8       R3
 9       R3
10       R3

Quant à la table Reglement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
IdReglement Montant
----------- -------
R1          30
R2          40
R3          30

Savoir que R1, R2 et R3 règlent O1 n'est-il pas suffisant ?

Outre l'inconvénient cité plus haut, supposons que je souhaite vérifier que le montant total de O1 a bien été réglé. Je vais devoir lister la totalité des réglements liés à O1 pour en faire la somme. Je dois évidemment trouver 100€. Si j'effectue cette opération directement, à l'aide de jointures classiques, je vais trouver 340€ ! En effet :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
IdOrdonnance IdSeance IdReglement Montant
------------ -------- ----------- -------
O1            1       R1          30
O1            2       R1          30
O1            3       R1          30
O1            4       R2          40
O1            5       R2          40
O1            6       R2          40
O1            7       R2          40
O1            8       R3          30
O1            9       R3          30
O1           10       R3          30

Il va donc y avoir de sérieuses précautions à prendre sur les manipulations de la base de données touchant à l'aspect monétaire.

Pour éviter ces gros inconvénients, il serait plus que judicieux de rattacher les réglements à l'ordonnance :

[ Reglement ]--1,1---( Payer )----0,n--[ Ordonnance ]


A méditer...