Cahier des charges pour le plugin prévention

• Gestion des données de prévention
  • pour un patient en particulier
  • pour une population
• Il comprendra
  • des actions de prévention,
  • des résultats , et
  • une notification de rappel (automatique et programmable).
• Nous définissons
  • éléments de prévention : un item particulier de la prévention. Par exemple: “automesures deux fois par an”.
  • moteurs de prévention : regroupent un ou plusieurs “éléments de prévention”. Par exemple: “Risque cardio-vasculaire”.
• Le module prévention sera intégré à l'interface de FreeMedForms par le biais d'une page et d'un sous-menu dans le menu plugins.

• Dans la prévention on peut citer :
  • les vaccinations (moteur de prévention),
  • les suivi des examens de dépistage (moteur de prévention)
    • coloscopie
    • mammographie
    • frottis cervicovaginal
    • prostate (psa, clinique, paraclinique)
    • examen de la peau
    • suivi du diabétique
      • fond d'oeil
      • microalbuminurie
      • pieds
      • coeur

• Description (utiliser la classe Utils::GenericDescription ?)
  • un identifiant unique
  • un nom (traduisible)
  • une catégorie (traduisible)
  • un élement de validité
  • un élément d'utilisation (l'utilisateur peut inhiber/activer un moteur entier s'il le désire)
  • des limitations (sexe, âge…)
  • des règles d'analyse (codée en javascript ou en C++)
  • des règles d'alerte et de notification (xml ou javascript)
  • des ressources textuelles ou image (à gérer en attendant le nouveau plugin document – ex lettre au patient…)
  • des éléments de présentation graphique spécifique

• Exemple:
  • Vaccination (moteur spécifique)
  • Suivi des examens de prévention
  • …
• Description (utiliser la classe Utils::GenericDescription ?)
  • un identifiant unique
  • un nom (traduisible)
  • une catégorie (traduisible)
  • un élement de validité
  • un élément d'utilisation (l'utilisateur peut inhiber/activer un moteur entier s'il le désire)
  • une liste d'éléments de prévention

• Un moteur de prévention prend en charge un ou plusieurs de prévention
• Par défaut nous l'appellerons PrenventionEngine (ou IPreventionEngine si cette devient virtuelle pure)
• Elle donnera un accès:
  • aux éléments d'identification des items de prévention

• Utiliser des tables relationnelles
• Une table pour
  • la description générale (pour éléments et moteurs)
  • les contenus spécifques (scripts, fichiers) (faire très général pour pouvoir mettre toutes les ressources associées aux éléments et aux moteurs – un blob par exemple)
  • les résultats (car un éléments de prévention peut avoir plusieurs résultats == historique && statistiques)
  • une trace des analyses/modifications réalisées par les utilisateurs

• création d'un plugin test inclus dans une application test (répertoire /trunk/test/prevention )
• création de la base de données

- je travaille déjà avec un module de prévention et timer très utile

- Inscription dans base de donnée.

- Combo d'items avec rajout possible d'items (inscrits dans une table dédiée)

- Visualisation en TreeView

- Alerte par inscription dans le dossier, Message Box et ou icone d'alerte.

- Possibilité de produire une lettre type de rappel au patient ou un mail.

Réflexions et idées — desombre 2011/11/26 17:24

C'est un gestionnaire d'alertes, d'envoi de courrier sur alertes, etc … Mais aussi d'analyse. Il faudra pouvoir faire des requêtes de type : where patients - entre âge et âge - patho type - prevention - depuis date. Et idem pour les patients qui auraient du avoir mais n'ont pas eu.

Sur un plan d'IHM je penche pour une treeview pour le côté collapse qui permet de mieux choisir les items (cf receipts) et d'afficher des sous items eux même paramétrables (type, date, durée, …) Il faudra pouvoir ajouter des items à cette base.

— Eric Maeker, MD 2011/11/26 20:55

En lisant ta page, je prends doucement la mesure du truc.
Je propose de définir au mieux les données que doivent contenir un item type (modélisation de données). Par exemple, l'item doit contenir:

• une date de réalisation
• un historique
• un examen type
• un résultat
• une validation de résultat
• un temps de rappel programmable — desombre 2012/01/22 16:16
• une information au patient (la lettre dont tu parles)

Ensuite, on peut très bien créer un item de formulaire de FreeMedForms et créer des formulaires XML à l'aide de ce nouvel item. Par exemple, au final un code Qt/C++/SQL à écrire avec un cahier des charges précis, et un code XML maléable qui décrit les items et les règles de prévention. Exemple

  <MedForm ...>
    <Item type="prevention" name="...">
      <rules>[description encodée des règles de prévention]</rules>
      <exam><[codage de l'acte ou des actes à réaliser]/exam>
      <blabla>[textes explicatifs, liens vers référentiels...]</blabla>
      <norms>[définition des normes pour l'examen en question]</norms>
      ...
    </Item>
  </MedForm>

De sorte qu'au final on crée une page “Prévention” comme “Médicament”, à partir du formulaire XML ci-dessus. On a le treeview, la synthèse, l'historique, l'impression et l'intégration automatique des données dans la base de FreeMedForms. Ca fonctionnerait comme la page “formulaire patient”.

— desombre 2012/01/22 17:48 le stockage des données de prévention doit aussi permettre les requêtes d'analyse transversales : par exemple : “dans la patientèle “médecin traitant” quel nombre de coloscopies de telle date à telle date entre âge et âge, par rapport aussi à la clientèle générale”.