Le forum qui avait disparu depuis longtemps est enfin de retour. Pour y accéder, il suffit de cliquer sur le menu “Forum”. Et comme une nouveauté est toujours mieux quand elle est accompagnée d’une autre, j’ai aussi modifier le thème du site. N’hésitez pas à poster vos questions et vos remarque sur le forum.

L’analyse de la prochaine version de Phoenix est terminée! Il y a deux petites surprises par rapport au planning initial: le gestionnaire d’indices BMI sera de la partie avec le gestionnaire de liens familiaux. Mais faisons sans plus attendre une liste des nouvelles fonctionalités:

• Ajout d’un patient.
• Ajout rapide d’un patient. En d’autres termes, il suffit d’ajouter le nom, le prénom, la date de naissance et la date d’inscription du patient pour l’ajouter. En interne, cette fiche sera notée comme incomplète et l’utilisateur pourra la mettre à jour quand il aura plus de temps.
• Modification des données d’un patient.
• Gestion des données BMI (Body/Mass index) d’un patient avec affichage graphique des données et possibilité de les ajouter/modifier/supprimer.
• Gestion des liens familiaux d’un patient. Il y a moyen d’enregistrer le fait que le patient A est le frère du patient B qui est le père du patient C. Comme pour la gestion BMI on peut ajouter/supprimer/modifier des données.

Voici quelques liens pour avoir quelques informations supplémentaire:

• Le document d’analyse est téléchargeable ICI (Document en anglais).
• Vous pouvez laisser un commentaire pour formuler une requête ou poser une question.

Je viens de terminer l’analyse des fonctionnalités qui seront implémentées dans le prochain sprint.

Commençons par énoncer le but de cette version: créer un point d’entrée pour Phoenix Suite. Ce point d’entrée peut être subdivisé en trois parties: le “Phoenix’s Nest”, le module de recherche et la “session”.

Passons donc en revue ces concepts:

• Phoenix’s Nest: Ce concept, qui se traduit par “nid du phoenix“, est la partie de l’interface graphique qui supportera tout, ce sont les fondations de l’application. Il est responsable  de mettre à disposition de l’utilisateur toutes les fonctionnalités et d’afficher toutes les informations importantes .  Ci-dessous, un croquis de ce à quoi il ressemblera:

• Module de recherche: Est un module qui permet de chercher un patient sur différents critères. La sélection d’un patient permettra de charger une session. Voici un croquis de ce que devrait donner le module de recherche:

• Session: Une session est constituée d’un patient et propose l’accès à tous les services de gestion d’un patient. Par exemple, gestion des rendez-vous, des prescriptions etc.

Voici quelques liens pour avoir quelques informations supplémentaire:

• Le document d’analyse est téléchargeable ICI (Document en anglais).
• La liste des tests de validations se trouve ICI (Document en anglais).
• Vous pouvez laisser un commentaire pour formuler une requête ou poser une question.

Il m’arrive, en temps qu’informaticien, d’utiliser des mots totalement incompréhensibles qui pourrait me faire paraître pour un extra-terrestre. Pour que vous continuiez à me comprendre, j’ai commencé à lister tous ces mots barbare dans un glossaire que je mettrai à jour régulièrement. Pour l’heure, c’est ICI que ça se passe…

Étant donné que je suis en plein dans la phase d’analyse de la couche métier, il est normal que cela change. Voici donc les modifications apportées ces derniers jours…

Deux petites choses:

• Les pathologies sont maintenant classifiées par type.
• Les factures ont temporairement disparues.

Après discussion avec un ostéopathe, nous somme arrivé à la conclusion qu’il est inutile de relier une facture à un rendez-vous. De plus, Phoenix se concentre d’abord sur la gestion des patients.

Veuillez noter que, de part la phase d’analyse du module métier, je reste ouvert à toute proposition relative à la gestion des patients.  Puisque je suis en train de travailler dans ce module, tout demande à ce sujet sera implémentée quasi en temps réel 😉 Pour ce faire, il suffit de laisser un commentaire sur ce billet.

Ci dessous, le schéma modifié:

(Cliquez sur l’image pour la voir en grand)

Hier soir, j’étais au téléphone avec ma belle et tendre fiancée quand elle me dit que cela faisait un long moment que je n’écrivais plus rien au sujet de Phoenix Suite.  J’écris donc ce billet pour corriger cette erreur!

Cette fois-ci, je ne pourrais pas montrer de jolis  screenshots de l’interface graphique puisque le code que j’ai écris fait partie de la partie dite de “sous le capot“. J’ai fais quelques ajouts dans la logique métier, j’ai implémenté deux nouveaux modules et  j’ai reciblé les différentes technologies utilisées afin de rendre Phoenix le plus stable et adaptable possible.

Voici un résumer des derniers changements:

• Module de Log:
  J’ai rafraîchi toute la partie liée au logging afin de pouvoir cibler le plus facilement possible toutes les erreur et les bugs.  Une fois en production, c’est le dernier lien que j’aurais avec Phoenix pour chasser les bugs… C’est donc un module très sensible et qui doit être bien écrit!
• Module de Traduction:
  Initialement Phoenix est écrit en anglais mais il contient déjà un module de traduction qui comprendra au moins trois langues (peut-être quatre) dès sa sortie: Anglais, Français, Espagnole et peut-être Néerlandais. Ce module est finalisé et est prêt à subir la batterie de test avant d’être apte à la mise en production.
• Phoenix Core:
  C’est le cœur de Phoenix, c’est lui qui contient toute la logique métier. Après une discussion avec un ostéopathe,  j’ai ajouté un lien familial entre les patients. En d’autres termes, il sera possible de refaire un arbre généalogique de vos patients.  Ce module est toujours en travaux et peut donc subir quelques changements, mais ils resteront subtiles. Vous pourrez voir ci-dessous la schéma du module:

(Cliquez sur l’image pour la voir en grand)

Pour conclure  je vais rappeler les différents but que Phoenix 2 cible

• Versatilité du point de vue de son interface graphique, il sera donc très facile de créer de nouvelles interface graphique voire même laisser la possibilité à l’utilisateur de choisir laquelle il désire.
• Indépendance par rapport à la base de données. Une fois mature, Phoenix suivra la mode des systèmes distribués: une base de données centrale et des clients qui accède cette base de données. Bref une optique ou l’ostéopathe ne sera plus seul mais accompagné d’une secrétaire ou de collègues. La base de données de ce nouveau système ne sera plus SQLite mais probablement MySQL (ou n’importe quelle base de données qui gère les connexion multiples).

Je viens de terminer le code du moteur de recherche de Phoenix 2. Je vais en profiter pour donner quelques mots d’explication sur celui-ci.

Comme vous pouvez le voir sur l’image ci-dessous, l’interface graphique est sobre et complète.  La fenêtre se divise en deux parties. La moitié supérieure comprend les critères de recherche, il suffit de cocher les critères désirés et ensuite cliquer sur le bouton “rechercher“. Le moitié inférieure contient les résultats de la recherche et pour sélectionner un élément du résultat, il suffit de le double-cliquer ou de le sélectionner à la souris et de confirmer par le bouton “sélectionner“. L’utilisateur peut également changer à tout moment la taille des deux parties de la fenêtre.

J’ai programmé ce module pour le rendre adaptable facilement à n’importe quelle partie de la base de données (même celle qui n’existe pas encore!). Je pourrais très facilement donner la main à l’utilisateur pour qu’il choisisse lui même, via une interface de configuration, les critères qu’il souhaite utiliser pour ses recherche. Donc si je rencontre une demande dans cette voie, j’implémenterai cette fonctionnalité!

(Cliquez sur l’image pour la voir en grand)

Cela fait quelques temps que je ne donne plus de nouvelles, j’en suis navré mais le boulot était plus que prenant ces derniers temps: je passe littéralement mes weekends au boulot!

Ceci dit, ça c’est quelque peu calmé ce weekend et j’ai le temps d’écrire ce billet pour résumer l’état d’avancement de Phoenix 2.

Phoenix est subdivisé en trois modules:

1. Session:
   Ce module contient toutes les informations sur un patient et les outils pour interagir avec celui-ci.
   Voici la liste des sous modules:
   • Le module patient proprement dit.
   • Les fiches médicales.
   • Les photos relatives au patient.
   • Les prescriptions.
   • Les factures.
   • Les rendez-vous du patient.
2. Rendez-Vous:
   Ce module contient tous les outils pour gérer et afficher les rendez-vous.
3. Statistiques :
   Ce module contient tous les outils pour afficher les statistiques sur les différents domaines de Phoenix.
4. Administration:
   Ce module permet de gérer les options ou les informations satellites de Phoenix.

Pour l’instant je travaille sur la Session et plus particulièrement sur le module du patient. J’ai terminé l’interface graphique et les fonctionnalités pour la gestion  des réputations, des types de médecins et des mutuelles.  La gestion des médecins et des patient est quasiment terminée: il ne reste plus qu’à finaliser le système de recherche multi-critère. Le moteur de recherche générique est en cours d’écriture. Dès que celui-ci est terminé, il sera très facile de le spécialiser pour les différents module de Phoenix.

Comme promis, je vais m’attarder un peu sur les fonctionnalités et de la base de données de Phoenix Suite 2.

Tout d’abord, j’aimerai attirer l’attention sur le fait que je n’utilise plus Microsoft Acess mais une solution libre: SQLite (1).  D’une part la création de la base de données me coute beaucoup moins cher: je n’ai plus besoin d’une licence Microsoft Access ! D’autre part, SQLite se montre beaucoup plus rapide à l’utilisation que Access. Notez toutefois que l’utilisateur ne verra pas de différence si ce n’est une exécution plus rapide!

Si nous nous penchons sur le design proprement dit de la base de données, nous observerons quelques changements:

1. Le patient n’est plus limité à deux médecins. Il peut maintenant en avoir autant qu’il le désire.
2. Les médecins sont classés par spécialité (que l’utilisateur crée).
3. Les rendez-vous peuvent être de différents type (que l’utilisateur crée). Cela permet de faire des recherches par type de rendez-vous.
4. Le patient peut avoir autant de fiches médicales que nécessaire et plus une seule.
5. Une fiche médicale peut avoir un type (que l’utilisateur crée) ce qui permet de faire des recherches par type de fiche médicale.
6. Une facture peut être crée sur base d’un rendez-vous ou sur base d’un acte médical:
   1. Lors de la création d’une facture l’utilisateur pourra créer celle-ci sur base des rendez-vous auxquels le patient s’est présenté.
   2. L’utilisateur peut également créer des factures sur base d’un acte médical posé (sans tenir compte des rendez-vous)
   3. Notez que “Acte médical” n’est qu’un terme générique. Ceci pourrait représenter n’importe quel concept que l’on peut facturer à un patient. D’ailleurs l’interface graphique tiendra compte de ce point en laissant l’utilisateur choisir le terme à afficher.
7. Un système d’historique de pathologies notera toutes les pathologies dont le patient à souffert.
8. Pour le reste, les fonctionnalités restent les même que pour Phoenix Suite 1:
   1. Des photos peuvent être liées au patient.
   2. Le patient garde un historique de ses prescriptions.
   3. Le concept de “réputation” existe afin que l’utilisateur note comment le patient à entendu parlé du médecin.
   4. Un système de macro existe afin d’insérer du texte préformaté dans une fiche médicale.
   5. Un système de mise en évidence de texte existe afin de mettre en couleur certains types de mots dans le texte d’une fiche médicale.

Voilà le résumé des fonctionnalités qu’offrira Phoenix Suite 2… En espérant que cela plaira à la majorité 😉

(1) Site officiel de SQLite en anglais, l’article Wikipedia en français sur SQLite