Chers collègues,
Vous avez sans doute été destinataires d’un courrier de 2 représentants syndicaux de la région s’opposant à la poursuite de l’utilisation de SMUR-t@b, ce qui est pour le moins inhabituel pour un projet conçu par des urgentistes, pour des urgentistes
Pour information et transparence, voici point par point les réponses techniques et précises à chacun des éléments identifiés dans ce courrier:
Allégation 1
« Une mise en place sans réelle concertation avec les utilisateurs »
Le projet de cet applicatif a été validé le 12 juin 2017, lors de l’assemblée générale constitutive d’Est-RESCUE, devant une assemblée de représentants (médecins, cadres et directeurs). Fin 2017, après avoir formalisé le projet avec notre GRADeS Pulsy puis déposé un dossier auprès de l’ARS, celui-ci a été accepté avec un financement initial par le FIR à hauteur 75%.
Dès début 2018, nous avons débuté une concertation avec les SMUR de la région lors de 3 réunions associant, suite à un appel à participation adressé à toutes les structures d’urgence de la région, une vingtaine d’urgentistes exerçant dans des SAMU-SMUR-SAU de CHU, CHR et CH (dont, accessoirement, les trois médecins d’Est-RESCUE qui sont urgentistes et qui interviennent toujours en SMUR) mais aussi des représentants de notre collège de médecine d’urgence (le président du COMUGE est destinataire de notre réponse). Il est à remarquer que les deux cosignataires du courrier ont participé à ce travail de concertation. Par la suite, une réunion a eu lieu le 19/09/2020, regroupant les utilisateurs de la version 1 (toujours avec la participation des cosignataires) afin de faire un RETEX et de programmer les modifications à réaliser dans la version 2 (plus de 90% des remarques ont été prises en compte, les autres étant la plupart du temps non réalisables techniquement ou avec un rapport intérêt/coût rédhibitoire). Au fur et à mesure du développement complexe de cette V2, une information des utilisateurs a été régulièrement réalisée, via notre site et via une newsletter Est-RESCUE.
Allégation 2
« L’accord du patient n’est pas valablement recueilli »
Conformément à la RGPD et au code de la santé publique, le recueil du consentement du patient est obligatoire sauf en cas d’urgence absolue. Le patient peut revenir par la suite sur son consentement s’il le souhaite afin d’appliquer ses droits à l’utilisation de ses données. Il appartient à l’équipe de prévenir le patient, comme pour tout usage d’outil numérique, et la traçabilité est faite lorsqu’il est apte à consentir. Dans l’hypothèse contraire, le médecin SMUR, dans la Version 1 de l’applicatif, n’a pas la possibilité de sélectionner « non apte à consentir » et ne peut saisir que « oui » ou « non ». Si le médecin saisit « non », la validation de la fiche SMUR et donc l’archivage numérique du dossier ne sont pas autorisés. Cette fragilité a été remontée par les utilisateurs lors de la réunion de RETEX sus décrite et, a fait l’objet d’une correction dans la V2 en cours de déploiement. Dans cette V2, l’utilisateur aura trois types de réponses à la demande du consentement : “Non”, “Ne peut se prononcer”, “Oui”, afin de prendre en compte les cas où le patient est dans l’incapacité de donner une réponse lors de la prise en charge. Si le patient ne donne pas son consentement, le compte rendu sera transmis au service d’accueil du patient mais les données ne seront pas utilisées à des fins statistiques ou d’études. Pour remarque complémentaire, la saisie d’un dossier aux urgences fait rarement l’objet d’une demande préalable d’autorisation…
Allégation 3
« Les dossiers ne sont pas transmis de façon sécurisée »
La transmission des dossiers peut se faire de deux façons :
– soit par messagerie sécurisée vers le service destinataire (si ce service dispose d’une MSS, le déploiement de ces messageries étant à la charge des établissements) et vers la base SMUR pour archivage. Il est à noter que le GIP Pulsy promeut l’usage de ces messageries et fournit même gratuitement des adresses MSS aux établissements n’ayant pas encore de fournisseur
– soit en récupérant le pdf du dossier sur un site en rentrant un code de téléchargement. Le code de téléchargement des fiches n’est visible que par l’équipe du SMUR ayant pris en charge le patient. Ce code est généré aléatoirement avec 13 caractères afin qu’une personne malintentionnée ne puisse pas le déduire et sa validité dans le temps est réduite à 24 heures. Il est, au même titre que nos fiches SMUR papier, de la responsabilité du médecin SMUR de transmettre ce code au service receveur de manière confidentielle.
Allégation 4
« le système est isolé des SAMU »
L’intérêt de la communication du logiciel SAMU vers un logiciel SMUR est évident. Le schéma retenu au niveau national est un schéma à double sens SAMU-ORU-SMUR, l’intérêt d’un bouclage temps réel avec l’ORU étant de pouvoir être utilisé indépendamment du type de progiciel du SAMU. Pour communiquer, il faut, certes des connecteurs, mais avant tout un format d’échanges constitué de champs et de jeux de valeurs pour chaque champ. Cela fait maintenant trois ans que nous travaillons, au sein de la FEDORU (Fédération des ORU) et en lien avec le groupe SI-SAMU national, sur ce format de données et nous espérons être en mesure de publier des recommandations sur ce format (dénommé RDR, résumé de dossier de régulation, a l’instar du RPU et du RPIS) au plus tard en octobre. Dés lors, nous pourrons enfin envisager une communication SAMU-ORU-SMUR (évitant les redondances de saisies) d’autant que l’ORU Occitanie, qui dispose déjà de connecteurs avec AppliSAMU et Centaure, travaille actuellement sur un connecteur avec Exos, et que, concernant le SI SAMU national, nous serons les premiers à pouvoir en bénéficier compte tenu du premier déploiement en cours sur le SAMU 68.
Allégation 5
« Aucun suivi des anomalies »
Depuis le début de l’usage, le support Pulsy a reçu environ 650 appels avec 220 « tickets » créés (correspondant à des anomalies à explorer, les autres appels étant directement résolus en ligne) et environ 150 mails sur notre adresse Est-RESCUE donnant lieu à « 45 tickets ». Ces fameux « tickets » sont suivis quotidiennement. A ce jour, la plupart de ces anomalies ont été corrigées et celles restantes, qui nécessitent le travail le plus conséquent, seront résolues dans la V2 (au 22/09/20, il reste 2 tickets en cours d’investigation).
Allégation 6
« Un dossier chronophage destiné plus à alimenter une banque de données statistiques qu’à servir efficacement le patient »
C’est une rhétorique bien connue et déjà entendue lors de l’informatisation des SAMU puis lors de l’informatisation des services des urgences. Alors oui, un dossier informatisé est souvent, au moins au début, plus chronophage. Pour SMUR-t@b, nous avons essayé de limiter cette contrainte en évitant au maximum les zones de texte libre, en utilisant la dictée vocale, et permettant la prise de photo en particulier des ordonnances du patient… A contrario, ces dossiers sont toujours de meilleure qualité car lisible et nettement plus complet du fait des champs obligatoires (idem RPU ô combien polémique lors de sa mise en place en 2004). Par ailleurs, ils permettent la connaissance et la reconnaissance de l’activité, la réalisation d’études scientifiques, la mise à disposition de procédures régionales et bientôt la télé expertise.
Allégation 7
« la pérennité du financement des SMUR dépend de l’utilisation de SMUR-t@b »
Il n’existe à ce jour, contrairement aux RPU, aucun texte réglementaire obligeant à la remontée d’un RPU SMUR communément appelé RPIS, ce qui exclu de facto cette allégation. Pour autant, il est probable que cette exigence réglementaire arrive dans un avenir pas si lointain et il se trouve que ce RPIS est déjà intégré dans le dossier SMUR-t@b. Par ailleurs, il ne nous paraît pas aberrant de devoir justifier son activité SMUR à l’instar de l’activité des urgences via le RPU ou de celle des services intra hospitaliers via le PMSI.