Agenda multi-sites : éviter les conflits de trajet, de lieu et d'heure

Donner au site une identité, pas seulement un nom libre

Un site doit avoir une adresse complète, une entrée ou un bâtiment si nécessaire, des indications d'accès et un fuseau lorsqu'il y a lieu. Reliez le rendez-vous à une identité de site stable. Si deux lieux ont le même nom commercial, afficher seulement ce nom sur le rappel expose à une erreur de destination.

Vérifiez ce qui se passe lors d'un déménagement : faut-il conserver l'ancienne adresse pour l'historique et la nouvelle pour les rendez-vous futurs ? Une modification globale du libellé ne doit pas faire croire qu'une consultation passée s'est déroulée ailleurs. Les rendez-vous déjà confirmés concernés par un changement nécessitent une information explicite.

Raisonner entre deux sites dans un ordre donné

Le temps de trajet peut différer selon le sens et la plage horaire. Prévoyez aussi les opérations nécessaires à l'arrivée et au départ ; une durée de conduite seule ne suffit pas toujours. Faites valider des marges opérationnelles réalistes par l'équipe, sans les présenter comme des temps garantis.

Exemple fictif : une consultation se termine à 11 h sur le site A. Le déplacement et l'installation prévus totalisent 40 minutes. Le premier début possible sur le site B est alors 11 h 40, sous réserve que les autres ressources soient disponibles. Une place à 11 h 30 doit être refusée même si les deux rendez-vous ne se chevauchent pas.

Le trajet doit être recalculé lorsque le site change ou qu'un rendez-vous s'intercale. Bloquer une pause fixe à midi ne protège pas nécessairement un déplacement ajouté en matinée. Si le logiciel ne sait pas traiter cette contrainte, l'organisation doit la compenser explicitement avec des plages bloquées vérifiées.

Éviter le dédoublement d'une ressource mobile

Un appareil ou une équipe itinérante ne doit pas avoir deux identités indépendantes, une par site, si cela permet de le réserver simultanément. L'ANS inclut lieux, objets et personnes dans le périmètre de l'agenda partagé ; ce repère aide à modéliser la ressource avant d'ajouter des filtres par établissement.

Décrivez sa capacité réelle et son temps d'indisponibilité pendant le transport. Le secrétariat d'un site doit pouvoir savoir qu'une ressource manque sans nécessairement voir le détail des patients d'un autre site. Partager une disponibilité n'exige pas de partager un dossier.

Références : Agence du Numérique en Santé — G_NIUS, agenda.

Afficher une heure liée à un lieu

Dans iCalendar, une date-heure locale sans fuseau peut être interprétée comme une heure dite flottante. Pour un rendez-vous à un instant précis, l'export doit exprimer correctement cet instant et son contexte temporel. La RFC 5545 décrit ces représentations ; elle ne garantit pas qu'un outil les exporte correctement.

Testez avec un calendrier configuré dans un autre fuseau : confirmation, rappel, fichier ICS et page de modification doivent rester cohérents. Pour une série, vérifiez également les changements d'heure. L'heure montrée au patient doit être intelligible, par exemple en précisant qu'il s'agit de l'heure du lieu de consultation lorsque l'ambiguïté est possible.

Références : IETF — RFC 5545, iCalendar.

Faire un exercice de mauvais site avant qu'il arrive

Créez un rendez-vous fictif sur le site B, puis parcourez la confirmation depuis un téléphone. L'adresse est-elle visible avant le lien de navigation ? Le numéro appelé correspond-il à l'accueil pertinent ? Le patient peut-il distinguer une entrée principale d'une entrée dédiée sans lire une longue page ?

Rejouez ensuite un changement vers le site A. Vérifiez le nouveau message, l'ancien lien et l'historique côté équipe. Le scénario doit aussi prévoir une personne qui se présente au mauvais accueil : qui la renseigne, comment joindre le site attendu et qui décide d'une reprogrammation ? Ce sont des responsabilités à écrire, pas des automatismes à supposer.

Mesurer les erreurs sans créer un classement trompeur

Regroupez les incidents par cause : adresse ambiguë, rappel ancien, temps de trajet absent, ressource indisponible ou erreur de sélection. Un simple compteur de retards par site masque ces différences. Corrigez la cause la plus fréquente, puis vérifiez si elle disparaît dans les semaines comparables suivantes.

Ne concluez pas qu'un site est moins performant parce qu'il reçoit les parcours les plus complexes. La comparaison doit tenir compte de l'activité et des contraintes ; son objectif est d'améliorer la coordination, non de produire un palmarès.

Questions complémentaires