Communauté des utilisateurs de Medshake EHR/EDC

Bonjour,

Etant possiblement un nouvel utilisateur de Medshake, je souhaite tenter de l'adapter à ma pratique quotidienne afin de savoir s'il pourra répondre à mes besoin et me faciliter la tâche le plus possible.
Etant médecin vasculaire, je souhaite pouvoir, lors d'une consultation, rentrer les informations suivantes :

• Indication de l'examen / interrogatoire
• (ATCD, ttt, allergie, FDR CV ou d'insuffisnace veineuse mais ça c'est déjà dans le panneau latéral, que j'adapterai en fonction)
• Examen clinique
• Examen d'échographie avec, pour chaque type d'échographie possible, un texte par défaut saisi. Sachant qu'il est possible de faire plus d'une écho par consultation.
• une conclusion. Idéalement une conclusion globale pour toute la CS qui se remplit des conclusions prédéfinies pour chaque t échographie réalisée

Et ainsi, au final, générer automatiquement le compte-rendu de consultation avec toutes ces informations.

Autant les premiers champs sont simples, autant je ne suis pas certain de savoir quelle est la solution la plus simple pour saisir chaque examen d'échographie réalisé lors d'une CS et que tout soit rangé dans ladite CS.

Par exemple :

• echo des TSA : texte par défaut "A droite, artère carotide commune perméable, non athéromateuse, IR.. " et conclusion par défaut " bonne perméabilité des artères carotido..."
• echo aorte et artères membres inf : texte par défaut "Aorte non anévrismale, mesurée à XX mm. Artères iliaques communes et externes perméables..." Et sa conclusion par défaut..

Merci pour votre idée de mise en place

Alors alors ...

Le principe de base de l'EHR c'est : un examen = une ligne dans l'historique = un pdf

Là-dessus le module de gynéco obs est un exemple avancé de ce qu'il est possible de faire avec ces formulaires d'écho qui gère les grossesses jusqu'à 3 foetus.

Pour sortir de ce mécanisme de base, on est limité uniquement par les idées. Le module de médecine thermale donne un bon exemple de ce qu'on peut faire en synthèse. De mémoire, dans ce module, on va piocher dans les 2 consultations précédentes pour générer un compte rendu final de la cure, ainsi que dans les atcd.
Les class spécifiques au module montrent bien comment on peut aller piocher les données structurées nécessaires en base aux diverses étapes (création d'un nouveau form, d'un pdf ...)

Dans les 2 modules évoqués, les informations à extraire sont bornées par un contexte déclenché par un formulaire : soit une nouvelle grossesse, soit une nouvelle cure.
Mais on peut imaginer borner les choses en considérant les examens du patient donné à la date du jour uniquement, ce qui est beaucoup plus simple.

B.

Merci beaucoup pour votre réponse.

Notre spécialité ne se prête pas du tout à cela car une consultation peut contenir plusieurs examens différents.
Il pourrait être facile de créer un champ "Type" avec le ou les noms des examens réalisés, un champ "Résultats" et un champ "Conclusion" puis, selon le champ type choisi, de modifier le contenu par défaut de Résultat et Conclusion... Et de créer des textes par défaut pour les différentes combinaison (sachant que forcément un jour, je ferai une combinaison qui ne sera pas prévue..). Le problème est que je vais recopier plusieurs fois le même texte par défaut et lorsque je voudrai le modifier, il faudra le modifier partout.

J'ai vu effectivement le fonctionnement des grossesses gémellaires qui est une bonne solution pour éviter de modifier tout le code. Cela oblige à conserver des tables très grandes où la plupart des colonnes ne sont pas remplies la majeure partie du temps et cela ne permet pas de gérer des grossesses avec 4 embryons (bien que ça soit absolument exceptionnel).

Je vais commencer à regarder le code mais je verrais bien mettre en place une liste de formulaire qui pourrait apparaître à l'infini en dupliquant autant que nécessaire un même formulaire et en enregistrant les entrées les unes sous les autres dans une table SQL où une colonne pointerait vers l'index de la consultation en cours. Cela me permettra de gérer ma problématique et offrira plus de flexibilité pour autrui si besoin.
Dans le compte-rendu de consultation qui sera produit, il suffira de faire une boucle sur ces tables

Oula oulala Quand je vois la notion de créer une nouvelle table, c'est l'effet que ça me fait

Il n'y a surement pas besoin de ça. Le système de stockage de data très structurées et solide et il n'y a a priori aucune raison de le compléter par une table sup.

Reprenons pour être certain de bien comprendre : un patient vient, il peut subir plusieurs examens, à la fin, il faut rendre un compte rendu unique reprenant l'ensemble.
J'ai bien compris ?

Si c'est le cas : il faut créer un formulaire par type d'examen. Ce formulaire stocke la data structurée de chacun. Je n'y connais rien à la spé, mais je pense qu'il y a par exemple un certain nombre de données chiffrées (diamètre artériel, presssions ...) qui vont remonter par le dicom. Qu'il y ait en bout de course ou non un modèle pour sortir un pdf dédié sur un examen bien précis ne semble pas important.
Chaque examen validé va générer une ligne dans l'historique du jour pour ce patient. Ca me semble aussi une bonne idée pour visuellement voir facilement ce qui a été fait sur une consultation donnée et retrouver rapidement les résultats spécifiques antérieurs dans l'historique (et aller les pécher par ailleurs si on veut envisager des suivis d'évolution)

Enfin, à la fin de consultation, il faut générer ce compte rendu global. Là pas de problème. On doit pouvoir boucler sur la date du jour et extraire les champs importants à venir coller dans le formulaire final qui donnera le fameux PDF.
Si on a 40 examens possibles, on fait 40 if else dans le template de PDF final ou on repasse par une phase d'édition préalable à l'écran.

Vraiment tout est déjà là pour aboutir.

En résumé : j'ouvre mon dossier patient -> echographe configuré
Je fais les examens.
Je reviens au bureau, je déclenche un formulaire par type d'examen fait : echodop TSA, echo veineuse mb inf ... à chaque fois en 1 clic les données dicom s'insèrent. J'ajuste les textes par défaut.
Je demande enfin le formulaire de synthèse qui apparait à l'écran en étant déjà complété des données importantes piochées dans ce qui a été validé dans les minutes précédentes. J'ajuste ou pas, je valide, j'ai mon PDF final.

Tout le travail de code est sur le formulaire final. En ca l'exemple c'est le module médecine thermale et la dernière consultation.

Mais bon, j'ai peut être rien compris

B.

Je ne vous parlerai donc pas de mon ERP avec ses plus de 160 tables SQL alors.. Il ne faut pas avoir peur des tables SQL si elles sont bien pensées et articulées entre elles.

Reprenons pour être certain de bien comprendre : un patient vient, il peut subir plusieurs examens, à la fin, il faut rendre un compte rendu unique reprenant l'ensemble.
J'ai bien compris ?

Cela mis à part, vous avez compris la première partie.

Pour ce qui est de la 2e partie, notre pratique clinique (en tout cas pour les "jeunes") est incomparable à des échographies fœtales dans le sens où notre examen est dynamique, morphologique et hémodynamique. Donc outre peut-être un examen particulier, je n'ai besoin que d'un champ de texte large (si possible enrichi pour mettre du gras etc.) pour la description de l'examen. Pour résumer cela, par type d'examen échographique, j'ai juste besoin de :

• un select avec le type d'examen que je vais décrire juste en dessous (Troncs supra aortiques, artères membres inférieurs, veineux membre inférieurs etc.)
• un champ large avec texte enrichi pour décrire l'examen réalisé

Et c'est ce dernier champ qui sera initialisé selon la valeur du select, avec un texte par défaut.

Je ne sais pas si c'est plus clair ? C'est plus facile mais plus complexe à la fois :p

Ok, je vois. Je suis surpris, je croyais que la spé était plus concernée par des examens finalement très stéréotypés, du genre pour un TSA :
caroride G :

• diamètre : X mm
• lumière : libre, athéromatheuse ...
  etc etc ...

Bref, tout cela est encore moins compliqué que prévu. Il faut donc un unique formulaire de consultation avec X champ de type textarea (un par zone écho) qui comporte un texte pré rempli de l'examen par défaut et une colonne latérale avec chaque zone et une case à cocher qui provoque l'affichage / masquage du textarea concernée (et qu'il me semble pas mal de coller en base pour être capable de sortir des stats).

Pour les tables SQL, je n'en ai pas vraiment peur. Le site MedShake.net en a un petit paquet et l'api CCAM un gros paquet de plus.
La question n'est pas là.
Il s'agit simplement du fait que le moteur de stockage de MedShake est pensé pour 2 choses :

• avoir des données le plus structurées possibles
• avoir une traçabilité forte de tout ce qui y est saisi.
  Tout ce qui va utiliser le moteur de création de formulaire va bénéficier de la chose. Tout ce qui va en sortir va nécessiter de raccrocher des morceaux de façon plus ou moins sauvage et intégré.
  Il suffit de voir le peu de ligne de code de chaque module nécessaire et la grande variété des réalisations (du squelette cliquable du module chiro au formulaire du module thermale) pour constater que toutes les briques sont là.
  Mais ce qui est assurément compliqué, c'est de s'imprégner de tout ça pour rentrer dans ce moule. Plus compliqué initialement que d'envisager coller une table de plus, ce que chaque personne découvrant le code ne manquera pas d'avoir comme réflexe pour aboutir simplement.

J'ajoute enfin votre question reçu par mail :

je me suis rendu compte que je n'ai pas vu une fonctionnalité essentielle de tout logiciel métier (donc forcément j'imagine que je ne l'ai pas vu) : comment faites-vous pour produire un compte-rendu de consultation à adresser à plusieurs personnes et que, soit le CR est transmis par mail (apicrypt..), soit une notification est mise à la secrétaire (ou quelqu'un d'autre) pour pouvoir imprimer l'exemplaire pour la personne X et la mettre sous pli. Je n'ai pas vu non plus l'endroit où l'on spécifiait la liste des destinataires d'un CR et ainsi que cette liste apparaisse dans le CR.

Alors sur ce point, j'ai cherché un article dans ma doc et c'est vrai qu'il n'y a rien.
Cependant on voit la chose fonctionner dans la vidéo au sommaire de medshake.app
A 25 s on voit l'utilisation de l'onglet "Liens du patient" qui permet d'attacher un dossier patient à un ou plusieurs médecins/correspondant.
A partir de là la suite de la vidéo montre que l'en tête administrative du dossier se met à jour.
A 2min50 on voit ensuite l'envoi du compte rendu généré.

A ma connaissance, personne n'a encore réalisé de template de génération de PDF qui vient incruster les correspondants. Il faut dire que tout est optimisé surtout pour l'envoi numérique. Un mail par destinataire, mais comme il s'envoie en 1 clic.
S'il y avait besoin de ce coté là, il y a toute une mécanique de class qui permet dans un module de venir compléter les tags utilisables dans un template de génération de PDF.

Un exemple avec le module médecine thermal ici :
https://github.com/MedShake/MedShakeEHR ... urrier.php

Et disons qu'on pourrait même envisager d'aller ajouter tout cela dans la class msCourrier de la base du logiciel, parce qu'effectivement avoir la liste des correspondant dans les templates PDF, c'est une bonne idée.

Voilà pour aujourd'hui.

B.