Discussion :

[marot_r]

Attention : Le développement d'une application quelle que soit sa nature impose de connaître l'ensemble des règles.

C'est très vrai et comme on dit par chez nous "Le diable est dans les détails". Autrement dit, un problème qui peut paraître simple au début peut être un vrai enfer lorsqu'on se met à creuser pour le réaliser.

A+

[St Carats]

j'ai fini deja de batir les tables, relations et quelques formulaire ! j'ai pas encore conçu les etats et requètes...mais je sais pas comment "uploader" ce que jai fais ici !

[St Carats]

St Carats,

Donc résumons, un assuré bénéficie d'une assurance : tu dois donc stocké dans la table Visite concocté par René un champ Booléen (de type OUI/NON) précisant si la visite est soumis à assurance (ce n'est peut être pas une obligation) d'où la question suivante :

Un assuré peut-il être couvert par son assurance sur un motif de visite et une autre visite Non ? (Ta réponse impactera l'emplacement de ce champ Booleen à savoir dans visite ou table Patient).

En ce qui concerne le taux de prise en charge, dans la table <DetailVisite> nous aurons donc le prix de l'acte (éventuellement modifiable) ainsi que le taux de Prise en Charge. Deux nouvelles questions cependant :

1. Le taux est t-il identique pour chaque acte lors d'une visite ?
2. Y a t-il l'équivalent du qualificatif de dépense dans ton pays (c'est à dire acte supporté par la PEC ou non) ?

Le calcul s'effectuera donc en fonction du taux et du prix de l'acte à l'écran, sur un état ou sur une requête.

PS : PEC = Prise en Charge dans notre jargon




JimBoLion

Concrètement j'ai , c'est plutot dans ma table patient que j'ai ajouté le champs indiquant si "le patient " est soumis a un régime d'assurance . j'avais donc essayé de sélectionner le type booléen pour ce champs mais il s'avère que quand je saisie des enregistrement de patient ce champs prends sois le "0 " ou "1" au lieu de "OUI/NON " comme je laurai souhaiter . j'ai dc décider finalement de d'opter pour une liste de déroulante .

Reponse couverture assurance :

je sais pas vraiment ! Normalement si on as une assurance santé , on s'en sert partout ou besoin y est sauf si l'hopital en question ne reçois pas les assurance dune maison x donnée...
dc je dirai qu'un patient bien qu’étant assuré peut ne pas pouvoir utilisé son assurance dans des fois...
Pour ce qui nous intéresse nous ( cabinet médicale ) c'est : est ce que le patient pour cette visite dispose d'une assurance acceptable chez nous ?
si oui alors celui ci est assuré ...

Aussi je sais pas vraiment mais je suppose que le taux depends de la maison d'assurance dc celui ci peut différer.

[marot_r]

"0 " ou "1" au lieu de "OUI/NON " comme je laurai souhaiter

Le codage interne n'est pas important. Les champs booléens sont conçus pour stocker des valeurs vraie ou fausse.

Attention de ne pas confondre l'affichage de la donnée, de préférence gérer au niveau des formulaires, avec la valeur de la donnée dans la table.

Dans ta table tu peux très bien avoir -1 (vrai, oui) / 0 (faux, non) et dans ton formulaire afficher. "OUI" ou "NON".

Si tu "masques" la vraie valeur contenue dans la table, tu risques de ne pas savoir quoi mettre comme critère dans tes requêtes pour retrouver tes données.

A+

[St Carats]

Bonsoir ,
ok je vais donc passer a l'autre étape c'est a dire la création des requêtes et formulaires...

Pour résumer , la sorte de facture (resumant ) le passage du patient dans le cabinet est un état que j’édite et dans lequel je mentionne toute les activité lié au patients dans la clinique .mais j’évite d'y inscrire son numéro identifiant comme je l'avais souhaiter au départ...

c'est un peu ce que je comprends !

[jimbolion]

St_Carats, René bonjour

Réné :

C'est très vrai et comme on dit par chez nous "Le diable est dans les détails".

Belle expression que je serai ressortir à bon escient...

St Carats

ok je vais dc passer a l'autre etape c'est a dire la création des requêtes et formulaires...

Pas trop vite. Es tu certain de ton modèle ? Le travail est réfléchi mais je pense honnêtement qu'il subsiste quelques failles.

1. Je constate qu'il s'agit d'un cabinet médical dentiste : Ne faudrait t-il pas intercaler une table soins entre visites et détail de l'acte. Généralement pour une visite il y a plusieurs soins (à des dates différentes) avec une facture globale. Tout peut éventuellement se regrouper dans visite (mais il te faut datedebut et datefin) si tu préfères mais avec perte de l'historique.
Soins -> Visites -> Detail Visites.

2. Le type de relation entre Acte Médical et Détail Visite n'est pas indiqué.

3. La table Prix_Act_Medical sert à conserver les différents tarifs si des changements devaient avoir lieu (Cette table est-elle vraiment nécessaire ?). Que se passe t-il si tu intègres le prix de l'acte dans la table Acte_Medical ? Mais la réflexion est bonne.

3. Dans T_Visites le type de paiement doit se rattacher à une relation 1 à N. Il peut y avoir plusieurs moyens de paiement et tu peux ainsi gérer les versements successifs (acomptes versés).

4. Concernant l'assurance et le choix du booléen (suivre la réponse de René). L'interprétation d'un champ peut être reformaté à l'écran ou sur un état et te permet d'utiliser aussi les check box (dès fois plus parlant qu'une listBox). Concernant l'assurance je pense qu'il faut se rapprocher de ton ami afin de vérifier si l'ensemble des actes sont soumis à prise en charge (moi je pense que le taux doit être redescendu dans la table Detail_Acte afin de gérer l'exhaustivité des cas).
Concernant l'assurance : Un assuré peut-il bénéficier de plusieurs assurances qui viendrait en complément de l'assurance principale. Tu peux ainsi faire un cumul de taux.
Une assurance est t-elle valable pour certains soins et indépendamment d'un acte (exemple détartrage). On appelle cela soins de confort.

5. Et puis normalise le nom des champs et de tes tables (le nom d'une table T_nomTable au pluriel puisque il s'agit d'une collection). Pour le nom des champs index mettre Patient_ID et champ de données : Patient_nom...
Sans être hyper rigide cela te facilitera la vie lors de la constitution de tes requêtes. Tu verras que au cours de l'évolution de ton projet une bonne normalisation n'est que bénéfique. Pas d'accents, pas de N°, pas de parentheses, pas de guillements mais par contre l'underscore est le bienvenu.

Jeté pèle mêle quelques réflexions. Saches qu'un projet évolue toujours et que nombre de développements n'aboutissent jamais car l'application dans un domaine professionnel répond à des exigences et que les cas métiers doivent être gérés dans l'intégralité. Le fameux diable dans le détail.

JimBoLion

[St Carats]

1.
Je constate qu'il s'agit d'un cabinet médical dentiste : Ne faudrait
t-il pas intercaler une table soins entre visites et détail de l'acte.
Généralement pour une visite il y a plusieurs soins (à des dates
différentes) avec une facture globale. Tout peut éventuellement se
regrouper dans visite (mais il te faut datedebut et datefin) si tu
préfères mais avec perte de l'historique.
Soins -> Visites -> Detail Visites.

Ahh oui je commence a bien retrouver le diable dans les détails là !

En effet , il s'agit d'un cabinet dentaire et après interview je me suis
rendu compte qu'une visite peux générer plusieurs soins en différentes
dates et même qu'un soins complet peu se faire en plusieurs jours!
mais je crois au final c'est un montant unique quelques sois le nombre
de séance qu'a nécessité le soins ( le social ) ...

2. Le type de relation entre Acte Médical et Détail Visite n'est pas
indiqué.

c'est a dire? je pense plutot a integré "Act medical " dans la la table
vistes...

3. La table Prix_Act_Medical sert à conserver les différents
tarifs si des changements devaient avoir lieu (Cette table est-elle
vraiment nécessaire ?). Que se passe t-il si tu intègres le prix de
l'acte dans la table Acte_Medical ?

je suis d'avis avec vous , l’intégrer dans la table Acte_Medical serais
bien.mais aussi en l'ayant a part sa constituerais une base de donnée
pour ts les actes effectué dans le cabinet...

3. Dans T_Visites le type de paiement doit se rattacher à une
relation 1 à N. Il peut y avoir plusieurs moyens de paiement et tu peux
ainsi gérer les versements successifs (acomptes versés).

Oui mais comment definir ce type de relations ( 1 a N)??

4. Concernant l'assurance et le choix du booléen (suivre la
réponse de René). L'interprétation d'un champ peut être reformaté à
l'écran ou sur un état et te permet d'utiliser aussi les check box (dès
fois plus parlant qu'une listBox). Concernant l'assurance je pense qu'il
faut se rapprocher de ton ami afin de vérifier si l'ensemble des actes
sont soumis à prise en charge (moi je pense que le taux doit être
redescendu dans la table Detail_Acte afin de gérer l'exhaustivité des
cas).
Concernant l'assurance : Un assuré peut-il bénéficier de plusieurs
assurances qui viendrait en complément de l'assurance principale. Tu
peux ainsi faire un cumul de taux.
Une assurance est t-elle valable pour certains soins et indépendamment
d'un acte (exemple détartrage). On appelle cela soins de
confort.

Oui c'est ce que j'ai fais : descendre le taux dans la table detail_Acte
.
je pense que je vais encore interroger mon ami....

Maintenant disons que j'ai un patient qui est assuré et dont la maison
d'assurance couvre les frais clinique a 80% ..
le montant total de la visite alors serais calculé...je veux donc ecrire
une expression qui prends en compte ce calcul ( voir image )
mais ca fonctionnne pas quand je fais un enregistrement du coup jai pensé plutot ecrit un code mais la encore sa coince car je sais vraiment pas quoi ecrire ...

[jimbolion]

St Carats,

Ce n'est pas sur un événement qu'on insère un champ calculé sauf à le faire dans un code VBA ! Dans la partie SourceControle.

Regarde ce sujet

http://office.microsoft.com/fr-fr/ac...010108354.aspx

JimBoLion

[St Carats]

Bonsoir a tous ,

Desolé pour l'absence , difficulté lié aux périodes d'examens...

Mais Jm , comme sugéré jai intercalé la table soins et je vois bien son utilité.
jai aussi approché mon ami et le cabinet ne prends pas en compte les mutuelles donc tout les payement se font cash et ya même possibilité de payer par tranches ( séance ou soins )

[St Carats]

J'ai quand même decider de laisser le champs Assurance au cas ou!
mais avant je vous montre un etat des relation entre les table après quoi je pourrai créer les états.

Désormais , une intervention nécessitant plusieurs séance ou soins parfois , le Patient sera enregistré seulement dans le formulaire visite la premiere fois ou il entame la visite dans le cabinet.Toute seance qui vont suivre (dans le cadre de la meme visite) seront ajouté ou enregistré dans la table soins avec ajout de la date et du néméro de la visite qui corespond a ce patient...

[jimbolion]

St Carats?

Pour les paiement une table T_Reglements avec (Id_Visite,Mode_Reglement_Fk, Montant)

Table Mode_Reglement (Id_Mode_Reglement, Mode_Reglement_NomLong, Mode_Reglement_NomCourt)


Exemple : ID = 1 (Nom_Long ) Especes (Nom_Court) = ESP

Pour le reste çà me semble cohérent (rajouter un statut de visite : En cours - Teminé) avec une table ad hoc.

Un modèle évolue en fonction de ton développement

Mais avant les états faudrait peut-être commencer par les formulaires


Bon courage pour la suite

[St Carats]

Great ! Thanks Jim ...
RDV en fin de semaine avec le résultat escompté

[jimbolion]

St Carats,



JimBoLion

[St Carats]

Bonsoir a tous ,

Ayant usé de toute vos recommandations je pense être arrivé a quelques chose d'assez interressant ! Bon disons j'ai crée quelques requêtes et formulaires
et je crois avoir implémenté mon MCD et MCT a 90% . Mais je rencontre une difficulté quand a la création de la facture pour chaque Patient. C'est a dire que l'application doit pourvoir faire sortir une facture ( ou une fiche patient ) ! au départ je pensais le faire avec un etat mais il me semble que c 'est pas possible ...enfin je sais pas si c possible avec un formulaire de tel sorte que jai seulement une fiche édité pour chaque patient que j'aurai défini...

[St Carats]

Alors je dois donc aussi crer une table T_Facture???
si c'est le cas comment le fomulaire pourra edité les facture selon les patients? ( un patient par page ) enfin si voyez un peu de quoi je veux parler...

[jimbolion]

St Carats,


Eh oui la difficulté d'un modèle tient à prendre en compte l'ensemble des contraintes posées par une demande métier. Une facture doit être établie à l'issue de la prestation, mais le patient peut éventuellement demander un relevé des soins durant la période (nous n’appellerons donc pas cela facture) donc une table T_facture avec un Id, une date, un numéro et une clé étrangère Visite_FK (héritant de la table Visite). En l’occurrence la table Règlements héritera de la table Factures. N'oublie pas une table Paramètres permettant de renseigner toutes les mentions légales à faire apparaître sur la facture (coordonnées du cabinet, N° Siret ou équivalent dans ton pays...)


JimBoLion

[St Carats]

Salut Jim,

Je suis vraiment content de l’évolution actuelle de l'application , mon Professeur aussi en est satisfait il veux même l’intégrer sur son site ...Mais il y'a encore des failles surtout avec la facture ou la fiche patient !

J'avoue aussi ne pas comprendre votre idée...(confus) ! si vous pouviez me le détaillé un peu plus. dans mes relations j'ai pas lié la table visite et Facture , j'ai créer une table independante (t_facture) et chaque fois que je veux éditer une nouvelle facture je rempli le formulaire facture que j'imprime ensuite ....

vous avez parler de faire migrer une clé étrangère ( visite ) dans la table facture , cela me semble correcte... Et aussi la table règlement elle vas consister a quoi?

[St Carats]

Bonsoir a tous, jim et Réné,

Je vous viens tout d'abord vous remercier pour votre aide qui m'as été vraiment bénéfique ...J'ai bcp appris avec vous et c'est avec joie que je vous présente ce que j'ai pu realiser jusqu'a présent y compris la facture et meme le titre de cette discution a savoir : comment codifier de maniere automatique les clés d'un enregistrement ; j'ai finalement trouver une astuce en jouant sur la date . merci

[jimbolion]

St Carats,

Bravo pour le travail réalisé... mais peut être va t-il falloir que tu revois une partie du projet. Je t'ai prévenu, on commence par le modèle et ensuite les formulaires et les états.

Maintenant revenons en à notre facture. Ta facture est bien le résultat d'une visite. Puisque les soins sont renseignés au fur et à mesure, pourquoi faire re-saisir au dentiste tous les éléments des actes de soins (puisque en plus tu stockes le montant de chaque acte : inutile de faire une resaisie des infos). Donc ta table t_facture devrait se résumer à peu près à çà :

T_factures (Id_Facture, visite_FK (N° visite chez toi), date_edition, numero_facture, statut_facture.....) - La simple jonction entre factures visites et actes devient ainsi aisée et peut servir à établir également un relevé de soins (c'est juste l'en tête de l"état qui changera)

et associé à cette table factures une table t_reglements (comportant de 1 à n reglements)

t_reglement(id_reglement, reglement_mode_fk, montant) : reglement_mode_fk héritant d'une table t_modes_reglements (id_modeèreglement,mode_reglement_nomcourt,mode_rgelment_nom_long)

Dans le principe c'est comme cela qu'il faut agir

Les puristes (comme René) te diront qu'ils faudraient envisager d'associer plusieurs factures à n visites et on peut même imaginer que ce soient des factures n'appartenant pas aux mêmes patients) dans ce cas il suffit d'ajouter une table de jonction t_factures_visites (id_jonction, id_visite, id_facture). La facture ne se rattachant plus à la visite... mais dois tu gérer ce cas ?

JimBoLion

[St Carats]

ok je vais dc essayé d’implémenter ça comme ça voir ...