<![CDATA[RUFUS - Blog]]>Mon, 02 Mar 2026 16:58:27 +0000Weebly<![CDATA[CATALINA]]>Wed, 09 Oct 2019 05:09:36 GMThttps://www.rufusvision.org/blog/catalina
Pour les utilisateur de Mac pressés qui se sont un peu trop vite dépêchés de faire la mise à jour vers la dernière évolution du système Catalina et ne peuvent plus afficher les photos ou pdf dans Rufus.

C'est normal parce que Catalina interdit par défaut tout accès aux fichiers du dossiers documents et bloque donc mysql quand il veut accéder aux photos stockées sur le disque.
​Pour corriger le problème, il faut donc autoriser mysql à avoir accès aux photos et autres documents.
  • Menu Pomme/Préférences Système
  • Icône Sécurité et confidentialité
  • Onglet Confidentialité
  • Clic sur le cadenas en bas à droite pour modifier et entrer le mot de passe administrateur
  • Dans la colonne de droite choisir Accès complet au disque
  • cocher dans le tableau de droite la case mysqld
]]><![CDATA[Version Linux]]>Tue, 29 May 2018 05:44:13 GMThttps://www.rufusvision.org/blog/version-linux
Le code source est fonctionnel sous Linux aussi bien que sous MacOS. Vous pouvez le télécharger et le compiler si vous êtes un peu masochistes.
Le travail d'adaptation à Linux bat son plein.
Le programme fonctionne sous Linux mais certains aspects ne sont pas encore aboutis, comme les sauvegardes, l'aspect des polices...etc...
La publication de la version Linux ne devrait plus tarder, probablement durant l'été 2018.
]]><![CDATA[La video dans Rufus]]>Sun, 11 Mar 2018 11:46:41 GMThttps://www.rufusvision.org/blog/la-video-dans-rufus
Une démo de l'intégration de la video dans Rufus avec l'exemple d'une consultation post-opératoire : rédaction des documents post-opératoires et intégration dans la base de  la video de l'intervention.
Les noms du patient et des médecins sont bien entendu faux. La demo est un peu floue en raison des contraintes de compression liées à la diffusion sur le web. Télécharger la video en HD
N'importe quelle video peut être intégrée dans le dossier d'un patient, tous les formats courants sont acceptés. Un slider en bas de la fenêtre permet de se déplacer dans la video.
Une video peut-être recopiée sur un autre media (clé USB donnée au patient p.e.) en cliquant sur le bouton d'enregistrement en bas à droite.
]]><![CDATA[La comptabilité en multiutilisateurs]]>Wed, 20 Dec 2017 07:55:37 GMThttps://www.rufusvision.org/blog/a-comptabilite-en-multiutilisateursl
La personnalisation des utilisateurs est publiée en version beta.

Il y aura encore quelques bugs à corriger dans les semaines qui viennent.
D'ores et déjà, Rufus peut prendre en charge à peu près tous les modes d'exercice:
. soignant (ophtalmologiste, orthoptiste ou autre), secrétaire ou autre non soignant.
. pour les soignants, la possibilité de travailler en tant que responsable, assistant( volant ou non) ou alternant les 2 formes d'exercice.
. pour la comptabilité et l'enregistrement des actes et des dépenses: l'exercice libéral ou salarié, le remplacement.
. la possibilité de travailler dans le cadre d'une société d'exercice: SEL, SCP, SELARL...etc...

La version sans comptabilité suivra dans les semaines qui viennent.
]]><![CDATA[AMoiLeNek, DMP, HAS, marquage CE, lobbying, Doctolib, normes, et Rufus...]]>Sun, 17 Dec 2017 12:53:31 GMThttps://www.rufusvision.org/blog/amoilenek-dmp-has-marquage-ce-lobbying-doctolib-normes-et-rufus
La manie des normes arrive à ses fins en informatique médicale et nos logiciels ne seront plus homologués à court terme. On parle de 2019 pour l'obligatoire homologation, ce qui implique homologation LAP, homologation DMP, intégration d'une messagerie sécurisée..etc...
Tout ceci est pétri de bonnes intentions et frappé au coin du bon sens.

Le problème est le suivant : est-ce vraiment utile ?
Qui va s'amuser à pirater le courrier que vous adressez au confrère pour lui dire que madame Michu a une bonne conjonctivite ?
Ne pouvons pas nous-mêmes nous sentir responsable de ça et demander ce cryptage (c'est très simple) si on en éprouve le besoin auprès de notre éditeur de logiciel ?

Autre bonne idée, le logiciel d'aide à la prescription (LAP) : le LAP va vérifier pour chacune de vos ordonnances l'absence de contre-indication rhédibitoire, vous demander de forcer la règle au cas où et bien entendu enregistrer tout ça de façon définitive dans vos données.
A l'extrême, pour prescrire un flacon de collyre, il vous faudra parfois vérifier systématiquement urée-créatinine.
Argument des Autorités : les erreurs du médicament nous coûtent cher, on les limitera avec le LAP pour le bien du patient et de notre budget !!! On les remercie.
Une ordonnance médicaments pré-remplie comme on le fait tous : désormais interdit, toute ordonnance pharmacie devra être générée par le fameux LAP.
Pire, c'est déployé partout ailleurs en Europe.

Qu'est ce qu'on va y gagner ? Rien si ce n'est un alourdissement considérable de notre activité (le LAP, c'est lent - très lent et très ch...) et un alourdissement considérable de la facture logicielle.
Alors pourquoi tant d'acharnement à normaliser ainsi les logiciels ? Il suffit de regarder la situation allemande pour comprendre.
Là bas, en ophtalmologie, 2 logiciels se disputent le gâteau pour ce que j'en sais et se partagent donc le marché dans une situation de quasi-monopole.
Il est obligatoire de s'informatiser et de souscrire une maintenance. Prix annuel : 6 000 euros par poste, incontournables.
En France, 5 000 ophtalmo et 6 000 euros par poste auxquels il faut rajouter les postes secrétaires, salles d'examen complémentaire, cabinets secondaires....etc....
On est devant un marché potentiel de 40 millions d'euros annuels. A multiplier par le nombre de spécialités médicales et on n'est plus très loin du demi-milliard.

Les logiciels métiers en médecine générale ont vu ces dernières années un regroupement considérable et, même si des dizaines de logiciels persistent, ils appartiennent la plupart du temps à 2 ou 3 grosses boîtes de dimension européenne qui ont donc la mainmise sur ce marché.
Alors, quand on est un industriel du logiciel métier, on ne néglige pas les "petits" marchés comme l'ophtalmologie.
D'autant que créer « de novo » un logiciel coûte à la louche 1 million d'euros. 1 millions d'euros à dépenser pour investir un marché qui rapporte 40 fois plus tous les ans, on imagine la suite.
A partir de là, logique moderne type Afflelou, ou Doctolib: il faut bien sûr être le premier parce qu'on devient alors indéboulonnable.
La guerre pour le gâteau remonte même à Bruxelles puisqu'on se bat là haut pour savoir s'il faut imposer l'homologation DMP ou le marquage CE aux logiciels médicaux.
Bref, on est entrain de se chamailler pour savoir si ça doit rester des marchés nationaux ou européens.

C'est pour cette raison qu'on va assister dans les mois qui viennent à de grandes manœuvres dans lesquelles des compagnie américaines seraient même présentes.
Il se murmure que M. Simoncini, qui ne veut décidément toujours pas s'en aller, ainsi que d'autres, utilisent largement les oreilles complaisantes de membres très haut placés de l'état pour hâter les évènements.
Tout le monde veut être présent au festin de l'argent des ophtalmos et les labos pharmaceutiques seraient aussi sur les rangs.
Comme Sodebo pour les cantines scolaires, on se bat pour imposer des normes, on investit beaucoup d'argent et on essaie d'être le premier sur place.
On obligera bien sûr les ophtalmos à s'équiper et à payer une maintenance et s'ils râlent, on leur montrera que c'est une norme européenne. Finie la vieille copie de StudioLogic qui tourne depuis 2002 sans renouveler le contrat de maintenance.
Ces gueux d'ophtalmos, on les connait : ça crie un peu au début mais ça finit par se laisser faire de toute façon.
​
La suite, il suffit de se rapporter à l'histoire moderne pour la deviner. On laisse couler ou on rachète à prix d'or (relativement à leur taille) nos petits éditeurs de logiciel (il n'y a pas de temps à perdre - il faut être le premier).
Editeurs qui de toute façon auront beaucoup de mal à faire les investissements nécessaires pour faire évoluer leur code.
Et on présente des logiciels bien finis, bien léchés. On expliquera aux clients qu'il faut maintenant migrer de Studio+ à AMoiLeNek, en leur montrant que de toute façon, c'est nettement mieux et beaucoup plus joli.
On calmera nos consciences par le biais de quelques pointures de l'ophtalmologie française qui viendront nous affirmer que « oui , tout ça est génial, notre équipe s'est d'ailleurs beaucoup investie dans la mise au point du truc». 
Si vous insistez, on vous dira que c'est une technologie ultra moderne, du « client léger » et que c'est inutile de rentrer dans les détails.
On insistera lourdement pour vous dire que vous n'avez besoin que d'un tout petit PC, Mac ou même un smartphone et on glissera rapidement sur le détail complètement inutile qui ne compte pas, à savoir que vos données seront hébergées à distance, dans le serveur de l'éditeur.
Qui pourra lui au passage largement se sucrer sur l'exploitation de vos données (anonymisées bien sûr, conformément à la loi, faut pas déc.).
Et là, ça ira bien plus loin que les RDV de Doctolib qui font si peur à certains d'entre nous.

Rapidement, il y aura des regroupements et des ententes et on vous expliquera que oui, les prix ont triplé mais c'était obligatoire en raison de la technologie qu'il a été nécessaire de développer pour se conformer à ces maudites normes et fabriquer un logiciel avec une interface moderne.
Et que de toute façon, c'est la sécu et la loi, on n'y peut rien, vous devez payer.

La solution? Fédérer les énergies pour ne pas se faire tondre.
Créer un logiciel métier SANS BUT LUCRATIF POUR QUI QUE CE SOIT.
En faire faire la maintenance par des petites boîtes totalement indépendantes qui le connaitront bien et resteront dans des tarifs honorables.
Garder le code public, pour que tout le monde puisse le faire évoluer pour l'adapter à ses besoins.
Ne pas stocker ses données médicales sur les disques durs d'une société privée.
Se préparer à d'autres attaques, ces gens là ne se décourageant jamais.

Il faut 300 000 euros pour faire évoluer un logiciel comme Rufus et lui adjoindre agenda (nettement moins si on l'interface avec un existant), DMP et autres quincailleries. Ou 1 million si on veut repartir de zéro.
Soit, suivant les cas, entre 1 et 3% de ce qu'on dépensera obligatoirement tous les ans d'ici peu de temps si on ne bouge pas.

Serge Lainé, gaucho de base.
]]><![CDATA[Journal du bug - les derniers appareils et un git pour Rufus]]>Sun, 03 Dec 2017 21:08:02 GMThttps://www.rufusvision.org/blog/journal-du-bug-les-derniers-appareils-et-un-git-pour-rufus
Beaucoup d'évolutions sur Rufus:
la liste des matériels implémentés n'a cessé de s'allonger.
la configuration des profils utilisateurs implémente à peu près toutes les situations possibles et va permettre d'envisager le fonctionnement de Rufus dans toute sorte de configuration, avec ou sans compta, remplacement, salariat, rétrocession...etc...
Tpus les OCT du marché sont implémentés aujourd'hui.
​Enfin, pour les connaisseurs, Rufus est présent sur GitHub et on peut suivre l'évolution de son code. Le nom du dépôt est Rufus. 
]]><![CDATA[Journal du bug - la messagerie instantanée]]>Thu, 29 Jun 2017 11:49:32 GMThttps://www.rufusvision.org/blog/journal-du-bug-la-messagerie-instantanee
La messagerie de Rufus est opérationnelle. Elle offre la possibilité:
  • d'envoyer des messages instantanés à un ou plusieurs utilisateurs
  • de qualifier ces messages en tâche à réaliser avec une date d'échéance
  • de répondre à un message reçu
  • d'attribuer le message à un patient de la base
  • de qualifier les messages comme urgents
]]><![CDATA[Le journal du bug - OPTOS DAYTONA et DAYTONA PLUS]]>Tue, 27 Jun 2017 17:42:30 GMThttps://www.rufusvision.org/blog/le-journal-du-bug-optos-daytona-et-daytona-plus
Intégration des appareils Optos Daytona et Daytona plus. La compression à 256Ko passe très bien, même sur un écran de 2560x1440.
]]><![CDATA[Le journal du bug - CENTERVUE EIDON et COMPASS]]>Sat, 17 Jun 2017 06:37:47 GMThttps://www.rufusvision.org/blog/le-journal-du-bug-centervue-eidon-et-compass
L'intégration de la gamme des retinographes Eidon et Compass a mis en évidence un problème lié à la grande qualité de ces appareils: le volume des images qu'ils produisent.
Centervue n'a pas prévu de compression des images et chaque cliché pèse au moins 5Mo, voire plus quand il s'agit de montages photographiques.
Dans un centre qui archive plusieurs dizaines de clichés par jour, le volume généré deviendrait rapidement incompatible avec une taille raisonnable de la base de données, d'autant que l'affichage sur un écran ne nécessite pas une telle qualité d'imagerie.
Dans Rufus, chaque cliché au format jpg est donc comprimé à une taille inférieure à 256Ko avant son intégration dans la base de données. Les clichés de fond d'oeil supportent sans problème des taux de compressions élevés et il n'y a aucune perte de qualité visible à l'écran.
]]><![CDATA[Journal du bug]]>Thu, 15 Jun 2017 04:29:06 GMThttps://www.rufusvision.org/blog/journal-du-bug4114509
La nouvelle version du programme apporte:
. une messagerie instantanée qui permet d'envoyer des messages à n'importe quel utilisateur du programme. Très pratique pour communiquer avec un utilisateur à distance, connecté par Internet,
. un lien direct vers la CCAM en ligne,
. la possibilité de comprimer les pdf incorporés dans la base,
. un meilleur paramétrage des motifs de consultation,
. l'intégration des appareils de la gamme Centervue Eidon
​. la correction de bugs mineurs...etc...
]]>