MODERNISATION SI ET TÉLÉCOMS DES SAMU CENTRE 15

Transcription

1 MODERNISATION SI ET TÉLÉCOMS DES SAMU CENTRE 15 Mars 2012 Etude réalisée avec le concours de Classification : Public 1 / 119

2 Classification : Public 2 / 119

3 ASIP Santé Mars 2012 SYNTHÈSE STRATÉGIQUE Le présent document fait suite à la mission confiée à l ASIP Santé par la DGOS dans le cadre de la modernisation des équipements informatiques et de télécommunication des SAMU Centre 15. Elle présente le scénario et la feuille de route retenus à l issue de cette démarche. L objectif est de statuer sur le lancement d un programme répondant aux enjeux majeurs auxquels les SAMU doivent faire face dans les prochaines années : efficience, pilotage interrégional, gestion de crise. Le système d information et de télécommunication constitue pour chaque SAMU un composant vital dont la qualité conditionne le service rendu aux patients et à la collectivité. Cette activité s appuie actuellement sur les ressources techniques et logistiques des établissements de santé auxquels elle est confiée ; l hétérogénéité résultante ne permet pas de garantir l égalité d accès à une réponse médicale d urgence sur tout le territoire satisfaisant les exigences sociétales attendues d un tel service. Pour que les 101 centres de régulation et de réception des appels d urgences bénéficient d un système d information de qualité en situation nominale et adaptable à toute situation d exception relevant de la gestion de crise, un programme de modernisation du système d information de ce service national doit être entrepris. L étude entreprise à la demande de la DGOS par l ASIP Santé s est appuyée sur un laboratoire d idées constitué pour l occasion de responsables de SAMU et d experts en systèmes d informations et en centres d appels. La cible identifiée se détaille dans un scénario ambitieux, mais réaliste, concrétisée par une proposition de feuille de route. Le système cible s appuie sur une infrastructure mutualisée de services de système d information et de télécommunication évolutive, lancée à la fin de la 2 ème année et déployée progressivement à l ensemble des 101 SAMU dans une perspective de généralisation complète à une échéance de 10 ans. Le financement d un dispositif national nécessite un investissement prévisionnel en matière d infrastructure estimé à 30 M à déléguer à une maitrise d ouvrage nationale. Les coûts de fonctionnement aujourd hui assumés par chaque établissement de santé doivent abonder le financement de ce nouveau dispositif mutualisé. L élaboration pour ce programme d un pilotage national constitue un facteur clef de succès. Il est l occasion d associer l ensemble des professionnels de santé des SAMU et tous les acteurs de l aide médicale d urgence à la réalisation d une politique publique à la hauteur des attentes des citoyens en matière d urgence médicale. Diagnostic Le rapport Mardegan de juillet 2010 relatif «à la modernisation des SAMU» fait apparaître la persistance de fragilités opérationnelles et technologiques, ainsi qu une grande hétérogénéité des équipements, des ressources et des niveaux d activité. L évolution croissante et constante de l activité des SAMU, à laquelle s ajoutent les besoins de renouvellement de leurs outils techniques (système d information, téléphonie) expliquent, en partie, les difficultés qu ont rencontrées certains de ces services pour assurer leurs missions de manière satisfaisante. Cette question de l adaptation des moyens techniques est au cœur de l élaboration d un dispositif de gestion de crise ou de catastrophes sanitaires (pandémie grippale, etc.). Classification : Public 3 / 119

4 ASIP Santé Mars 2012 C est ce constat qui incite à s interroger sur la nécessité d une forte action de modernisation des plateformes d appel des SAMU Centre 15. Par ailleurs, un certain nombre d évolutions voire de ruptures technologiques importantes impactent dès à présent les solutions mises en place dans les SAMU Centres 15. La téléphonie et le transport de la voix sur IP (ToIP et VoIP) permettent d intégrer finement leur usage dans le contexte d utilisation des SAMU (logiciel de régulation et applications en mobilité). Le développement du «Cloud Computing» ouvre la perspective de déploiement d une application de régulation médicale des appels d urgence en mode service hébergé (SaaS 1 ) supplantant la logique actuelle d acquisition et de mise en place d un système d information par chaque SAMU. Axes stratégiques L étude Mardegan prolongée par la réflexion réalisée dans le cadre de cette étude a identifié les axes stratégiques suivants non satisfaits dans le contexte actuel : Rendre le juste soin avec un service de qualité élevée Le service délivré par le dispositif actuel, montre une hétérogénéité importante pénalisant la réponse apportée par les SAMU. Gestion de la régulation et pilotage à l échelle nationale en situation nominale Le dispositif actuel ne permet pas de consolider de manière effective les données d activités de chaque SAMU sur des critères adaptés à un pilotage de l activité. La création des Observatoires Régionaux des Urgences répond à cette problématique à l échelle régionale sans consolidation possible et illustre les dynamiques à développer au niveau national. Gestion de crise nationale L élaboration du dispositif national «SINSAMU» de gestion des appels dans le cadre de la gestion de la pandémie grippale A H1N1 en 2010 a montré concrètement l intérêt d une démarche nationale dans ce genre de situation, mais également les limites associées à une réponse élaborée dans l urgence face à une situation de crise majeure. Disposer d un système hautement disponible Chaque SAMU est confronté à des dysfonctionnements de son logiciel de régulation qui pour certains peuvent être importants (de quelques heures à plusieurs jours). Garantir la confidentialité des données de santé Le respect du droit des patients en matière de gestion de données de santé implique la mise en œuvre de règles et de processus dépendants à ce jour de la capacité de chaque établissement à s inscrire dans cette démarche. Interactions avec les partenaires (SDIS, SOS médecin, etc.) et les logiciels de santé (DMP, Annuaire des ressources mobilisées en situation d urgence (ROR)) 1 «Software as a Service» Classification : Public 4 / 119

5 ASIP Santé Mars 2012 Chaque SAMU doit mettre en œuvre le même projet d intégration de son infrastructure dans son environnement. La factorisation de ces actions est synonyme d efficience et de qualité. Leur décloisonnement est essentiel. Adéquation entre les ressources attribuées et l activité des SAMU Les attributions budgétaires ne sont que faiblement corrélées aujourd hui aux données d activité des différents SAMU. Scénarios étudiés Quatre scénarios possibles ont été identifiés et parmi eux, deux ont été écartés rapidement et deux ont fait l objet d une analyse détaillée permettant l élaboration de feuilles de route distinctes. Les scénarios écartés sont cités ici pour mémoire. Un scénario basé sur la construction d une solution de logiciel de régulation unique, mais déployée à l échelon local au sein de chaque centre de régulation a été écarté. Il ne répondait pas aux exigences de gestion de crise, s appuyait sur une stratégie industrielle en matière d offre logicielle pénalisée par la constitution d un monopole non maitrisé et s avérait difficile à concrétiser globalement, car dépendant de ressources propres à chaque établissement de santé. Un scénario s appuyant sur la constitution de plateformes téléphonie/logiciel de régulation élaborées à l échelon régional a également été écarté. Couteux à mettre en œuvre, car répliquant la même infrastructure pour chacune des régions, ce scénario renforçait le cloisonnement régional ou interrégional et ne répondait pas à la nécessité d un pilotage national nécessaire à la gestion de crises. Un scénario basé sur la labellisation des solutions du marché renforcée par une infrastructure nationale de gestion des appels et d échange de dossiers de régulation inter-samu a fait l objet d une analyse plus poussée. Ce scénario contraignait les éditeurs à rendre leur offre interopérable (entre elles, ainsi qu avec les différents acteurs externes en intégrant les référentiels nationaux). Pour garantir une gestion des appels au 15 optimale sur l ensemble du territoire national, la mise en place d une infrastructure de téléphonie constituée à l échelle nationale facilitait l adaptation du dispositif nominal aux situations de gestion de crise. Chaque centre de régulation opérait cependant un environnement d échange de dossiers de régulation commun complétant l environnement par des procédures de bascule et de repli nécessaires à la gestion des situations de crise. Ce scénario a été écarté, car engendrant une complexité de mise en œuvre importante pour des coûts difficilement maitrisables, mais assurément très élevés en raison d un déploiement à deux niveaux (local et national). Scénario cible : mise en place d une solution mutualisée Description Ce scénario consiste à mettre en place une solution unique et mutualisée, où applications et téléphonie sont intégrées et disponibles en mode service sur l ensemble du territoire. Sa logique de centralisation et de mutualisation par l ensemble des SAMU Centre 15 lui confère une capacité à offrir un service de haute qualité et parfaitement homogène sur l ensemble du territoire Classification : Public 5 / 119

6 ASIP Santé Mars 2012 national dépassant les clivages interrégionaux. L interconnexion entre l ensemble des SAMU Centre 15 est native, apportant de vraies capacités de régulation et de pilotage, agiles à l échelle de la nation. La capacité de cette solution pour faire face à une crise nationale est optimale (déploiement rapide et forte évolutivité comme des outils d aide à la décision, etc.). Ses interactions avec les services logiciels nationaux de santé (ROR, DMP et d autres à venir) sont facilitées ainsi que les échanges avec l ensemble des partenaires (SDIS, ambulanciers privés, services des urgences, etc.). Le critère économique est favorable, surtout dans les coûts récurrents même si les coûts d investissement pourraient être plus concentrés dans le temps selon le modèle économique retenu. Enfin, il offre la meilleure garantie en matière de disponibilité et de sécurité dans un cadre particulièrement sensible sous réserve de s inscrire dans une gouvernance efficiente. Ce scénario incarne un changement majeur dans la stratégie de mise en œuvre du système d information sous responsabilité d établissements de santé. Il est porteur de bénéfices très importants, mais se trouve par contre exigeant en matière de volonté politique, et tributaire d une nécessaire centralisation des budgets d investissements. Il est également plus exigeant en termes de maîtrise d ouvrage pour sécuriser sa bonne fin (risque inhérent à tout projet informatique de taille critique dans un environnement public à maîtrise d ouvrage faible). Il doit enfin dépasser les possibles réticences de certains responsables métiers des SAMU tentés d y voir une perte dans leur autonomie de fonctionnement en leur garantissant une qualité de mise en œuvre irréprochable correspondant à la criticité et la sensibilité de la régulation médicale des appels en situation d urgence. Feuille de route Les 3 principes suivants structurent fortement la trajectoire présentée : Le mode service hébergé (SaaS) dans une perspective cible La mise à disposition de fonctionnalités de gestion des appels et des dossiers de régulation est la seule solution garantissant une disponibilité homogène à un niveau de qualité maitrisé sur l ensemble du territoire. Ce mode de fonctionnement nécessite la construction d une solution totalement nouvelle, associant au savoir-faire et aux outils des centres d appels un logiciel de régulation à développer capitalisant l expertise acquise dans une architecture compatible avec le mode SaaS. En effet l offre actuelle en matière de logiciel de régulation est techniquement endettée et ne peut être migrée techniquement dans ce nouvel environnement. Sur le domaine de l aide médicale d urgence, cette cible de système d information s inscrit sur la trajectoire du dispositif anglais (NHS Direct, avec un SI mutualisé et des opérateurs multiples pour la prise en compte des appels au 111). Des sites pilotes en prologue au programme de modernisation Afin de sécuriser le lancement des travaux de construction d une solution complète (téléphonie/gestion des dossiers de régulation/interconnexion avec les partenaires), des sites pilotes expérimenteront une solution conforme à la cible et développée dans le cadre d une nouvelle gouvernance nationale. Le retour d expériences alimentera les spécifications du mode service soumises à concertation auprès de l ensemble des acteurs (responsables métiers et techniques, partenaires SDIS ambulanciers ). Cette étape de projet sera mise à profit pour l élaboration du cadre juridique nécessaire à la sélection d un consortium industriel titulaire du marché de fourniture du service cible sur une durée nécessairement supérieure à celle des marchés publics standards. Classification : Public 6 / 119

7 ASIP Santé Mars 2012 Une montée en charge progressive Le mode SaaS permet de lisser dans le temps les évolutions du service fourni sans nécessiter de couteuses opérations de migration logicielle et matérielle habituellement constatées sur des infrastructures opérées localement par les ressources techniques internes de l organisation bénéficiaire. Cela permet de démarrer le déploiement par les SAMU actuellement sans solution adaptée, puis de les faire évoluer au rythme de l extension du périmètre fonctionnel de la nouvelle solution de régulation. Les SAMU bénéficiant actuellement d une solution satisfaisante intègrent le dispositif cible au moment où la nouvelle solution est à un niveau d exigences équivalent à leur existant. Nous sommes donc dans un déploiement progressif et pragmatique s opposant à une démarche de type «big bang» peu adaptée aux caractéristiques d activités des SAMU. La feuille de route pourrait être structurée avec une phase de pilote de la manière suivante : Phase d initialisation du programme d une durée de 6 mois. Conduite par une équipe restreinte, elle consiste à élaborer les grands principes nécessaires au lancement du programme de modernisation SI et Télécom des SAMU tant sur l étape prototype que celle SaaS. Elle définit le rôle et la composition des missions de la maitrise d ouvrage stratégique (MOA-S), de la maitrise d ouvrage système d information et de télécom (MOA-SIT) et de la maitrise d ouvrage métier (MOA-M) Phase de réalisation Cette phase est elle-même découpée en deux étapes : Etape Pilote : expérimentation du dispositif cible sur des sites en fonctionnement (couplage fort téléphonie - régulation, virtualisation, ) et production de spécifications fonctionnelles détaillées de qualité et éprouvées par le réel Classification : Public 7 / 119

8 ASIP Santé Mars 2012 Etape SaaS : mise à disposition par un consortium d acteurs du marché d un service parfaitement adapté aux besoins des SAMU Centre 15 selon un plan de montée en puissance progressif et continu tant sur l aspect fonctionnel que sur le déploiement des SAMU. Cadencement du déploiement Le premier site opérationnel arrive après 2 ans dans une configuration pilote. Le déploiement en production du premier SAMU dans le mode service arrive à la fin de la 4 ème année 2,5 ans après l arrivée du premier SAMU sur le nouveau système, 50 SAMU ont migré sur le nouveau système (phase de déploiement soutenue) 4,5 ans après l arrivée du premier SAMU sur le nouveau système, 80 à 90 SAMU ont migré Au bout de 6 ans de déploiement, l ensemble des SAMU est déployé Evaluation budgétaire Du fait de la dispersion actuelle des moyens, il n existe pas aujourd hui de coûts consolidés à l échelle nationale agrégeant les postes d investissements et de fonctionnement en matière de système d information et de télécommunication. L étude entreprise s est basée sur un modèle extrapolant de manière pondérée à l ensemble des SAMU les données d un site de référence bénéficiant aujourd hui d un équipement satisfaisant. L étude comparative des scénarios s est construite autour de la valeur de «cash out 2» estimée pour chacun d eux sur une période de 10 ans : en début de période : couts d investissement et couts de fonctionnement de l existant dans l attente du déploiement du nouveau système en fin de période : cout de fonctionnement du nouveau système Pour le scénario cible, les résultats de cette simulation sur 10 ans sont : Un cout d investissement de 27,8 M (CAPEX) Un cout de maintenance final global annuel pour la 10 ème année de 10,8 M (OPEX) Soit un «cash-out» sur 10 ans de 175 M se décomposant de la manière suivante : o 27,8 M d investissement (CAPEX) pour le nouveau système o o 34 M d exploitation (OPEX) sur le nouveau système 113,2 M de maintien en condition d exploitation des anciennes solutions dans l attente du déploiement de la nouvelle (OPEX + CAPEX). 2 Le «cash out» représente le budget réel global qu il sera nécessaire de dépenser pour mettre en place le scénario sur une période donnée sommant coûts d investissement et coûts de fonctionnement Classification : Public 8 / 119

9 ASIP Santé Mars 2012 SOMMAIRE SYNTHÈSE STRATÉGIQUE... 3 Diagnostic... 3 Axes stratégiques... 4 Scénarios étudiés... 5 Scénario cible : mise en place d une solution mutualisée... 5 Description... 5 Feuille de route... 6 Evaluation budgétaire... 8 SOMMAIRE LES SAMU AUJOURD HUI L activité de régulation médicale La mission des SAMU et les grands processus de la régulation médicale Les acteurs de l écosystème des SAMU Etats des lieux des SAMU Une grande disparité de la qualité des équipements SI et télécom entre les SAMU limitant la délivrance d un service fonctionnel uniforme et satisfaisant Un niveau de disponibilité encore trop faible pour un «centre d appel» Une utilisation limitée des logiciels de gestion d appel de type «centre d appel» Une utilisation étendue des communications GSM Une politique d utilisation des radiocommunications non définie (rôle d ANTARES) Un cloisonnement des SAMU entre eux Une gestion actuelle des appels en débordement n apportant pas satisfaction Encore très peu d intégration avec le système de santé Une expérience SIN SAMU Grippe ayant fait émerger la volonté et la capacité d harmonisation des SAMU Des données budgétaires des SAMU Centre 15 très difficilement disponibles Un marché des logiciels de gestion des appels de régulation peu viable en l état Des innovations de rupture majeures Innovations fonctionnelles Innovations techniques de rupture LES NOUVEAUX ENJEUX DES SAMU Analyse des besoins cibles et des voies de progrès Les axes de progrès Analyse des besoins fonctionnels cibles Interactions hospitalières / pré-hospitalières Focus sur la reprise d activité Focus sur le pilotage national Description fonctionnelle cible des SAMU COMPARAISON DES SCENARIOS Présentation des scénarios considérés Classification : Public 9 / 119

10 ASIP Santé Mars Scénario 1 - des spécifications communes pour inter opérer Scénario 2 - Une solution commune opérée localement Scénario 3 - Une solution opérée localement et complétée par un dispositif régional d échange et de sauvegarde Scénario 4 - Une solution unique, commune et partagée Dynamique d évolution des scénarios Méthode d analyse Analyse par axe stratégique Analyse multi-critères objective Analyse comparative Comparaison des scénarios Comparaison multi critères Synthèse par scénario Conclusions de l'analyse comparative et suite de l étude APPROFONDISSEMENT DU SCENARIO Les fondamentaux de la solution Une application en rupture avec l existant Description haut niveau de la cible Les grands Principes de la solution Les exigences de sécurité Principes de construction de la solution (DESIGN & BUILD) Une solution mutualisée Gestion de crises Lien avec l opérateur et intégration de la téléphonie Interactions avec les partenaires et les logiciels de santé Le réseau ANTARES Le réseau de télécommunication Implémentation locale dans les SAMU centres Gestion des moyens SMUR Grandes fonctions transverses Principe de déploiement (ROLLOUT) Les enjeux d un déploiement géographique Les enjeux d un déploiement fonctionnel Principe de fonctionnement (RUN) Qualité de service et management de la qualité Outils d administration Sécurité et confidentialité Support aux utilisateurs Maintenance corrective Stratégie industrielle proposée Eléments introductifs Stratégie industrielle choisie Evaluation du modèle économique du programme Feuille de route de la solution Eléments structurants des feuilles de route Variante de la feuille de route avec prototype Variante de la feuille de route avec pilote Classification : Public 10 / 119

11 ASIP Santé Mars Maîtrise des risques / conditions de succès ANNEXES Equipe projet ayant conduit l étude Démarche suivie & Planning de l étude Démarche suivie Planning de l étude Classification : Public 11 / 119

12 ASIP Santé Mars LES SAMU AUJOURD HUI 1.1 L activité de régulation médicale La mission des SAMU et les grands processus de la régulation médicale Né de différentes initiatives dans les années 60 et 70, c est la loi du 6 janvier 1986 qui structure l organisation des SAMU en en étendant le principe à tous les départements français et en proposant un numéro d appel unique, le 15. Le SAMU est chargé de fournir une réponse adaptée aux problèmes médicaux urgents qui lui sont soumis par une ligne téléphonique d urgence exclusivement médicale (le 15 en France) ou à travers les autres lignes d urgence : numéro général européen 112, 17 de la police, 18 des sapeurs-pompiers ; ou à travers le réseau de télécommunications de la santé. La fonction, à la fois médicale et sanitaire, de traitement de ces appels, est appelée régulation médico-sanitaire des urgences. Elle s étend à une région sanitaire plus ou moins grande dans le cadre d un véritable système intégré des urgences médicales (SIUM) où tous les services de soins urgents de la médecine générale et de transport sanitaire sont impliqués et mutualisent leurs ressources que le SAMU est chargé de monitoriser. La régulation médicale peut aller de la simple aide médicale urgente téléphonique à l engagement de moyens mobiles lourds d unité de soins intensifs mobiles en passant par l envoi d une ambulance simple ou de sauvetage, ou la consultation d un médecin généraliste, sans oublier la possibilité de recours à d autres moyens tels ceux des Sapeurs-pompiers. Le SAMU est devenu un acteur fondamental aussi dans les situations de crise sanitaire aiguë et des urgences médicales collectives. Le réseau national des SAMU ainsi que le réseau national hospitalier constituent aujourd hui le pilier d une véritable protection civile sanitaire. Dans le cadre de la mission effectuée, une modélisation en grand macro processus de l activité des SAMU a été effectuée afin d en comprendre le fonctionnement et de pouvoir donner une cartographie fonctionnelle cible du système d information des SAMU (voir chapitre 2.2). Il est intéressant de présenter ici le schéma synthétique de ces macro processus, au nombre de cinq, qui permet de bien comprendre les grandes typologies de l activité d un SAMU : Apporter le juste soin : c est le processus de base au cœur du métier. Il consiste en premier lieu à réceptionner et qualifier un appel, puis, en général de passer au processus de décision médicale, lui-même s enchaînant éventuellement sur des engagements de moyens qu il convient de suivre jusqu à l orientation et la prise en charge du patient ; Suivi des régulations médicales : consiste à suivre et à compléter le dossier de régulation médical et à obtenir les informations nécessaires des acteurs ayant participé à la prise en charge ; Gestion de crise : ce sont des processus exceptionnels, permettant une mobilisation spécifique et mettant en œuvre des acteurs autres tels que des SAMU d autres départements ou encore le ministère de la Santé ; Pilotage SAMU : cette activité est importante, car elle permet une meilleure compréhension du fonctionnement et de mettre en place un processus d amélioration continue ; Les processus dits «support» : il s agit typiquement des ressources humaines, de la gestioncompatibilité, de l informatique... Classification : Public 12 / 119

13 ASIP Santé Mars Les acteurs de l écosystème des SAMU Les SAMU centres 15 interagissent avec un nombre important d acteurs pour d une part recevoir l ensemble des demandes d aides qui arrivent par différents canaux et pour d autre part engager et suivre les moyens adaptés à chaque situation. Le tableau ci-dessous liste l ensemble de ces acteurs : Classification : Public 13 / 119

14 ASIP Santé Mars 2012 Au vu de tous les acteurs concernés dont la mobilisation peut être exercée dans un cadre d urgence, on comprend mieux la valeur ajoutée du système d information dans l exercice du processus de régulation, qui doit permettre de gagner du temps et de prendre a priori les décisions les mieux adaptées. 1.2 Etats des lieux des SAMU Le rapport Mardegan de juillet 2010 relatif «à la modernisation des SAMU» fait apparaître la persistance de fragilités opérationnelles et technologiques, ainsi qu une grande hétérogénéité des équipements, des ressources et des niveaux d activité. Sur la base des éléments du rapport Mardegan et des entretiens menés avec les représentants du comité de pilotage dédié à cette mission, il se dégage 12 constats principaux sur le fonctionnement actuel des SAMU, dont la synthèse est donnée ici. Classification : Public 14 / 119

15 ASIP Santé Mars 2012 CONSTATS IT & TELECOM 1. Une grande disparité de la qualité des équipements SI et Télécom selon les SAMU concernés limitant la délivrance d un service fonctionnel uniforme et satisfaisant ; 2. Un niveau de disponibilité encore trop faible pour un «Centre d appels» ; 3. Une utilisation limitée de logiciel de gestion d appels de type «Centre d appels» ; 4. Une utilisation étendue des communications GSM ; 5. Une politique d utilisation des radiocommunications non toujours définie (rôle d ANTARES) ; CONSTATS METIERS 6. Un cloisonnement des SAMU entre eux ; 7. Une gestion actuelle des appels en débordement n apportant pas satisfaction ; 8. Encore très peu d intégration avec le système de santé ; 9. Une expérience SIN SAMU Grippe ayant fait émerger la volonté et la capacité d harmonisation des SAMU ; 10. Une insatisfaction globale des acteurs métiers vis-à-vis des services SI et Télécom en place ; CONSTATS ÉCONOMIQUES 11. Des données budgétaires des SAMU Centre 15 très difficilement disponibles ; 12. Un marché des logiciels de gestion des appels de régulation non viable en l état. Classification : Public 15 / 119

16 ASIP Santé Mars Une grande disparité de la qualité des équipements SI et télécom entre les SAMU limitant la délivrance d un service fonctionnel uniforme et satisfaisant Les SAMU, dépendant exclusivement des hôpitaux auxquels ils sont rattachés, voient les budgets qui leur sont attribués varier en fonction des possibilités spécifiques et des priorités de chaque hôpital. Les cycles budgétaires de chaque SAMU sont indépendants les uns des autres et les périodes d investissement massif (notamment pour moderniser les infrastructures) sont ainsi très ponctuelles et désynchronisées. Par voie de conséquence, les équipements et services actuellement en place sont donc souvent très inégaux. Ces deux facteurs ont pour conséquence de créer des écarts qui peuvent s avérer très importants entre les équipements SI et Télécom des différents SAMU Centres 15. Or, le caractère prioritaire et urgent des Centres de Réception et de Régulation des Appels (CRRA) implique un niveau élevé de fonctionnalité et de disponibilité des infrastructures SI et Télécom afin d améliorer l efficacité et de limiter les risques de dysfonctionnements. En conclusion, un certain nombre de SAMU Centres 15 présentent souvent des infrastructures vieillissantes ne pouvant offrir une qualité de service à la hauteur de leur mission Un niveau de disponibilité encore trop faible pour un «centre d appel» Plusieurs éléments illustrent ce faible niveau de disponibilité : Plusieurs SAMU ne possèdent pas d autocommutateur de secours ; Plusieurs SAMU ne possèdent pas de contrat de maintenance sur les logiciels de régulation. Ainsi en cas de panne, la situation peut rapidement devenir critique. Par ailleurs, le marché des éditeurs de progiciels de régulation médicale étant de petite taille, il ne permet pas d offrir, en général, un support d une réactivité suffisante pour la gestion des urgences en cas de besoin Une utilisation limitée des logiciels de gestion d appel de type «centre d appel» L objectif premier d un Centre 15 consiste à gérer les flux téléphoniques : dans ce cadre, les fonctionnalités de type «salles d attente» et plus généralement de téléphonie avancées permettent une véritable amélioration de la qualité de service offerte. Ces fonctionnalités sont offertes par des logiciels spécifiques qui ne sont pas installés ou exceptionnellement installés dans les SAMU Centres 15. Au-delà de la mise en place de ces outils, il est nécessaire d aider le personnel des SAMU (très souvent autodidacte) et d instaurer «une culture» de la téléphonie avancée qui passe par un accompagnement au changement Une utilisation étendue des communications GSM Actuellement, afin de communiquer, les SAMU utilisent principalement la téléphonie mobile (GSM). Chaque Centre 15 conserve néanmoins souvent des équipements de radiocommunication pour gérer les situations de crise où le réseau mobile serait défaillant Une politique d utilisation des radiocommunications non définie (rôle d ANTARES) Le système ANTARES est un réseau de télécommunication chiffré, sécurisé et opéré par le ministère de l Intérieur. L ensemble des unités de pompiers est en cours de migration sur ce système de radiocommunication. Il permet notamment le transport de la voix, de data (statut, bilan simplifié...). Afin Classification : Public 16 / 119

17 ASIP Santé Mars 2012 de pouvoir continuer à échanger avec les pompiers, les SAMU n ont d autres choix que d utiliser le système de radiocommunication ANTARES ; Quelques SAMU ont déjà migré sur ANTARES Un cloisonnement des SAMU entre eux La mission des SAMU est aujourd hui principalement une mission départementale. Cet aspect des interventions constitue une des forces du SAMU par sa connaissance parfaite de l environnement local et sa capacité d intervention dans ce cadre. Cependant, lorsque cela est nécessaire, les SAMU peuvent être amenés à intervenir sur d autres départements. Des initiatives sont menées au niveau de certaines régions (PACA, Champagne-Ardenne, Pays de Loire) pour faciliter et optimiser en termes d efficacité l intervention des SAMU entre les différents départements qui constituent la région. Par voie de conséquence, on constate un cloisonnement croissant entre les régions notamment en raison de la logique des ARS qui encourage les initiatives et une articulation entre les SAMU d une même région : ce cloisonnement peut dans certains cas conduire à des situations peu optimisées pour les patients (transport d un patient vers l hôpital de sa région bien plus éloigné géographiquement que celui de la région voisine) Une gestion actuelle des appels en débordement n apportant pas satisfaction Certains SAMU ont été équipés de poste Etrali permettant la prise en charge des appels en débordement d autres SAMU. Cependant, la couverture géographique de ce système n est pas totale et cette solution n est pas considérée par les SAMU à l usage comme une solution satisfaisante, ne serait-ce que parce qu elle concerne que la téléphonie et non l informatique. On constate l absence d une politique de débordement des appels qui permettrait de gérer l insécurité ou la surcharge téléphonique Encore très peu d intégration avec le système de santé Un manque d échange de données avec les systèmes de santé en interaction avec les CRRA : Au cours de la prise en charge d un patient par le SAMU, de nombreuses informations sont collectées par le Centre 15, sur le patient, sa pathologie, le diagnostic établi par la régulation, etc... Le plus souvent, ces informations ne sont actuellement pas correctement échangées entre les services de santé : Ce manque d échange automatisé de données a de nombreuses conséquences : Saisie d informations en double, source de manque d efficacité voire d erreurs ; «Oublis» d éléments déterminants sur l état de santé du patient (contexte de l accident, soins déjà prodigués, etc.) ; Les SAMU disposent aujourd hui de peu d interaction avec le système de santé Dans les régions où il existe un ROR, le SAMU Centre 15 du département n y est pas toujours interfacé ; Depuis la mise en place opérationnelle du DMP fin 2010, aucun SAMU Centre 15 n a développé une interface ; Il n existe actuellement pas de messagerie sécurisée et normalisée permettant (manuellement ou au travers d un logiciel de régulation médicale) de communiquer les données médicales entre professionnels de santé. Classification : Public 17 / 119

18 ASIP Santé Mars Une expérience SIN SAMU Grippe ayant fait émerger la volonté et la capacité d harmonisation des SAMU Dans le cadre de la pandémie grippale de 2009, le système SIN SAMU-Grippe a été mis en place au niveau national. Cette initiative a été considérée par les professionnels des urgences comme un dispositif adapté à ce type de situation (en termes de déploiement, de fonctionnalités et d efficacité). Elle a permis de créer une culture nationale pour préparer une solution nationale). En termes d architecture logicielle, la solution SIN SAMU-Grippe était une solution mutualisée au niveau national et accessible via un client web banalisé Des données budgétaires des SAMU Centre 15 très difficilement disponibles Le rapport Mardegan ainsi que les différentes collectes menées dans le cadre de la présente étude ne permettent pas de disposer d une vision claire sur les budgets SI et Télécom des Centres 15. Chaque SAMU bénéficie de fonds locaux de manière discontinue et aléatoire, et ainsi difficilement traçables et identifiables Un marché des logiciels de gestion des appels de régulation peu viable en l état Le marché actuel est constitué de quelques acteurs qui se partagent le marché : Appligos (AppliSAMU), SIS (Centaure 15), GCS (Ramu), Scriptal (SAMUscript) ou même des développements personnels. Dans ce paysage, on retrouve également des acteurs pas nécessairement liés à la santé comme IMP, Systel ou Artémis (en lien avec le SI des pompiers) : le marché des logiciels de gestion de régulation médicale est trop étroit, fragmenté et peu solvable pour permettre la constitution d acteurs économiques pérennes, performants et innovants soutenant une offre logicielle de qualité. 1.3 Des innovations de rupture majeures Innovations fonctionnelles La mise en œuvre de nouveaux services logiciels permet de concevoir le système cible du SI des SAMU dans une urbanisation cohérente et en ligne avec les niveaux de subsidiarité de ces nouveaux services: Le répertoire opérationnel des ressources (ROR) Le répertoire opérationnel des ressources a été défini dans la circulaire relative à la mise en œuvre des réseaux d urgence de Ce service indispensable à l activité de régulation décrit les offres de soins mobilisables par le SAMU dans l élaboration d une réponse graduée et adaptée aux appels d urgence en tenant compte de leur disponibilité et de leur accessibilité géographique. Un ROR interopérable au niveau national est essentiel à la cible pour permettre aux SAMU de réaliser leur activité de régulation en mode nominale et en situation de crise sur un périmètre non seulement régional, mais aussi inter régional Le Dossier Médical Personnel (DMP) Le Dossier Médical Personnel donne la possibilité aux SAMU d accéder aux informations utiles à la coordination des soins dans le cadre de leur activité de régulation. Un mode d accès spécifique, conforme réglementairement et fonctionnellement à leurs contraintes, leur permet de se baser sur ce Classification : Public 18 / 119

19 ASIP Santé Mars 2012 service pour organiser la gestion des «patients remarquables» pour lesquelles une synthèse du dossier de régulation viendra compléter le cas échant le DMP La messagerie de santé sécurisée L utilisation de la messagerie sécurisée, service en cours de développement, doit permettre aux SAMU de communiquer avec l ensemble des acteurs de santé. Elle répondra en particulier aux besoins de communiquer des informations médicales à caractère personnel entre les acteurs de la régulation, des SMUR et des SAU Innovations techniques de rupture L accélération du rythme d innovation dans les technologies de l information a permis l apparition d un nombre important d innovations de rupture qui peuvent jouer un rôle clé dans la modernisation SI & Télécom des SAMU Centre 15 : La téléphonie sur IP (ToIP) rendue possible par la convergence numérique et la banalisation des réseaux haut débit ; La montée en puissance des terminaux mobiles intelligents (smartphones, tablettes...) permettant le déploiement rapide d applications et transformant les usages de manière considérable dans de nombreux secteurs d activité ; Le «Cloud Computing» offre de nouvelles perspectives sur la mise à disposition des ressources informatiques (serveurs, applications, etc.) en passant d un modèle d acquisition à un modèle de service avec un paiement à l utilisation. Ces innovations sont présentées de manière générique dans les pages suivantes. Leur déclinaison dans le cadre de la modernisation des SAMU Centre 15 est détaillée dans le cadre d une mise en pratique illustrative La téléphonie sur ip La Téléphonie sur IP (ToIP) est une technique qui permet d utiliser un réseau IP pour acheminer des communications téléphoniques. La voix est numérisée puis transportée sous forme de paquets comme n importe quelles autres données (mails, vidéo, images, etc.). Dans le cas de la téléphonie traditionnelle, les signaux de service et la voix sont acheminés par les lignes raccordées à un auto commutateur : la communication, une fois établie grâce au traitement des signaux de signalisation, transite aussi à travers l auto commutateur. Dans le cadre de la téléphonie sur IP, les signaux de service sont traités par un serveur dont le logiciel gère la mise en relation d un poste à un autre, puis la communication se déroule en point à point entre les deux, ou n, terminaux concernés. Classification : Public 19 / 119

20 ASIP Santé Mars 2012 La téléphonie sur IP apporte un certain nombre d avantages fonctionnels et financiers : Apporter des fonctions avancées grâce au couplage voix - données : la téléphonie sur IP permet la convergence des applications voix et données en s appuyant sur le couplage intime de la téléphonie et de l informatique. Il devient alors possible de concevoir des solutions complètement intégrées pour proposer des services à valeur ajoutée (tels que la gestion graphique des appels, la reconnaissance vocale, des enregistrements vocaux numériques, etc.). Pérenniser l investissement : le marché de la téléphonie d entreprise PABx-IP a déjà dépassé celui des auto commutateurs traditionnels. Il est donc stratégique d investir dans la technologie ToIP pour bénéficier par la suite de ces évolutions (nouveaux services). Cet avantage est d autant plus fort que les équipements pour la téléphonie traditionnelle (auto commutateur) sont en général plus onéreux que ceux pour la ToIP, surtout dans le cadre de solutions mutualisées Faciliter la mobilité : avec des postes n étant plus physiquement reliés à des lignes dédiées à la téléphonie, la téléphonie sur IP rend possible le déménagement ou le renforcement d un centre 15 sans avoir à redéployer des lignes téléphoniques classiques, un simple accès à un réseau IP VPN suffit. Economiser sur l abonnement télécom : la banalisation des accès Internet et l évolution constante de la bande passante font de la solution ToIP une solution bon marché au regard du montant des abonnements télécom traditionnels. En effet, d importantes économies peuvent être réalisées sur les frais récurrents en plus des investissements initiaux. En fait, la grande puissance de la ToIP vient du fait qu il est possible de gérer la téléphonie entièrement par un logiciel résidant sur un serveur informatique banalisé : partant de ce principe, le couplage entre ce logiciel dédié à la téléphonie et le ou les logiciels applicatifs métiers liés à la régulation devient très facile et permet d implanter des fonctionnalités de haut niveau. Une des limites de la ToIP réside dans la capacité à l interfacer avec des réseaux téléphoniques conventionnels : il faut alors des dispositifs de type «passerelle» hardware et software particuliers, en général propriétaires et assez coûteux financièrement. Classification : Public 20 / 119

21 ASIP Santé Mars 2012 Mise en pratique : exemple d une architecture ToiP pour les SAMU Ce schéma illustre ce que pourrait être une architecture ToIP mutualisée dans le cadre des SAMU Cloud Computing et architecture en mode service (SaaS) Description «Le Cloud Computing consiste en une interconnexion et une coopération de ressources informatiques, situées au sein d une même entité ou dans diverses structures internes, externes ou mixtes. Et dont les modes d accès sont basés sur les protocoles et standards de l Internet. Les solutions Cloud reposent sur des technologies de virtualisation et d automatisation.» (définition donnée par le Syntec Informatique Principe Le Cloud Computing est donc un nouveau mode de mise à disposition de ressources informatiques reposant sur 5 principes : Offre de service (xaas) Ajustable dynamiquement (élasticité) Exploitant des ressources mutualisées Basée sur les technologies d internet Facturée sur la consommation effective Classification : Public 21 / 119

22 ASIP Santé Mars 2012 Périmètres de responsabilité en fonction des solutions «as a service» Le Cloud Computing propose différents degrés de mise à disposition de ressources informatiques illustrés dans le schéma suivant : Avantages fonctionnels et financiers des solutions du Cloud Computing Améliorer la qualité de service : le fournisseur de solutions de Cloud Computing est tenu par des engagements contractuels forts de qualité, de disponibilité, de sécurité, d évolutivité du service dans le temps. La maintenance (corrective et évolutive) des solutions est directement assurée par le fournisseur et en général de manière transparente pour l utilisateur. De plus, l élasticité fournie par les solutions Cloud permet de faire face à des surcharges ponctuelles d activités. Maîtriser ses coûts : ce modèle locatif de mise à disposition de ressources informatiques permet de s affranchir des coûts d investissement et de maintenance. Les ressources informatiques deviennent une charge de fonctionnement (OPEX), dont il est plus aisé de planifier/anticiper ses Classification : Public 22 / 119

23 ASIP Santé Mars 2012 dépenses. Les services étant souvent facturés «au siège» et/ou à l usage, la compréhension des coûts s en trouve très facilitée. Réduire les temps de mise en œuvre : il n y a pas besoin d acquérir des serveurs, de les configurer, d y installer un environnement et les applications, de gérer leur intégration. Ces processus sont gérés par le fournisseur des services du Cloud Computing. La mise en production se limite généralement à la souscription d un abonnement. Concentrer sur le cœur de métier et s affranchir des compétences informatiques : L affranchissement de la gestion des ressources informatiques par l utilisateur lui permet de rester concentré sur son métier, de bénéficier d effets de volume (industrialisation, mutualisation), d avoir à sa disposition l expertise et la qualité de service de spécialistes informatiques. Mise en pratique : exemple d une architecture «Cloud Computing» pour les SAMU Dans cette illustration très schématique, le Cloud privé héberge toutes les ressources virtuelles et en garantit la sécurité (redondance des infrastructures, sauvegarde, etc.). Cette configuration permettrait d installer un nouveau SAMU ou une salle de crise temporaire qui serait opérationnel en très peu de temps Terminaux mobiles Description Derrière ce terme de «terminaux mobiles», deux notions sont à prendre en considération: La banalisation des terminaux mobiles dits «intelligents» (smartphones, tablettes tactiles, PDA, ultra portable, etc.) permettant l apparition de nouveaux usages au moyen d applications («apps») ; Classification : Public 23 / 119

24 ASIP Santé Mars 2012 Principes L émergence de réseaux de télécommunications toujours plus performants ( Réseau 4G - LTE «Long Term Evolution», etc.) et éprouvés par un usage grand public. En effet, les opérateurs travaillent à mettre au point des réseaux hertziens permettant des débits fortement augmentés et une couverture étendue. Au niveau des mobiles, le réseau LTE constitue une véritable prouesse technologique en proposant un débit maximum du Gbit/s à la cible (LTE Advanced). Il est prévu pour couvrir 80% des utilisateurs de mobiles en fin La première version disponible dès 2012 sur les réseaux opérateurs proposera les fonctionnalités suivantes : débit descendant de 326,4 Mbit/s (3G : 384kb/s) débit de chargement de 86,4 Mbit/s (3G : 128kb/s) Il est aussi excellent pour le support des mobiles en mouvement (c est-à-dire de hautes performances jusqu à 350 km/h). Au-delà de ces caractéristiques techniques, le réseau LTE permettra notamment de gérer des classes de service et d administrer finement les utilisateurs. Au niveau des terminaux, 7 millions de Français possédaient un smartphone en 2010, et cela représentait environ 1 4 des téléphones vendus. Aujourd hui les terminaux (mobiles, tablettes) sont majoritairement équipés d un écran couleur de bonne qualité, d un capteur d image (photo/ vidéo) souvent haute définition, d un micro, d une puce GPS et d un accès WiFi, de capteurs de position (boussole), d un processeur équivalent à la puissance d un PC d il y a 3 ans, d une mémoire de plusieurs dizaines de Gigaoctets... Toutes ces fonctionnalités ouvrent le champ à de nouveaux usages comme la vidéo-conférence à plusieurs, la géo localisation en direct de l appelant, l envoi de photos ou d enregistrements vidéo de manière instantanée, etc. Avantages des terminaux mobiles Favoriser les interactions : l essor des terminaux mobiles permet l échange de données (photos, vidéos, positions, etc.) directement avec les utilisateurs qu ils soient patients ou bien partenaires. Les terminaux mobiles constituent un nouveau canal de communication riche qu il convient d intégrer aux côtés des autres plus traditionnels (RTC, Radio, etc.) Développer de nouveaux services (opportunités applicatives) : au-delà des interactions, la puissance des terminaux mobiles permet aujourd hui de proposer des applications offrant des services en tout genre (Ex. : Application iphone de la Croix Rouge pour dispenser les gestes de premiers secours ou l application «En cas d urgence» qui propose tous les numéros téléphoniques de secours et les informations associées (n sécu, groupe sanguin, etc.) de manière rapide et centralisée). Ces applications peuvent aussi embarquer une partie du SI afin de continuer à fonctionner même en cas de défaillance de la connexion. Classification : Public 24 / 119

25 ASIP Santé Mars LES NOUVEAUX ENJEUX DES SAMU 2.1 Analyse des besoins cibles et des voies de progrès Les axes de progrès Sur la base des constats énoncés dans le chapitre précédent, un certain nombre d axes de progrès ont été identifiés dans le cadre de la modernisation SI et Télécom des SAMU : Donner à tous les SAMU quels que soient leurs moyens, la mise à disposition d un service identique sans disparité au regard de leur capacité organisationnelle et financière et de leur capacité d évolution ; Fournir les meilleures solutions technologiques avec des niveaux de disponibilité élevés tout en restant dans un cadre économiquement contraint et en fournissant un niveau de service adapté aux contraintes des SAMU (offrir des outils «clés en main») ; Concentrer l activité des SAMU sur leur cœur de métier en acceptant une moindre autonomie sur la gestion du SI et des télécoms au niveau local ; Réduire le cloisonnement régional en offrant des possibilités d échanges et d actions au plan national ; Offrir une meilleure interopérabilité : Permettre la réception et la transmission de données et d appels vers/depuis les autres acteurs de la santé (HAD, Hôpitaux, Télémédecine, Pompiers, SOS Médecins, etc.) ; Avec les autres SAMU, définir des normes et des référentiels communs entre les SAMU ; Travailler à la mise en place d un outil reprenant les meilleures fonctionnalités de chacun des outils du marché (SAMU et extérieur) ; Mieux maitriser les cycles d investissement et d exploitation ; Etablir une politique de pilotage global de l activité des SAMU : o en mode nominal : coordination inter SAMU ; o en période de crise : pour garantir la gestion des cas d urgence (cela englobe la gestion du débordement) ; Assurer l intégration entre le SI des SAMU Centre 15 et les services logiciels de santé (notamment les échanges avec le ROR, le DMP et messagerie sécurisée) ; Etablir une stratégie industrielle permettant de créer une (ou plusieurs) offre(s) logicielle(s) de qualité, réactives et avec un niveau de service adapté (SLA) ; Développer une cohérence globale des SAMU en apportant une démarche collaborative (comme déjà réalisée à l échelle nationale avec Sin SAMU-Grippe). De ces axes de progrès, il a été dégagé huit critères mesurables permettant de comparer les différents scénarios sur la base d une analyse multi-critère (chapitre 3.2). Classification : Public 25 / 119

26 ASIP Santé Mars Analyse des besoins fonctionnels cibles Le tableau qui suit liste les principaux besoins fonctionnels cibles pour les SAMU Centres 15. Nouveaux besoins Une utilisation croissante des DATA (données multimédia) Terminaux mobiles SMUR Intégration avec les logiciels de Santé nationale Informatiser les échanges avec les partenaires du SAMU Alertes automatiques Serveur vocal Interactif (SVI) dynamique Cartographie, SIG et géolocalisation Description Intégrer la communication multi canal, avec le patient et les effecteurs dans les deux sens (vers et depuis) afin d améliorer la qualité des régulations médicales : voix Mail, fax, SMS Messagerie sécurisée Radio Antarès (voix, data : messages courts, statuts, géolocalisation) Recours à l utilisation de la vidéo (imagerie embarquée) Gestion aisée des pièces jointes (ECG, imagerie embarquée,...). L enjeu est d améliorer la prise en charge au travers la mise à disposition des SMUR de terminaux mobiles permettant un meilleur échange d information avec les autres acteurs de la chaine de régulation. Néanmoins, ce besoin doit être envisagé en parallèle avec une capacité accrue au niveau du régulateur pour traiter ces données. La région de PACA est actuellement en train de faire des expérimentations via l informatisation des SMUR avec des PDA. L intégration étroite avec le DMP et le ROR permettra d améliorer significativement la qualité de la régulation médicale. L échange de données informatisé avec le SDIS, les SIH doit améliorer la qualité de la régulation médicale. Un flux croissant d information arrivant aux centres de régulation médicale par voies textuelles. Le traitement correct de ces sources de données devra se faire via des automates qui scanneront les informations textuelles pour en extraire les informations pertinentes. La mise en place d un serveur vocal interactif permet de décharger un ensemble d appels arrivants aux Centres 15 et dont l objet est uniquement une demande d information (ex : pharmacie de garde la plus proche...). Les fonctionnalités devenues communes de géolocalisation telles que GoogleMaps ouvrent le champ à des améliorations significatives de l engagement de moyens. Classification : Public 26 / 119

27 ASIP Santé Mars Interactions hospitalières / pré-hospitalières Le schéma ci-dessous présente les interactions actuelles et cibles entre le monde hospitalier et le monde pré-hospitalier. Ces nouvelles interactions ont pour objet d une part d améliorer la qualité du soin apporté en valorisant le maximum d informations disponibles sur le patient pour l acte de régulation médicale et d autre part, de faire en sorte que les SMUR et les urgences du SIH puissent recevoir en avance de phase des informations pertinentes sur la future prise en charge Focus sur la reprise d activité Compte tenu de l augmentation croissante et constante du nombre de sollicitations faites aux SAMU, il est nécessaire que la nouvelle application permette des mécanismes de reprise d activité précis et efficaces. Cette section s attache à détailler les différentes typologies de reprise d activité, ainsi que les conditions nécessaires à une reprise d activité Les différents types de reprise d activité On peut distinguer 4 types de reprise d activité différents : La reprise d activité en cas de panne majeure d un SAMU : Ce sont d autres SAMU qui vont récupérer son activité. Les informations du ROR du SAMU en panne sont indispensables pour le SAMU reprenant l activité ; La reprise d activité en cas d épidémie : un pré choix au niveau du SVI offre la capacité à répartir ces sollicitations au niveau national. Les autres SAMU peuvent traiter l appel sans ROR local puisqu ils délivreront une information standard. Par contre, lorsque le cas est problématique et nécessite un engagement de moyen, l appel est routé sur le SAMU du département pour traitement ; La reprise d activité en cas de surcharge (sans épidémie) d un SAMU : Ce type de reprise d activité est à envisager compte tenu de l augmentation continue du nombre de demandes Classification : Public 27 / 119

28 ASIP Santé Mars 2012 auprès des SAMU. Toutefois, ce type de reprise d activité est à envisager de manière très encadrée, au sein d un projet médical géographiquement bien délimité avec la signature de convention entre les acteurs; La reprise d activité en cas de débordement : cette situation est globalement rare compte tenu du nombre de lignes téléphoniques disponibles au sein des SAMU Les conditions nécessaires pour la reprise d activité Afin de pouvoir reprendre l activité d un autre SAMU, il est indispensable de disposer des éléments suivants : L appel téléphonique du patient ; Le «ROR local» : ce référentiel contient la liste des partenaires et des moyens d intervention associés à un territoire de santé ; Les DRM (Dossier de Régulation Médicale) en cours de traitement à l instant t où la reprise d activité est devenue nécessaire. Cas particulier : dans le cas d une tension épidémiologique, il n est pas nécessaire de posséder le ROR du SAMU débordé : Si le cas n est pas critique, un conseil médical est délivré au patient (ressources locales inutiles) Si le cas nécessite une prise en charge, l appel peut-être redirigé vers le SAMU d origine Focus sur le pilotage national Le pilotage national peut s envisager en deux temps : 1. La valorisation de données globales de trafic des SAMU pour obtenir à froid des éléments d analyse qui permettront de mieux s organiser et de mieux communiquer sur l activité des SAMU au niveau des ARS (reporting, statistique,...) Dans un premier temps, ce système ne nécessite pas un pilotage en temps réel de l activité et ne doit pas permettre le basculement automatique des appels au niveau des SAMU. 2. Pilotage dynamique de la charge en activant la reprise d activité en situation de surcharge : à utiliser dans une logique de partenariat construit, de projets médicaux délimités géographiquement avec la définition de convention. Il convient d éviter un éventuel effet de cacophonie. Le basculement automatique des appels en cas de débordement doit se faire progressivement dans le cadre d une politique nationale clairement définie et de la déclinaison territoriale dotée d un projet médical géographiquement limité avec la signature de convention entre les protagonistes. Dans certains cas (pandémie, panne complète...), ce basculement pourra se faire automatiquement. 2.2 Description fonctionnelle cible des SAMU L analyse des principaux domaines d activité cibles des SAMU a permis d établir une description fonctionnelle synthétique de l activité des SAMU Centre 15 : Classification : Public 28 / 119

29 ASIP Santé Mars 2012 Le tableau suivant présente la description des différents blocs fonctionnels qui construisent l activité des SAMU : Classification : Public 29 / 119

30 ASIP Santé Mars COMPARAISON DES SCENARIOS 3.1 Présentation des scénarios considérés Quatre scénarios de modernisation SI et Télécom ont été considérés afin de répondre au mieux aux besoins de modernisation des SAMU Centre 15. Les sections suivantes présentent les caractéristiques de chacun de ces scénarios Scénario 1 - des spécifications communes pour inter opérer Le scénario 1 consiste à exercer des synergies sur le "design", c'est-à-dire sur la phase de conception et d'évolution fonctionnelle de la solution. Ce scénario s inscrit dans la continuité de ce qui se fait aujourd hui (chaque SAMU utilise le logiciel de son choix et l exploite) en prévoyant en plus la mise en place d une logique d homologation des éditeurs du marché pour les contraindre à rendre leur logiciel plus inter opérant entre eux, avec les différents acteurs externes et avec les grands référentiels nationaux. Classification : Public 30 / 119

31 ASIP Santé Mars 2012 Ce scénario permet à chaque SAMU de s aligner sur des spécifications communes. Il permet notamment : La définition et le partage de spécifications communes à tous les SAMU permettant aux systèmes de respecter un cahier des charges normatif, et notamment de communiquer entre eux et avec les partenaires, Une politique industrielle permettant de garantir la conformité des solutions par rapport aux spécifications (avec la mise en place d'un processus de certification), Une gouvernance commune pour la conception et la publication des spécifications, mais une autonomie des SAMU dans le choix et l évolution de leur solution. Il n est pas nécessaire de mettre en place une organisation pour piloter l évolution de la solution entre SAMU, Un renforcement de tous les processus achats afin qu ils soient appliqués à tous les SAMU, Des coûts d évolutions et d exploitation de l application qui restent non partagés et désynchronisés, Une qualité de service à gérer au cas par cas par chaque SAMU avec son exploitant. Classification : Public 31 / 119

32 ASIP Santé Mars Scénario 2 - Une solution commune opérée localement Le scénario 2 diffère du scénario 1 par la convergence et le déploiement du logiciel d un éditeur unique ("DESIGN and BUILD partagés"). L intérêt est de permettre aux différents SAMU Centres 15 de disposer d une capacité accrue à inter opérer par rapport au scénario 1. L éditeur restant est installé en situation de quasi monopole mais tenu par un cadre contractuel adapté. Ce scénario permet la construction d une solution de régulation et de téléphonie identique pour chaque SAMU. On y retrouve : La spécification et la réalisation communes d une solution de régulation médicale et de centres d appels pour tous les SAMU permettant la mutualisation des investissements, Une gouvernance commune pour la conception, la réalisation et les évolutions, L exploitation de la solution commune reste sous la responsabilité de chaque SAMU, Les systèmes sont compatibles au niveau des interfaces par construction et peuvent échanger des dossiers de régulation de manière native, Classification : Public 32 / 119

33 ASIP Santé Mars 2012 La définition d une politique industrielle forte permet de bénéficier d un outil complet et évolutif commun à chaque SAMU, Les coûts d exploitation de l application restent peu optimisés. Chaque montée de version nécessite de réaliser la mise à jour de l application autant de fois que de SAMU utilisant la solution. Le risque d'hétérogénéité n'est pas totalement éliminé Scénario 3 - Une solution opérée localement et complétée par un dispositif régional d échange et de sauvegarde Classification : Public 33 / 119

34 ASIP Santé Mars 2012 Le scénario 3 est une variante du scénario 2 dans lequel la convergence du BUILD est assurée essentiellement au niveau régional. Il est dans la continuité de la tendance actuelle avec une consolidation progressive de pôles régionaux. L activité des SAMU reste locale à chaque département avec un étage supplémentaire au niveau régional permettant une bonne interaction des SAMU entre eux, tout en augmentant le niveau de disponibilité au niveau intra régional. Le scénario 3 offre une sécurisation supplémentaire par rapport au scénario 2. Il comprend : La spécification et la réalisation communes d une solution de régulation médicale et de centres d appels pour tous les SAMU permettant la mutualisation des investissements, Chaque SAMU conserve la responsabilité de l exploitation locale de cette solution, La mise en place d une plate-forme centralisée permettant d assurer une synchronisation régulière des données de chaque SAMU. Ce système offre d'une part un backup en cas de panne d'autre part une consolidation potentielle des données de tous les SAMU sur une unique plateforme (permettant la construction de statistiques communes) Les systèmes locaux sont interfacés par construction et partagent des dossiers de régulation de manière native, Une gouvernance commune pour la conception, la réalisation et les évolutions, Cependant, le partage d un système de secours commun implique une certaine coordination des SAMU quant à la manière d exploiter la solution, Ce partage de données nécessite des mécanismes supplémentaires et donc des investissements associés seront nécessaires pour permettre cette sécurité supplémentaire. Ce concept est actuellement déployé à un niveau régional, on considère alors que ce scénario est un scénario tendanciel régional. Classification : Public 34 / 119

35 ASIP Santé Mars Scénario 4 - Une solution unique, commune et partagée Le scénario 4 présente une solution unique, centralisée et mutualisée ("DESIGN, BUILD et RUN") par l ensemble des SAMU Centre 15. L interconnexion entre l ensemble des SAMU Centre 15 est native, apportant une vraie capacité de régulation et de pilotage. La solution implémente la virtualisation de la téléphonie ce qui permet de bénéficier des plus values fonctionnelles du couplage entre les applications (de régulation) et la téléphonie. Afin d offrir un service mutualisé et évolutif, le scénario 4 prévoit : La spécification et la réalisation commune d une solution de régulation médicale et de centres d appels pour tous les SAMU permettant la mutualisation des investissements, La solution est opérée de manière mutualisée à travers une infrastructure robuste, redondée garantissant des niveaux de disponibilité élevés, La qualité de service centralisée profite à l ensemble des SAMU du territoire, Une homogénéité et une interconnexion natives de tous les SAMU grâce notamment au partage des processus de régulation et de référentiels (ROR, basses communes des dossiers de régulation), Une gouvernance commune pour la conception, la réalisation, les évolutions et les opérations de cette solution : la possibilité d apporter localement à la solution mutualisée des personnalisations adaptées Possibilité de créer des profils adaptés à différents types de SAMU (petit, moyen, grand, avec des partenariats spécifiques, etc.) Des coûts d exploitation de l application optimisés. Chaque montée de version nécessite une unique opération transparente pour le service délivré. Classification : Public 35 / 119

36 ASIP Santé Mars Dynamique d évolution des scénarios Afin d illustrer la dynamique d évolution des scénarios dans le temps, des schémas simples d évolution des 4 scénarios à 3, 5 et 10 ans sont proposés dans ce chapitre. Le schéma suivant illustre la disparité actuelle des solutions de régulations médicales utilisées au niveau national. Classification : Public 36 / 119

37 ASIP Santé Mars 2012 Principe du schéma : Chaque rond représente une solution exploitée localement (département) dans un SAMU. Chaque couleur correspond à un logiciel d un éditeur du marché. Les DOM-TOM ne sont pas représentés ici, mais ils suivent la même logique qu une région en métropole Scénario 1 - des spécifications communes pour inter opérer 3 ans 5 ans 10 ans Les SAMU opèrent localement une solution de l éditeur de leur choix. Les solutions sont certifiées par un dispositif qui garantit une certaine inter opérabilité. Le marché étant d'une solvabilité limitée, certains éditeurs disparaissent ne pouvant maintenir la compétitivité de leur solution. Classification : Public 37 / 119

38 ASIP Santé Mars 2012 Seuls quelques éditeurs restent sur le marché. Leur taille leur permet d assurer le maintien en condition opérationnelle de leur solution, mais sans assurer un niveau d'investissement permettant de prendre en compte rapidement les évolutions fonctionnelles qui seraient en rupture avec l'existant Scénario 2 - Une solution commune opérée localement 3 ans 5 ans 10 ans Les SAMU migrent leur système vers la solution commune qu ils opèrent localement. Une majorité des SAMU utilise la solution commune. Cette solution permet l échange d informations entre SAMU équipés de la même solution. Tous les SAMU utilisent la même solution qu ils opèrent localement. Les interactions nationales sont possibles, mais restent limitées à l échange plus qu'au partage Scénario 3 - Une solution opérée localement et complétée par un dispositif régional d échange et de sauvegarde Classification : Public 38 / 119

39 ASIP Santé Mars ans 5 ans 10 ans Les SAMU d une même région utilisent une solution commune, mais qui peut être différente entre régions (plusieurs éditeurs). Des systèmes régionaux de sauvegardes sont construits progressivement dans chacune des régions. Certains SAMU utilisent la solution de leur région. Tous les SAMU utilisent leur solution régionale. Les SAMU d une même région peuvent partager des informations entre eux, mais les interactions extra régionales restent difficiles Scénario 4 - Une solution unique, commune et partagée 3 ans 5 ans 10 ans Construction de la solution commune et partagée. Migration rapide d un premier lot des SAMU vers cette nouvelle solution (i.e. les SAMU les moins bien équipés aujourd hui et quelques-uns de grande taille). La migration est coordonnée au niveau de chaque région Le mouvement de la migration des SAMU vers la nouvelle solution s accélère pour les SAMU n ayant pas encore migré. Les SAMU migrés peuvent partager des données et interagir facilement. Tous les SAMU utilisent la nouvelle solution et partagent nativement des informations (dossier de régulation, géolocalisation des ressources, etc.) au niveau national. 3.2 Méthode d analyse Afin de comparer les quatre scénarios précédents, une comparaison a été conduite à l aide de deux grilles d analyses complémentaires, l'une par la capacité à atteindre les objectifs stratégiques identifiés et l'autre par une analyse exhaustive multi critères. Classification : Public 39 / 119

40 ASIP Santé Mars 2012 La logique de l analyse par axe stratégique est d'évaluer les différents scénarios par rapport à un nombre réduit d'objectifs, huit en l'occurrence, considérés comme les plus importants pour les SAMU ; La logique de l analyse multi critères est d avoir une grille d analyse se voulant aussi exhaustive et objective que possible. Cette analyse permet par construction un balayage large et complet des points sur lesquels il est possible d'évaluer objectivement les différents scénarios Analyse par axe stratégique Cette analyse recense les objectifs les plus stratégiques pour la nouvelle application de gestion de la régulation des SAMU. Huit critères ont été identifiés comme stratégiques : Rendre le juste soin avec un service de qualité élevé ; Gestion de la régulation et pilotage à l échelle nationale ; Disposer d un système hautement disponible ; Garantir la confidentialité des données de santé ; Gestion de crise nationale ; Interactions avec les partenaires (SDIS, SOS médecin, etc.) ; Interactions avec les logiciels de santé ROR et DMP ; Adéquation entre la dépense publique et l activité des SAMU. Le schéma ci-dessous vient détailler ce que signifie chacun de ces critères stratégiques. Classification : Public 40 / 119

41 ASIP Santé Mars Analyse multi-critères objective L analyse multi critères objective est une analyse complémentaire à l analyse par axe stratégique. Son but est d évaluer objectivement l adéquation des 4 scénarios selon des critères qualitatifs de la solution cible. Pour se faire, 5 axes d analyse majeurs ont été identifiés sur les thématiques suivantes : Fonctionnalités de la solution ; Qualité de service ; Capacité à piloter ; Stratégie industrielle ; Rationnel économique. Ces 5 axes d analyse servent de base à la démarche de comparaison des 4 scénarios identifiés. Chacun de ces axes d analyse est traité sous forme de questions qui serviront à l évaluation des 4 scénarios. Ainsi, chaque axe d analyse se décompose en un ensemble de questions regroupées par catégories. Ces questions ont été identifiées dans le but de couvrir le plus grand nombre d aspects de l axe analysé. Certaines catégories qui sont plus stratégiques que d autres ont une pondération accrue (voir les coefficients sur les tableaux de synthèse indiquant le coefficient multiplicateur). A titre indicatif, voici la liste des questions identifiées sur l axe fonctionnel : Eviter la divergence des solutions à terme Rationaliser le traitement des appels par les ARM (scriptage/formalisation) Déployer rapidement un CRRA supplémentaire ou des postes de régulation supplémentaires en cas de besoins de salle de crise temporaire ou d installation d un nouveau SAMU) Partager des DR/DRM Partager les moyens (disponibilité, géolocalisation, etc.) Faciliter l envoi et la réception de données avec les partenaires Partager un thésaurus commun Gérer la co-régulation, le délestage et le débordement Consulter/alimenter les grands référentiels (DMP, ROR...) Partager les fiches réflexes et guides d aide à la régulation Intégrer de manière sécurisée le système ANTARES Fournir des reporting cohérents aux niveaux national et régional Pour l axe d analyse «rationnel économique», compte tenu de l incapacité d obtenir de tous les SAMU les données économiques réelles sur la situation actuelle des SAMU de France, un modèle économique a Classification : Public 41 / 119

42 ASIP Santé Mars 2012 été construit pour évaluer les 4 scénarios. Le schéma ci-dessous explique la logique du modèle économique établi. Classification : Public 42 / 119

43 ASIP Santé Mars Analyse comparative Comparaison des scénarios Comparaison par axe stratégique Le tableau suivant présente la synthèse de l'analyse détaillée dans les pages suivantes : Classification : Public 43 / 119

44 ASIP Santé Mars 2012 Analyse détaillée : Axes stratégiques Scénario 1 Scénario 2 Scénario 3 Scénario Rendre le juste soin avec un service de qualité élevé au niveau régional La disparité des SAMU en termes de solutions logiciels et télécoms, conjuguée aux logiques de financement locales et inégales ne permettent pas d offrir un niveau de service de qualité homogène. La logique de financement local est inégale entre les SAMU et ne permet pas d offrir un niveau service de qualité homogène. Néanmoins, les solutions techniques identiques améliorent l homogénéité du service rendu par les SAMU. Les solutions techniques assurent au niveau régional un service de qualité homogène. Néanmoins des disparités sur la qualité offerte peuvent exister entre les régions. Les échanges intra régionaux sont parfaitement assurés entre les SAMU de la région Le caractère unique et centralisé de la solution technique permet de rendre un service de qualité, parfaitement homogène sur l ensemble du territoire national Les capacités d échanges entre SAMU sont excellentes autant régionalement que inter régionalement au niveau national Les capacités d échange inter régionaux entre SAMU ne sont pas satisfaisantes et limitent la qualité du service offert en périphérie des régions. + + Gestion de la régulation et pilotage à l échelle nationale La nature locale des solutions ne permet pas d envisager un pilotage national ni une régulation autrement que par des moyens extra informatiques Le pilotage comme la régulation peuvent être assurés partiellement à l échelle régionale (avec des limites, car il n y a pas de centralisation de la solution), mais restent difficiles au niveau national. Le caractère centralisé de la solution technique permet d une part une remontée consolidée de l activité nationale des SAMU et d autre part une régulation native Classification : Public 44 / 119

45 ASIP Santé Mars 2012 Axes stratégiques Scénario 1 Scénario 2 Scénario 3 Scénario Gestion de crise nationale Incapacité de coordination nationale pour optimiser l action des SAMU Pas d équilibrage possible des sollicitations téléphoniques sur le plan national Déploiement complexe de nouvelles fonctionnalités communes à cause de la gestion locale des solutions. Le système est adapté pour la gestion de crise régionale, mais pas nationale Harmonisation au niveau national des réponses faites par chaque SAMU Centre 15 et par chaque cellule de crise, Mise à jour automatique et nationale de l'algorithme d'aide à la régulation médicale avec les directives nationales, La solution fournit une «exacte» appréciation des sollicitations adressées aux SAMU, consolidée au niveau national, grâce à une base de données centrale unique permettant d'effectuer les traitements informatiques nécessaires pour dénombrer les typologies d'appels et les suites données". Classification : Public 45 / 119

46 ASIP Santé Mars 2012 Axes stratégiques Scénario 1 Scénario 2 Scénario 3 Scénario Interactions avec les référentiels de santé ROR et DMP Le dispositif de labellisation des solutions garantit une interopérabilité «minimum» des solutions avec les référentiels de santé. La construction commune de la solution assure une interopérabilité homogène avec les référentiels de santé. Mais la connexion avec ces derniers reste gérée localement avec autant d interfaces que de départements. Les interactions avec les référentiels de santé s opèrent au niveau régional, limitant la multiplicité des interfaces. En revanche, il est probable que les solutions soient différentes d une région à l autre. La solution est interfacée via une interface unique fonctionnelle et technique avec les référentiels de santé, ce qui facilite et industrialise les échanges. Le déploiement ou l extension d un référentiel peut être réalisé de manière quasi instantanée. + + Disposer d un système hautement disponible (y compris sur la téléphonie) L utilisation des infrastructures techniques locales des SAMU n offre des systèmes de secours satisfaisants que s ils sont totalement redondés. Ils pourraient être redondés mais au prix d un surcout budgétaire très conséquent et probablement de manière disparate. La mise en place d un centre de backup régional permet la sauvegarde des données, mais ne résout pas les pannes de téléphonie, qui restent locales. Là encore une redondance de la partie téléphonie pourrait être envisagée, mais à un coût très conséquent. Le centre national offre le plus grand niveau de disponibilité et de sécurité en offrant une redondance des infrastructures logicielles et téléphoniques (doublement des liens réseau sur 2 opérateurs différents). Au niveau local, deux accès MPLS séparés eux-mêmes éventuellement «backupés» par des accès ADSL ou 4G. Cependant, le caractère unique du système fait que si le système connaît malgré tout une panne, toute l activité serait impactée Classification : Public 46 / 119

47 ASIP Santé Mars 2012 Axes stratégiques Scénario 1 Scénario 2 Scénario 3 Scénario Interactions avec les partenaires (SDIS, SOS médecin, etc.) Le raccordement des SAMU aux systèmes de ses partenaires est complexe, car il doit se faire autant de fois que de SAMU. Le cadre normatif avec la labellisation permet cependant d assurer des échanges. Le raccordement des SAMU aux systèmes de ses partenaires est complexe, car il doit se faire autant de fois que de SAMU. La solution unique permet cependant de faciliter les échanges La proximité des groupes de SAMU avec leurs partenaires par région, mais aussi l existence d un centre de backup, facilitent les interactions avec les partenaires. Les interfaces pourraient s effectuer au niveau du centre de backup régional. La position centrale et unique du centre de production lui permet d offrir un unique point d interconnexion avec la totalité des SAMU à l ensemble de ses partenaires. Cependant, les partenaires sont locaux entrainant une multiplication des connexions. + Garantir confidentialité données de santé la des La conservation des systèmes de données locaux et la diversité des situations ne garantissent pas aux SAMU d être conformes aux obligations légales en termes de confidentialité des données (droits d accès règlementés aux données de santé nominative) La conservation de systèmes locaux et la diversité des situations apportent les mêmes limitations de conformité des SAMU aux obligations légales que le scénario 1. En complément, le centre de backup doit être agréé pour l hébergement de données de santé à caractère personnel En raison de la centralisation des données et leur absence au niveau local, mais aussi grâce au développement d une nouvelle application complète, ce scénario permet de respecter plus efficacement les obligations légales en termes de confidentialité des données de santé, En complément, le centre de backup doit être agréé pour l hébergement de données de santé à caractère personnel Classification : Public 47 / 119

48 ASIP Santé Novembre Comparaison multi critères Les schémas en étoile ci-dessous présente la synthèse de l'analyse multi critères. La suite de la section reprend les comparaisons par scénarios par catégories. Le scénario 4 se distingue nettement dans cette comparaison Critère "Fonctionnel" La mise en place d une solution commune tant dans la réalisation que dans l exploitation (scénario S4), permet d offrir des fonctionnalités plus évoluées et plus larges, notamment grâce à une capacité de financement de la solution plus élevée que dans les autres scénarios Le scénario S3 apporte une réponse fonctionnelle de qualité au niveau régional, mais pas au niveau national, de plus il risque de créer une situation hétérogène entre les régions, Classification : Public 48 / 119

49 Les scénarios S1 et S2 apportent un grand risque de disparité des fonctionnalités dans le temps, même si un dispositif de labellisation des solutions dans S1 garantissait a minima l interopérabilité des solutions favorisées par la mise en place de référentiels homogènes au niveau national. En termes de gestion de crise nationale, le scénario S4 grâce à son fonctionnement centralisé, permet de répondre efficacement et uniformément aux besoins fonctionnels liés à une situation de crise nationale (déploiement rapide de modules spécifiques, partage d information, etc.). Le scénario S1, S2, S3 peuvent difficilement apporter des réponses fonctionnelles satisfaisantes Critère "Qualité de service" La qualité de service nécessaire au bon fonctionnement des futures solutions, est un point essentiel de la modernisation SI et Télécom des SAMU, La centralisation des équipements imposée par le scénario S4 permet d offrir une qualité de service plus élevée que celle des autres scénarios, Le scénario 3 reste satisfaisant, mais il présente une qualité de service moins homogène en raison du cloisonnement des régions, Les scénarios 1 et 2 n apportent pas d amélioration homogène de la qualité de service sur l ensemble du territoire, Sur l aspect confidentialité, la gestion des données nominatives de santé doit respecter les obligations légales (L et L ) : le droit du patient, la gestion des accès (obligation d être PS ou ES et d y être autorisé) et enfin le respect des agréments d hébergement. Le scénario 4 permet de répondre efficacement à ces obligations par le caractère centralisé des données, a contrario des autres scénarios qui stockent les données en local. Classification : Public 49 / 119

50 Critère "capacité à piloter" Le découpage des SAMU par bloc régional du scénario S3 (sous le contrôle des ARS) permet une mise en place des instances de gouvernance de façon simplifiée et permet de rationaliser le marché des éditeurs en maintenant sa compétitivité, Le partage d une solution unique pour tous les SAMU (S2 et S4) implique la création d instances de gouvernance au niveau national. Cela nécessite la création d une autorité supérieure en charge de coordonner les sujets et d arbitrer les décisions si nécessaire. En complément cette autorité sera légitime pour piloter le SI des SAMU, Le scénario 4 offre la possibilité de gérer efficacement d un point de vue organisationnel le dispositif national permettant de faire face à une crise de grande envergure (ex. pandémie). En situation de crise, les scénarios 1 et 2 sont fortement désarmés pour faire face à la situation. Le scénario 3 quant à lui permet une bonne gestion régionale, mais est insuffisant au niveau national Critère "stratégie industrielle" Le scénario S3 est satisfaisant et nécessite a priori moins d effort pour être mis en œuvre. Cependant il augmente sensiblement le cloisonnement des régions et donc aussi l hétérogénéité dans la réalisation et l exploitation des solutions. La stratégie industrielle à mettre en œuvre pour les scénarios S1 et S2 est assez commune à ce qu il se fait aujourd hui. Cependant le scénario S1 entraînera une grande dispersion du marché pouvant conduire à la disparition des petits éditeurs tandis que le scénario S2 implique une position monopolistique de l éditeur retenu. Classification : Public 50 / 119

51 La stratégie industrielle du scénario S4 nécessite de bien séparer les processus (design, BUILD et RUN) et de solliciter des compétences métier pour mener à bien les AO associés aux processus Critère rationnel économique Chacune des précédentes courbes s appuie sur un jeu d hypothèse calibrant la vitesse de montée des SAMU sur la nouvelle infrastructure. Le tableau suivant fait une synthèse des résultats annuels de «cash out» pour les 4 scénarios : Classification : Public 51 / 119

52 Le scénario S4 présente le cash out le plus réduit avec une dynamique de cash out qui diminue continuellement dans le temps tout en apportant un service homogène et une forte flexibilité du service au niveau national, Le scénario S2 présente un coût global de +26% / S4 et il ne permet pas d offrir un service de qualité homogène, car au cours du temps des différences sur les paliers applicatifs apparaitront, Le scénario S1 présente un cout global de +28% / S4 et il ne permet pas d offrir un service de qualité homogène, Les scénarios S1 et S2 présentent une évolution de leur cash out en augmentation continue dans le temps, Le scénario S3 apporte une réponse globalement satisfaisante aux axes stratégiques des SAMU, mais présente le coût le plus élevé à cause de son échelon régional avec +41% / S4, ainsi qu une forte progression de son cash out sur la période. En fin de période, il laisse un OPEX récurrent de 18 M à comparer à 10 M pour le scénario S4. A noter : le montant du scénario 4 a été ajusté dans la phase d élaboration de la feuille de route, notamment pour tenir compte d une analyse plus poussée des couts relatifs à la mise en place d une infrastructure de téléphonie nationale. Cela ne remet pas en cause les logiques tendancielles des différents scénarios Synthèse par scénario La section suivante présente scénario par scénario la synthèse des analyses menées Scénario 1 - des spécifications communes pour inter opérer Points saillants : La principale amélioration réside dans la mise en place d une logique de standardisation et de labellisation des éditeurs du marché pour les contraindre à rendre leur logiciel plus inter opérant. La capacité réelle à spécifier en commun n'est pas, jusqu à présent, encore démontrée, compte tenu de la diversité des acteurs Avantages : Ce scénario est bien perçu par les acteurs métiers, La gouvernance et la stratégie industrielle sont simples, mais apportent peu de plus-value, Inconvénients : La qualité de services et le niveau des fonctionnalités restent globalement bas et non homogènes, notamment sur la durée, Une capacité d échange limitée qui rend difficiles la régulation entre SAMU, le pilotage national, la gestion de crise, les interactions avec les partenaires et les grands référentiels nationaux, Le marché des éditeurs reste dilué et non suffisamment solvable, Classification : Public 52 / 119

53 L adéquation entre le niveau des dépenses publiques et les services rendus à l activité reste assez faible, Le besoin de cash out augmente de manière continue, Les contraintes obligatoires de confidentialité présentent un risque en raison de la conservation locale des données Scénario 2 - Une solution commune opérée localement Points saillants : La démarche pour arriver à une solution qui soit localement la même pour tous les SAMU est un objectif probablement difficile à atteindre, L éditeur restant est installé en situation de quasimonopole. Cependant un accord équilibré peut être trouvé avec lui pour garantir un service à un coût réaliste dans la durée via un cadre contractuel adapté Avantages : Tous les SAMU sont équipés d une même solution ce qui accroît l homogénéité du service rendu et les capacités d interopérabilité par rapport au scénario Inconvénients : La qualité de service et le niveau des fonctionnalités restent globalement bas et non homogènes, notamment sur la durée, La capacité d échange reste limitée, ce qui rend difficiles la régulation entre SAMU, le pilotage national et la gestion de crise, La réactivité de l éditeur en termes d évolution risque de ne pas être bonne compte tenu de sa position monopolistique, L adéquation entre le niveau des dépenses publiques et les services rendus à l activité reste assez faible, Classification : Public 53 / 119

54 Il est complexe d investir et de migrer vers une solution unique pour la centaine de SAMU, Les contraintes obligatoires de confidentialité présentent un risque en raison de la conservation locale des données. La conduite du changement n est pas négligeable puisque l ensemble des SAMU migre sur un même outil dans des projets d implantation disjoints Scénario 3 - Une solution opérée localement et complétée par un dispositif régional d échange et de sauvegarde Points saillants : Ce scénario est la continuité tendancielle avec la consolidation progressive autour de pôles régionaux Avantages : Ce scénario offre une couverture fonctionnelle satisfaisante et des capacités de régulation au niveau régional, En termes de stratégie industrielle, ce scénario rationalise le marché des éditeurs, actuellement trop dilué par rapport à sa taille, Au niveau gouvernance, le scénario permet de capitaliser sur la dynamique régionale en vigueur, impulsée par les ARS L adéquation entre l activité et les financements publics sont correctement effectués grâce à la consolidation des pôles régionaux. Classification : Public 54 / 119

55 Inconvénients : Capacité très limitée à gérer les aspects supra régionaux de collaboration entre SAMU en situation nominale, mais également lors de situation de crises nationales, Le dépassement de la logique régionale sera extrêmement difficile à organiser de manière homogène, Les informations de santé restent conservées localement et gérées dans le cadre de politiques de sécurité non homogènes, Son coût d implémentation est le plus onéreux en investissements et en fonctionnement récurrent puisqu il présente des infrastructures à la fois locales et régionales Scénario 4 - Une solution unique, commune et partagée Points saillants : Ce scénario correspond à une logique de mise en œuvre novatrice qui ouvre un potentiel de bénéfices importants Avantages : Le niveau de service offert est parfaitement défini et homogène pour tous les SAMU sur l ensemble du territoire, La gestion de la régulation et le pilotage au niveau national sont conçus de manière native Excellente capacité à gérer les situations de crises nationales (grande flexibilité pour ajout/extension d un SAMU, déploiement facilité de modules spécifiques,...), Les interactions avec le ROR national, le DMP et avec les partenaires sont facilitées, Classification : Public 55 / 119

56 L adéquation entre l activité et les financements publics sont correctement effectués au niveau national, Le critère économique est favorable, surtout dans les coûts récurrents d exploitation qui baissent continuellement dans le temps pour finir par se stabiliser, Les possibles adaptations organisationnelles des SAMU n impactent pas les choix informatiques de ce scénario, La confidentialité des données de santé mise en place dans ce scénario permet de respecter les obligations légales Inconvénients : La gouvernance à mettre en place est complexe, La conduite d un projet de cette complexité technologique est délicate et présente des risques même si des projets similaires existent, de plus il demande une conduite du changement conséquente Une forte volonté politique est nécessaire pour assurer la mise en place de ce scénario Conclusions de l'analyse comparative et suite de l étude Les scénarios agissant directement sur les caractéristiques de l offre logicielle adaptée au SAMU Les scénarios 1 et 2 constituent une avancée importante par rapport à la situation actuelle, notamment sur l inter fonctionnement et la mise en place des référentiels. Ils rentrent bien dans les logiques actuelles de recherche d efficacité et d interopérabilité s appuyant sur la standardisation des logiciels, la labellisation et la sélection d offres industrielles pérennes, et économiquement compétitives s agissant de la solution 2. Le Programme Hôpital Numérique, la certification des fonctionnalités d aide à la prescription par la HAS ou l homologation des logiciels intégrant le DMP sont des exemples de dispositifs élaborés autour de cadres normatifs. Les scénarios 1 et 2 s appuient sur une mise en œuvre locale selon un cycle d investissement discontinu engendrant des disparités importantes dans le service délivré. Par ailleurs le scénario 1 permet difficilement de rendre solvable et d industrialiser les solutions techniques dans un marché de très petite taille sauf à imposer une certification exigeante. Classification : Public 56 / 119

57 Les scénarios 1 et 2 ne permettent pas de garantir la mise en place du besoin fondamental de garantir un service de qualité homogène au niveau national notamment sur le volet téléphonie. Le scénario 1 constitue donc une solution minimaliste peu coûteuse et peu efficiente, mais présentant un ratio coûts / bénéfices pouvant être intéressant. Le scénario 2 présente les quelques défauts du scénario 4 et aucun de ses avantages. Seul l aspect «psychologique» de la localisation de l application est à mettre au crédit de ce scénario par ailleurs complexe et coûteux. Les scénarios 1 et 2 laissent au niveau local la mise en œuvre de la gestion des appels et des télécommunications. Par ailleurs, ils n'intègrent pas de fonctionnalité de transfert d'activité d'un SAMU à l'autre que ce soit en situation de pic d'activité ou de crise comme en cas d'indisponibilité du SI. Une solution de conception d'un SI de gestion des appels à l'échelle nationale permettrait de combler ce manque. Cette variante n'a pas été analysée dans la phase 1 de l'étude, mais fera l'objet d'un approfondissement dans la suite de l'étude, à rapprocher de l'analyse similaire nécessaire pour le scénario Scénario de continuité sur la dynamique régionale avec consolidation progressive sur la maille régionale Ce scénario (n 3) qui capitalise sur la dynamique régionale en vigueur, incarnée par le rôle des ARS, offre une bonne couverture fonctionnelle au niveau régional avec l organisation des SAMU entre eux et leur capacité à se sécuriser mutuellement sur un premier niveau de mutualisation. Cette évolution s inscrit donc assez «naturellement» dans l environnement institutionnel. Cependant, il ne permet pas nécessairement de rationaliser un marché d éditeurs spécifiques, déjà trop dilué par rapport à sa taille et peut même exposer, comme sur d autres sujets, à une multiplication de solutions régionales très hétérogènes dans leur mise en œuvre. Son inconvénient majeur réside dans sa capacité très limitée à gérer les aspects supra régionaux de collaborations entre SAMU en situation nominale, mais surtout lors de situation de crises nationales. Il risque de créer des situations très inhomogènes non plus au niveau département, mais au niveau régional. Le cloisonnement accru des régions entre elles risque d engendrer des ruptures de services dans les zones limitrophes au niveau régional. Ce scénario est le plus couteux en investissement et en fonctionnement récurrent et nécessite une capacité à concevoir et piloter un dispositif régional critique, aujourd hui absent pour un certain nombre de régions. La mise en place d une gouvernance nationale plus forte permettrait d éviter les points de faiblesses identifiés les plus forts, mais plaiderait dans ce cas pour le scénario Scénario de mise en place d une solution unique et mutualisée Ce scénario (n 4) consiste à mettre en place une solution unique et mutualisée au niveau de l exploitation, où applications et téléphonie seraient disponibles en mode service (approche «SaaS» Software as a Service). Sa logique de centralisation et de mutualisation par l ensemble des SAMU Centre 15 lui confère une capacité à offrir un service de haute qualité et parfaitement homogène sur l ensemble du territoire national dépassant les clivages interrégionaux. L interconnexion entre l ensemble des SAMU Centre 15 est native, apportant de vraies capacités de régulation et de pilotage, agiles à l échelle nationale. La capacité de cette solution pour faire face à une crise nationale est optimale (déploiement rapide et facilité de modules complémentaires, d outils d aide à la décision, etc.). Ses interactions avec les services logiciels nationaux de santé (ROR, DMP) sont facilitées ainsi que les échanges avec l ensemble des partenaires (SDIS, ambulanciers privés, services des urgences, etc.). Le critère économique est favorable, surtout dans les coûts récurrents, mais les coûts d investissement sont plus concentrés dans le temps. Enfin, il offre la meilleure garantie en matière Classification : Public 57 / 119

58 de disponibilité et de sécurité dans un cadre particulièrement sensible sous réserve d être piloté de façon industrielle et rigoureuse. Ce scénario incarne un changement majeur dans la stratégie de mise en œuvre du système d information sous responsabilité d établissement de santé. Il est porteur de bénéfices très importants, mais se trouve, par contre exigeant en matière de volonté politique, et tributaire d une nécessaire centralisation des budgets d investissements. Il est également plus exigeant en termes de maîtrise d ouvrage pour sécuriser sa bonne fin (risque inhérent à tout projet informatique de taille critique dans un environnement public à maîtrise d ouvrage complexe). Il doit enfin dépasser les réticences des responsables métiers des SAMU tentés d y voir une perte dans leur autonomie de fonctionnement en leur garantissant une qualité de mise en œuvre irréprochable correspondant à la criticité et la sensibilité de leur activité Suite à donner à l'étude Suite à l'analyse comparative menée, la proposition de l ASIP santé est d approfondir : Le scénario 4 afin de permettre une prise de décision à partir d une pré-étude plus complète en évaluant notamment les risques projet. ce scénario sera présenté en détail dans le chapitre 4 qui suit ; Le scénario 1 dans une hypothèse de repli avec une certification exigeante (améliorer l'interopérabilité sur le plan national) dans une variante prenant en compte une approche nationale sur la téléphonie et les éléments d'interopérabilité nécessaires aux fonctionnalités de reprise d'activité inter-samu. L'approfondissement de ce scénario a été développé dans l'annexe de cette étude non présente dans le document actuel. Classification : Public 58 / 119

59 4 APPROFONDISSEMENT DU SCENARIO Les fondamentaux de la solution Une application en rupture avec l existant Le scénario 4 consiste à mettre en place une solution unique et mutualisée au niveau de l exploitation, où application et téléphonie seraient disponibles pour les SAMU en mode service (approche de type «SaaS» i.e. Software-as-a-Service). Cette nouvelle application nécessite : Un nouveau socle technique et une nouvelle architecture qui n existent pas dans les solutions actuelles ; Une gestion de la téléphonie novatrice capitalisant sur l ensemble des bénéfices de la téléphonie sur IP opérée sur un Cloud privé ; Une partie informatique de régulation médicale fortement couplée avec la téléphonie qui prend une nouvelle dimension ; Une architecture centralisée qui permet d implémenter de nouveaux services comme notamment des fonctionnalités d interconnexions et de bascules entre SAMU, etc. Ces fonctionnalités devront faire l objet d un prototype ou d un pilote, car rien n a été fait dans ce domaine jusqu à présent au niveau national. Ce scénario nécessite de reconstruire totalement une application de régulation médicale, car elle a pour objectif une homogénéisation et une intégration totale avec la téléphonie. Nous aborderons les détails de cette solution pour les phases de DESIGN & BUILD, de ROLLOUT et de RUN dans le cadre des parties 4.2, 4.3 et 4.4 de ce document. Le tableau ci-dessous précise les définitions des différentes phases du cycle de vie d une solution informatique telles qu employées dans la suite de ce document Phase Définition DESIGN Rédaction des spécifications fonctionnelles générales de la solution ; Rédaction des spécifications fonctionnelles détaillées ; Définition des plans de tests fonctionnels. Mise en place de l organisation et de la gouvernance du projet BUILD Développement de l ensemble des modules constitutifs de l applicatif : Rédaction des spécifications techniques détaillées ; Développement de la solution ; Intégration ; Qualification & Recette. ROLLOUT Déploiement de l application suivant l axe fonctionnel et l axe géographique : Conduite du changement ; Communication / Formation ; Déploiement opérationnel (Initialisation, Expérimentation, Pilotes, Bascules et généralisation par vague) Classification : Public 59 / 119

60 Phase Définition RUN Support aux utilisateurs ; Maintenance applicative (corrective & préventive) ; Exploitation / Supervision / Administration. Dans la suite du chapitre, les thématiques listées ci-dessous sont abordées afin d offrir un éclairage complet sur le scénario 4 : La stratégie industrielle à mettre en place ; Une évaluation économique du programme ; Une analyse détaillée de la feuille de route à prévoir ; La maîtrise des risques et facteurs de succès Description haut niveau de la cible La solution étudiée et schématisée ci-dessous est une représentation de la cible de la solution de téléphonie et de régulation commune à tous les SAMU Centres 15 : Cette solution est composée des cinq éléments principaux suivants : Un centre d exploitation mutualisé et redondé qui héberge la solution de téléphonie et de régulation sur des ressources mutualisées. Ce centre est relié au réseau téléphonique de l opérateur qui achemine les communications depuis l extérieur ; Un réseau virtuel IP sécurisé reliant tous les SAMU Centres 15 au centre d exploitation mutualisé ; Les SAMU Centres 15 avec des équipements locaux ; Les interfaces avec les partenaires et les professionnels ; Les interfaces avec les logiciels de santé (ROR et DMP principalement). Classification : Public 60 / 119

61 Les parties suivantes sont construites suivant des «focus» sur ces cinq éléments et complétées par des «focus» sur des fonctionnalités importantes telles que la gestion de crise ou le mécanisme permettant de garantir la disponibilité de l application telle que le «backup extrême» Projection sur la cartographie fonctionnelle En préambule des prochaines sections qui approfondissent la description de la cible, le déploiement et le maintien en conditions opérationnelles, il est important de faire le point sur le fonctionnement de la solution 4. En effet, elle nécessite une nouvelle répartition des responsabilités sur la conception et l exploitation de la solution en réelle rupture avec le fonctionnement actuel. Le transfert de responsabilité sur ces sujets est important, permet aux SAMU de se concentrer sur leur cœur de métier, à savoir trouver des réponses adaptées aux problèmes médicaux urgents. La cartographie fonctionnelle présentée ci-dessous, illustre la répartition actuelle des responsabilités sur les différentes briques fonctionnelles du système. On constate que la très grande majorité de ces briques est aujourd hui gérée localement par les SAMU Centres 15 eux-mêmes, ce qui d ailleurs est la cause des disparités importantes d un SAMU à l autre notamment sur la qualité de service offerte pour les fonctionnalités considérées. La mise en œuvre de la solution 4 implique une centralisation complète des infrastructures ainsi que de la responsabilité associée à ces outils. Le schéma ci-dessous représente la cartographie fonctionnelle obtenue dans le cadre de la mise en place de la solution 4. Classification : Public 61 / 119

62 On constate que les responsabilités des composants du SI sont déléguées à une entité centrale chargée d assurer un service répondant aux besoins des SAMU, à l exception de la gouvernance stratégique relative à la conception et au pilotage de l évolution de la solution. Classification : Public 62 / 119

63 Découpage de la solution 4 par grands blocs SI Le schéma ci-contre détaille le découpage des grands blocs SI composant le système d information cible des SAMU : Lien avec le réseau téléphonique de l opérateur ; Le SI de régulation et de téléphonie ; Le réseau privé sécurisé des SAMU ; L infrastructure et les équipements propres à chaque SAMU. Par ailleurs, un bloc «pilotage» au sens large (recueil et traitement des informations, administration du système...) est commun et transverse aux précédents ainsi que les aspects supports Les grands Principes de la solution 4 Cette section liste les grands principes que doit suivre le scénario 4 afin de minimiser les risques liés à la mise en place d une solution de cette nature Capitaliser sur les compétences existantes Lors de la phase de DESIGN & BUILD, il est indispensable de s appuyer sur les compétences fonctionnelles et techniques existantes. Ces compétences doivent nourrir la construction de la solution cible pour repartir du meilleur état de l art. Sur les aspects fonctionnels : il faut valoriser l important réseau de compétences fonctionnelles qui existe au niveau du réseau des SAMU, de leurs utilisateurs de différentes solutions, notamment au sein des SAMU ayant conduit les réflexions les plus poussées sur les fonctionnements inter SAMU. Les utilisateurs de la solution doivent participer de manière active très en amont de la spécification (mise à disposition, acteurs missionnés, etc.). Sur les aspects de téléphonie : il faut s appuyer sur des spécialistes des call center dont l activité est devenue extrêmement mature au cours de la décennie Sur les aspects de logiciels de régulation médicale : il faut s appuyer sur les éditeurs du marché disposant d une très bonne expertise sur le métier de la régulation médicale. Sur les aspects de virtualisation et de solutions technologiques de type SaaS : il faut s appuyer sur les acteurs industriels spécialisés sur ce type de problématiques qui ont depuis quelques années des offres industrielles Monter en puissance progressivement Une montée en puissance progressive suivant deux axes : Axe fonctionnel : Classification : Public 63 / 119

64 Avoir un lotissement pragmatique et progressif : une version v1 qui doit prouver le bon fonctionnement du concept du couplage téléphonie application de régulation médicale et qui ne doit pas chercher à implémenter dès le début l ensemble de tous les besoins fonctionnels. En d autres termes, ne pas chercher immédiatement à faire l application qui va faire mieux que ce qui est fait à l heure actuelle ; Prévoir un atelier de production des spécifications v1 pour obtenir des spécifications fonctionnelles de qualité dans un délai de temps maîtrisé et produire une maquette de l application ; Réaliser un pilote structurant et représentatif ; Des versions successives tous les 6 mois (v2, v3, etc.) qui permettent d embrasser progressivement le périmètre fonctionnel cible ; Importance d une roadmap d évolution majeure à définir précisément ; Ce lotissement intelligent et pragmatique permet de limiter et de contrôler les risques. Axe déploiement géographique, lié au nombre de SAMU centres 15 pris en charge Une capacité au niveau de la construction de l application de pouvoir monter en puissance au niveau volume ; Pouvoir démarrer en déployant, par exemple, un petit SAMU, puis deux SAMU de différentes régions, voire ensuite les SAMU d une région entière ; De doter d un arsenal d utilitaires techniques pour la bascule des solutions existantes (outils de reprise de données, outil de fonctionnement en double, etc.). Les phases de BUILD et de RUN doivent intégrer dès le départ cette dynamique de lotissement qui permet d évoluer sur les deux axes mentionnés précédemment. Ces aspects de construction progressive conditionneront aussi fortement la feuille de route Démarrer par la construction d un prototype (ou d un pilote) Aucun acteur du marché n est en mesure de pouvoir proposer sur étagère une solution de régulation du type de la solution 4. Afin d apporter un contrôle fort sur la solution qui sera construite, il est nécessaire de passer par la construction d un prototype dont la finalité sera de valider les concepts de la solution et construire un jeu de spécifications fonctionnelles éprouvées prototypépar le réel. Ces spécifications serviront par la suite de base pour valider auprès de l industriel ou groupement d industriels qui s attacheront à concevoir et mieux construire la solution cible. Les sections stratégie industrielle, maitrise de la solution et feuille de route reviennent en détail sur l importance de la cible dans la construction d un prototype ou d un pilote Réalisation d un benchmark Afin de profiter des expériences présentant des similitudes avec le contexte des SAMU Centre 15 au niveau national ou européen, il serait intéressant de réaliser un benchmark (analyse comparative) en amont de la conception de la solution commune. Les bénéfices d une telle démarche ne sont plus à prouver et permettent de disposer de : Une analyse comparative globale, factuelle et argumentée des organismes ciblés par le benchmark Une vision des opportunités d évolution ou d amélioration possibles de la solution initialement envisagée pour les SAMU Centres 15 ; Une prévision des impacts associés sur le système d information, tant sur le SI commun que le SI local ; La liste des facteurs clés de succès pour conduire la transformation relative au scénario d évolution retenu. Classification : Public 64 / 119

65 A l issue du benchmark, les SAMU Centres 15 auront donc une vision claire de la maturité des solutions employées par des organismes dont l activité est similaire à la leur Les exigences de sécurité Prérequis Pour intégrer une démarche sécurité en amont du projet, il est nécessaire que le pilote légitime du projet soit convaincu de la valeur ajoutée qu une étude de sécurité peut apporter à un projet d une telle criticité (dimensions Santé et Urgences). Cette démarche consiste à aborder la sécurité comme une composante transverse du projet depuis la phase de conception jusqu a l exploitation de la solution. L adoption d une approche de type EBIOS peut être envisagée afin de définir les niveaux d exigences attendus et d en décliner les architectures techniques inhérentes La sécurité Les différents éléments qui composent les exigences de sécurité doivent être les suivants : Exigences de confidentialité Droits du patient : o Etudier les conditions de mise en œuvre de l accord du patient pour le stockage de données de santé dans le contexte particulier de l urgence ; o Le patient dispose d un droit d accès, de modification et de suppression de toute ou partie des informations de santé le concernant. Droit d accès aux données nominatives de santé par les professionnels de santé : o Les professionnels de santé ont l obligation d utiliser des moyens techniques suffisants (CPS obligatoire, etc.) pour accéder aux informations de santé d un patient ; o Une gestion détaillée (patient par patient) des accès aux données par les professionnels de santé est nécessaire. Hébergement des données de santé : o L hébergement des données de santé doit répondre aux exigences émises dans l agrément des hébergeurs de données de santé à caractère personnel. L ensemble des hébergeurs qui devront intervenir sur cette solution devront à la fois pour les données et pour la voix, être des hébergeurs agréés à héberger des données de santé nominative. Exigences de disponibilité Disposer d un système redondé hautement disponible capable de supporter d importantes charges d afflux téléphoniques et de données de santé, dans le contexte critique du traitement des appels d urgence médicale. Exigences d intégrité Faire en sorte que les flux de voix et les données de santé lors de leur traitement, de leur conservation ou de leur transmission, ne subissent aucune altération ou destruction volontaire ou accidentelle, et conservent un format permettant leur utilisation. Exigences de preuve (auditabilité) Classification : Public 65 / 119

66 Disposer des éléments légaux à valeur probante ; La sécurité des données de santé doit se mettre en œuvre par des actions d enregistrement des données. La gestion de la preuve est donc extrêmement liée aux capacités d enregistrement de la solution. 4.2 Principes de construction de la solution (DESIGN & BUILD) Une solution mutualisée Principes de gestion de la téléphonie et de la régulation médicale Comme mentionné plus haut, cette solution consiste à mettre en place une solution unique et mutualisée pour la gestion de la régulation médicale et de la téléphonie en mode service communément appelée «SaaS» pour Software as a Service. Dans ce mode, l application locale devient un service accessible en ligne (comme les services Google) dans une logique où l utilisateur ne paye que ce qu il consomme. Les SAMU Centres 15 accèdent de manière évolutive et flexible à de nombreux services en ligne sans avoir à gérer l infrastructure sous-jacente ; ils ne sont donc plus gérants de leurs serveurs informatiques souvent complexes. Ce mode permet aussi de s affranchir de l achat de licences en passant à un modèle d abonnement avec facturation à l usage Cela se traduit par la construction d une solution commune à tous les SAMU Centres 15 qui sera ensuite exploitée dans un centre d exploitation unique, même s il est redondé. Les appels téléphoniques et les flux d informations des partenaires seront ainsi remontés au niveau du centre d exploitation puis redistribués aux SAMU concernés par le biais d un réseau privé sécurisé. Cette centralisation permet de gérer, facilement et rapidement, la redirection (ou «reroutage») des flux destinés à un SAMU indisponible (coupure réseau ou surcharge d appels entrants) vers d autres SAMU disponibles. Avec cette solution, aucun appel destiné au 15 n est perdu en cas d avarie matérielle dans un SAMU. La centralisation des flux téléphoniques vers ce centre nodal permet une meilleure gestion des appels et ainsi des débordements de plusieurs SAMU en cas de crises majeures. Au-delà de la disponibilité, un autre des principaux avantages de cette solution est d être «full IP» (IP : Internet Protocol) sur la partie téléphonie. Cela signifie que les flux téléphoniques ne sont plus acheminés au moyen des anciennes technologies utilisées dans le réseau téléphonique commuté traditionnel, mais sont maintenant considérées comme des données transitant sur le réseau Internet au même titre que des mails, flux vidéo ou audio. Classification : Public 66 / 119

67 Cette caractéristique «full IP» des flux téléphoniques permet de profiter d un couplage téléphonie informatique (CTI) fort. En effet, les flux téléphoniques étant traités comme des flux de données Internet, il devient aisé de mettre en œuvre des applications reposant sur un inter fonctionnement entre des applications informatiques et des fonctionnalités téléphoniques. Ce couplage s inscrit dans la logique de convergence numérique et apporte à cette solution le moyen d utiliser les ressources du SI des SAMU (données de régulation par exemple) pour enrichir les fonctionnalités des centres d appels. Ces éléments seront détaillés par la suite dans un focus sur le couplage CTI. Ces nouvelles fonctionnalités évoluées permettent une meilleure prise en charge des appels par les PARM (Personnel d Aide à la Régulation Médicale) : Gestion des appels entrants évoluée (SVI, salles d attente virtuelles, etc.) ; Affichage simultané sur l écran du PARM de données (historique du patient, données DMP, etc.) ainsi que la présentation de l appel sur son poste téléphonique ; Enregistrements vocaux instantanés et consultables en quelques clics ; Forte intégration avec les systèmes partenaires ; etc. Au-delà de l amélioration de la situation unitaire de chaque SAMU, cette solution supporte aussi l amélioration des communications entre SAMU Centres 15 (lien 15-15) en reposant sur un socle et un modèle d information communs. En effet, la solution étant commune à tous les SAMU, elle accueille nativement les fonctionnalités d interconnexion permettant de s échanger facilement des données de régulation pour assurer la co-régulation en cas de besoin Administration / Pilotage de l activité opérationnelle Une cellule nationale d administration et de supervision doit être créée pour assurer les fonctions d opérations classiques (ex.: paramétrage de l application pour la prise en charge d un nouveau SAMU ou bien une cellule de crise temporaire). Cette cellule permettra aussi de piloter l activité opérationnelle des SAMU Centre 15 au moyen d outils assurant une supervision nationale de l activité. Ainsi des SAMU Centre 15 en difficulté suite à une crise locale (ex. : accident lors d un événement sportif) pourront être épaulés par un autre SAMU dont l activité est faible au moment donné. Cette cellule nationale assurera le rôle de coordinateur global de l activité en prévention des pics de surcharge et donnera la vision consolidée de l activité nationale des SAMU. D un point de vue technologique, les modules d outils informationnels et décisionnels pour faciliter le traitement des informations remontées par les systèmes pourront être utilisés. Dans chacun des SAMU, des fonctions d administration/pilotage locales seront proposées. Les fonctions d administration permettront à chaque SAMU de paramétrer son instance de l application pour répondre à ses besoins locaux. De plus, des fonctions de gestion des utilisateurs (avec profils/droits) sont mises à disposition du responsable du SAMU. Concernant l aspect pilotage, les SAMU disposeront localement des outils leur permettant de piloter localement l activité, on pourra ainsi retrouver un ensemble de dispositifs évolués comme les écrans d informations temps réels dans les salles de régulation pour tenir informés les PARM et médecins régulateurs Modèle d information et référentiels des SAMU Afin de proposer un ensemble ordonné et coordonné d informations aux SAMU Centres 15 pour améliorer la pertinence du diagnostic et l engagement de moyens, la solution commune doit accueillir les référentiels et les bases de données qui soutiennent l activité opérationnelle. Cependant la mise en place de référentiels communs nécessite, en prérequis, l élaboration d un thésaurus commun afin que tous les SAMU Centres 15 «parlent le même langage». Il est donc important avant toute chose d identifier les démarches passées ou actuelles de construction de Classification : Public 67 / 119

68 thésaurus inter SAMU pouvant concourir à la conception d un modèle de données commun indispensable pour l élaboration de la solution. On notera ainsi que des initiatives de définitions de référentiels sont déjà en cours. En effet, le GT399 s est attelé à définir les exigences de certifications qui ont permis d établir les référentiels concernant le format des données de liste de victimes, la compression des données, etc. Il est donc prévu que la solution mette à disposition l ensemble suivant de référentiels métier partagés entre tous les SAMU : Dossier de régulation médicale ; Base des patients remarquables ; Annuaire et annuaire inversé ; Données SIG ; Scénarios d aide à la régulation... Une fois la solution déployée pour tous les SAMU, les données des référentiels seront partagées par construction, cela permettra donc à chaque SAMU de prendre la main sur un dossier de régulation initié par un autre SAMU dans les limites légales autorisées. Par ailleurs, un ROR national ou interopérable doit être créé et déployé pour permettre à tout SAMU de consulter, engager et piloter les moyens d autres SAMU en situation d indisponibilité. Le ROR doit aussi permettre de consulter la disponibilité des autres ressources nécessaires à la prise en charge des patients (ex : Chambre dans un hôpital, etc.). La solution mutualisée prévoit la mise à disposition et l intégration complète d un annuaire universel inversé. Cet annuaire permet de donner instantanément un nom et une adresse, y compris pour les listes rouges, du numéro de l appelant (ce service ne fonctionne actuellement que pour les abonnées du réseau France Télécom). Dans la pratique, il arrive que l annuaire ne permette pas de localiser l appelant (notamment si l appelant n est pas abonné à Orange). Dans ce cas, le service AEROPE ( développé pour la gendarmerie nationale permet d identifier l opérateur de l appelant et ainsi de localiser l appel via l astreinte de l opérateur (délai relativement important actuellement) Réponses aux exigences de sécurité Le tableau ci-dessous reprend les différents dispositifs permettant de garantir la sécurité et répondant aux exigences définies dans la partie : Périmètre de la solution demandée Centre d exploitation (e) pour garantir la L exploitation de la solution devra être assurée par un hébergeur agréé «Hébergeur de données de santé». La procédure d agrément permet de vérifier les capacités de l hébergeur à assurer la sécurité, la protection, la conservation et la restitution des données de santé à caractère personnel. En termes techniques, le centre d exploitation fonctionnel devra être redondé géographiquement par le biais de deux centres physiques distincts pour garantir la continuité de la solution. En complément et afin de sécuriser au maximum le système, une solution de backup extrême (avec un fonctionnement en mode dégradé) sera envisagée en cas de dysfonctionnement du centre d exploitation. Classification : Public 68 / 119

69 Périmètre de la solution demandée Lien avec l opérateur SAMU Application (e) pour garantir la L interconnexion du centre d exploitation fonctionnel au réseau opérateur doit être assurée par un accès fiabilisé de niveau 3. Cela implique donc une connexion avec double adduction/pénétration. Ce dispositif permet donc une duplication totale des éléments du réseau entre le site du centre et le central de l opérateur. Les accès des SAMU au réseau privé MPLS devront eux aussi être redondés pour assurer la continuité de la liaison au centre d exploitation. Le lien primaire sera assuré par une liaison MPLS classique. Concernant le lien secondaire de backup, plusieurs solutions (plus ou moins coûteuses) peuvent être envisagées : lien DSL, 3G/4G, etc. Dans les SAMU, une attention toute particulière devra être portée sur les équipements et infrastructures locales notamment le réseau. En effet, des réseaux LAN Ethernet doublés et de catégorie 5 ou 6 semblent être des prérequis pour garantir le bon acheminement et la garantie de service des flux voix et data. La mise en place d une solution de «backup extrême» assurant le minimum vital (téléphonie) doit être envisagée en cas de panne du système commun. Concernant les exigences de confidentialité, l accès à l application devra se faire par le biais de la carte CPS du médecin régulateur ou bien par une délégation au moyen d une carte CPS déléguée Réponse aux exigences de «scalabilité» de la solution Les technologies «Cloud Computing» reposent sur les technologies de virtualisation qui permettent de faire abstraction des limites techniques/physiques imposées par la couche matérielle aussi bien en termes de puissance de calcul que de capacité de stockage. L automatisation appliquée à la virtualisation permet donc d ajuster dynamiquement les ressources informatiques aux besoins réels des SAMU Centre 15 à un instant donné et ainsi de calquer les ressources sur les besoins en temps réel. De fait, ce mode de mise à disposition de la solution est parfaitement adapté à la gestion des pics de charge notamment dans les cas de crises majeures. Il offre une sécurité et un confort jusqu alors inconnu avec les hébergeurs classiques contraints de faire soit des hypothèses hasardeuses sur les pics de charge soit de surdimensionner les infrastructures Gestion des évolutions La montée en puissance de la solution souhaitée par la feuille de route de migration des SAMU devra être étudiée au travers de la réalisation de procédures d évolutions. Habituellement, deux modes de montée en puissance se distinguent des autres : Statique : Les mises à jour sont implémentées par lot et font l objet d un processus robuste nécessitant des ressources de manière temporaire ; Dynamique : Les mises à jour sont implémentées au fil de l eau de manière transparente pour l utilisateur comme c est souvent le cas avec les applications en mode SaaS ou bien Classification : Public 69 / 119

70 dans certaines architectures de type «Service Oriented Architecture» (avec une gestion dynamique des versions des services). Dans le cas de la solution cible, des versions fonctionnelles successives seront construites et déployées progressivement sur une période de 4 à 5 ans. Après la mise en production de la version finale (répondant à l ensemble des besoins des SAMU Centre 15), les évolutions seront alors gérées dans un mode d amélioration continue. Afin de limiter les risques, une seule version de l application sera en production. Cependant, des possibilités de personnalisation de l application sur les profils utilisateurs seront possibles. Ils permettront de donner accès ou non à certaines nouvelles fonctionnalités notamment dans les phases de déploiement fonctionnel. Etant donnée l orientation «SaaS» de la solution, le mode de mise à jour privilégié est le mode dynamique. De plus, des procédures de retour en arrière dynamique («Rollback») des données devront être formalisées pour se prémunir en cas de dysfonctionnement majeur d une des versions Gestion de crises Au-delà de l activité quotidienne des SAMU, la solution doit fournir les dispositifs nécessaires permettant de faire face à une crise majeure, tel qu une vague de pandémie du virus grippe A H1N1. A l instar de ce qui avait été fait en 2009 pour l expérience SIN (système d information national) SAMU Grippe, la solution permettra nativement de gérer collectivement les crises de grandes envergures en fournissant des fonctionnalités natives de pilotage et de suivi de crises à mailles variables : Gestion nationale pour les crises majeures (ex. pandémie) ; Gestion à maille plus petite pour une coordination locale (ex. accident majeur). L intérêt de la mise en commun des ressources de régulation permet aussi de rapidement mettre en œuvre des dispositifs tels qu un référentiel des «réponses à faire» par chaque SAMU Centres 15 et par chaque cellule de crise permettant une harmonisation au niveau national des échanges avec les patients. Il pourra également être envisagé un dispositif de mise à jour automatique et nationale de l algorithme d aide à la régulation médicale avec les directives associées (de l INvS par exemple.). Par ailleurs, le caractère «SaaS» de la solution va aussi simplifier drastiquement les efforts et les temps nécessaires aux déploiements d infrastructures d appoint, car seule une connexion au réseau privé commun à tous les SAMU sera nécessaire et suffisante pour utiliser la solution. Cela facilitera donc les mises en place de : Cellule de crise dans les SAMU ou bien dans un autre lieu disposant d une connexion au réseau suffisante ; Postes médicaux avancés (PMA) lors de grandes catastrophes ou bien en marge d événements (sportifs, manifestations, etc.) connectés au reste du réseau privé commun au moyen du réseau sans fil 3G aujourd hui, LTE demain. Classification : Public 70 / 119

71 4.2.3 Lien avec l opérateur et intégration de la téléphonie Le lien entre le réseau téléphonique de l opérateur et le centre d exploitation mutualisé est un élément crucial de la solution, car il acheminera l intégralité des flux téléphoniques nationaux en provenance du réseau intelligent de l opérateur et destiné aux SAMU Centres 15. Le lien entre le réseau téléphonique intelligent de l opérateur et le centre d exploitation mutualisé est un des points critiques de la solution. En effet si ce lien devenait défaillant voir inopérant, l activité de tous les SAMU de France serait directement impactée. Le routage des flux doit être assuré par le réseau intelligent de l opérateur télécoms et non plus le réseau téléphonique commuté comme c est le cas actuellement. En effet, ce réseau évolué permet de transporter un certain nombre d informations comme, notamment, la localisation de l appelant à une maille fine : Pour les fixes : Identification de la commune de provenance de l appel ; Pour les mobiles : Identification de la BTS (antenne GSM) à laquelle le téléphone est rattaché au moment de la communication. Afin de répondre au mieux aux attentes des SAMU Centre 15 en termes de gestion de la téléphonie, il est prévu de miser sur une approche nationale de la téléphonie. En effet, la conception d un SI de gestion des appels à l échelle nationale permettrait de combler les manques suivants : Stratégie nationale de routage des appels dans les cas de crises et de débordements ; Sécurisation des infrastructures (redondance géographique, multiples accès au réseau opérateur, etc.) ; Fonctionnalités évoluées apportées par la téléphonie sur IP dans les SAMU les plus modestes (i.e. a minima les fonctionnalités classiques de call center). A la cible, nous retrouverons les grandes composantes de téléphonie présentes dans le schéma cidessus. Les blocs figurants dans le périmètre bleu sont les composants indispensables à la mise en Classification : Public 71 / 119

72 place d une gestion nationale de la téléphonie et seront donc mutualisés. A l inverse, les éléments en orange restent spécifiques à chaque SAMU et seront ainsi gérés et utilisés localement. Les rôles de chaque élément sont les suivants : Un lien sur le réseau téléphonique de l opérateur pour recevoir les appels ; Un autocommutateur IP (IPBx, softswitch) o Il assure le routage des appels entre l opérateur et le poste téléphonique destinataire en fonction : du numéro composé par l appelant ; des informations fournies l ACD et le CTI. o L IPBx permet également la diffusion de messages vocaux : Messages d attente, d information, etc. Une fonctionnalité de type ACD (Automatic Call distribution) o Elle distribue les appels à l agent le plus qualifié. La stratégie de routage s appuie sur des informations de : Qualification des appels par le SVI ; D origine géographique fournie par l opérateur ; Fournies par la fonction CTI et extraites d un système d information interne : régulation,... ou externe annuaire inversé,... o Elle permet de paramétrer un décroché automatique de l appel sans intervention de l agent ou un décroché par l agent ; o L ACD gère les appels en file d attente en fonction éventuellement de leurs priorités ; o Cet outil réoriente les appels vers une autre destination en fonction de la stratégie de routage définie en cas d indisponibilité ou de saturation d une file d attente, d un groupe d agents ou d un site. Une solution de SVI (Serveur vocal Interactif) o Elle permet la qualification de l appel en demandant à l appelant de saisir des informations sur son clavier (ou par reconnaissance vocale) ; o Le SVI permet la diffusion des messages vocaux liés aux interactions avec l appelant : messages préenregistrés en studio, enregistrés à la volée, ou générés par une fonction text-to-speech. Une solution CTI (Couplage Téléphonie Informatique) o Le CTI assure la communication entre la téléphonie et l informatique. Il permet d utiliser : Les données métier dans les stratégies de routage d appels ; Les données de la téléphonie dans l applicatif métier ou la bureautique Implémentation technique au regard des solutions Le tableau ci-dessous présente les points clés associés à chaque niveau d implémentation de la solution centrale de téléphonie : Lien avec l opérateur Autocom (IPBx, softswitch) Solution cible (mutualisée et commune) Sécurisation indispensable avec des liens arrivant sur 2 clusters géographiquement distincts pour l acheminement des flux téléphoniques nationaux (i.e. double induction/double pénétration pour le centre d exploitation réparti). Opéré dans le centre d exploitation réparti Peut accueillir en mode nominal 1200 positions, le double en pointe Classification : Public 72 / 119

73 Solution cible (mutualisée et commune) Gestion des appels (ACD, SVI) Couplage CTI Equipements des SAMU Basée sur une solution ACD/SVI du marché (progiciel ou open source) Couplage natif des fonctions de téléphonie et de régulation dans la solution Double induction/double pénétration : connexions locales doublées au niveau du site Dimensionnement 40kbits par appel pour la partie téléphonie pure Architecture de routage Une étude préalable a permis de dégager deux scénarios envisageables pour le routage des flux téléphoniques. Ces deux architectures sont détaillées dans les parties suivantes. Elles permettent de mettre en évidence les différentes possibilités de continuité d activité de la solution 4. Nous parlerons ainsi de «Backup Extrême» de la solution dans le cas ou le centre national (qui soutient le système de téléphonie et le logiciel de régulation médicale) ou l ensemble du réseau maillé des SAMU tombent en panne complète ou partielle malgré une redondance géographique des datacenters Routage national des flux téléphoniques Dans la configuration nationale, l intégralité des flux téléphoniques destinés aux SAMU de France sont acheminés par le réseau intelligent opérateur vers le centre d exploitation. Ce centre d exploitation héberge toutes les composantes pour la gestion de la téléphonie et l enregistrement des appels. Les flux servant de signalisation (messages de service indispensables à l établissement et à la gestion des communications) ainsi que les flux de communication transitent ensuite via le réseau privé pour arriver jusqu aux SAMU. Aucune infrastructure lourde n est à déployer localement dans les SAMU hormis des postes de travail, des téléphones IP et un équipement appelé Gateway (Passerelle) offrant une solution de backup extrême en cas de panne du centre national. Le schéma suivant illustre les principes associés à un routage national : Classification : Public 73 / 119

74 On observe que les flux d un appel passé au 15 sont automatiquement dirigés vers le centre national de la solution. Ce flux est traité en central au travers des outils intelligents (IPBx, ACD) de gestion d appels. Il est également enregistré directement en central. Il est ensuite transmis au SAMU concerné grâce aux informations de signalisation (localisation) contenues dans l appel et éventuellement d autres informations (disponibilité). Il est à noter que cette architecture prévoit une modification globale du routage des SAMU pour que l ensemble des appels au 15 soit routé vers le centre national. Il sera ainsi nécessaire de prendre en compte les contraintes juridiques (décret de loi actuellement en place pour conserver le routage statique des appels au 15) ainsi que les contraintes techniques et financières liées à ce routage avec l opérateur. Cependant, le passage des flux téléphoniques des SAMU sur le réseau intelligent permettra de s affranchir des contraintes techniques grâce à un routage dynamique de tous les flux sur le périmètre national. Le schéma suivant représente la configuration d un routage des flux national dans le cas ou l infrastructure locale tombait en panne. Classification : Public 74 / 119

75 Dans cette situation, le routage des appels en mode nominal étant systématique destiné au système de téléphonie central, ce cas de figure est nativement traité par cette architecture. Le flux téléphonique est remonté en central et traité par les ACD et SVI national avant d être redirigé directement vers un SAMU voisin opérationnel. Le choix d une redirection vers un SAMU sera préalablement défini dans les paramétrages de l ACD (avec des critères de charge des opérateurs et de situation géographique). Le SAMU qui récupère l appel est donc en mesure d accéder aux informations du patient et aux ressources disponibles dans le département du SAMU en panne. Cette situation de panne est sans incidence pour le patient en situation d urgence : l appel abouti et est traité par un SAMU en capacité d engager des moyens locaux. Il existe cependant un deuxième cas de figure dans la situation ou le SAMU national venait à être en panne. Il s agit alors d un fonctionnement en mode backup extrême. Le schéma suivant illustre ce scénario : Classification : Public 75 / 119

76 Dans ce cas de figure, les flux doivent être dirigé au niveau local et ne pas passer pas l infrastructure centralisée. Ils sont ainsi re-routé depuis la source vers les SAMU départementaux. Les appels peuvent alors être traités directement dans les SAMU grâce à l installation d une «Gateway» locale en charge de réceptionner les appels localement dans les SAMU. Cette gateway aura également pour rôle de distribuer localement les appels sur les bons postes téléphoniques au sein du SAMU (fonction de routage statique local). On peut ainsi observer que la panne complète ou partielle de l infrastructure centrale de téléphonie n impacte pas outre mesure le fonctionnement de la téléphonie. Malgré un fonctionnement dégradé avec une structure de pilotage qui ne bénéficie plus de remontée d information statistique, mais surtout l application de régulation (dans le cas du scénario 4 uniquement) qui n est ainsi plus en capacité de fonctionner (le centre national étant en panne) ce backup extrême permet cependant aux SAMU de continuer à travailler en mode dégradé. Néanmoins, cette situation de backup extrême est conditionnée par la nécessité de rediriger les appels du 15 vers les structures locales des SAMU. Il est alors très important de s assurer, dans le cadre de contrat de service très strict, que l opérateur sera en capacité de rediriger l ensemble des appels au 15 vers le centre de réception et de régulation des appels du département concerné et cela dans des délais courts : le fonctionnement dynamique du routage des réseaux intelligents devrait autoriser sans problème cette exigence, sachant que les décisions de mise en œuvre (décision de passer en backup extrême, décision de revenir en mode nominal, etc.) devront être étudiées avec soin. Classification : Public 76 / 119

77 Routage local des flux téléphoniques Dans cette configuration, les flux téléphoniques sont acheminés par département vers le SAMU le plus proche. On retrouve toujours le centre d exploitation qui héberge toutes les composantes pour la gestion de la téléphonie et l enregistrement des appels cependant les flux téléphoniques arrivent dans les SAMU au niveau d une passerelle dédiée. Cette passerelle assure la connexion au réseau opérateur et embarque une intelligence lui permettant de proposer des fonctions basiques (appel groupé sur tous les postes, sélection directe à l arrivée, etc.). Cette passerelle a pour mission nominale de router les flux de signalisation vers le centre d exploitation via le réseau privé. En revanche les flux de communication sont acheminés localement. Un duplicata du flux de communication sera renvoyé vers le centre d exploitation mutualisé pour l enregistrement des appels. Grâce aux données de signalisation contenues dans l appel, les appels sont distribués intelligemment aux opérateurs du SAMU concerné et l ensemble des conversations est enregistré pour un stockage légal des données. Classification : Public 77 / 119

78 De la même manière que pour une architecture nationale, la situation de panne d un SAMU (illustrée page suivante) nécessite la redirection des tous les appels d un SAMU vers le centre national de téléphonie. Il sera alors indispensable d analyser les conditions et la capacité de l opérateur à rediriger ces appels dans un délai représentatif des métiers des SAMU. Une fois encore, les réseaux intelligents doivent répondre efficacement à ce besoin. Une fois en central, les flux téléphoniques sont gérés par l IPBx et l ACD pour être redirigés (via le réseau maillé) vers un SAMU voisin opérationnel. Classification : Public 78 / 119

79 Comme présentée dans le cadre d un routage des flux national, cette architecture doit comporter une solution de backup extrême en cas de panne d une des briques du système central. Cette configuration offre naturellement une solution de secours en cas de défaillance du réseau privé ou du centre d exploitation, car l acheminement local des appels reste possible. Une panne de l infrastructure centrale de téléphonie aurait ainsi des conséquences très limitées sur le fonctionnement opérationnel de la solution : Perte du système de pilotage centrale (routage des appels vers un autre SAMU impossible) ; Perte du système d enregistrement des appels ; Perte de la remontée d information statistique ; Chacune de ces deux architectures offre une possibilité de backup extrême satisfaisante. Cependant, afin de prendre une orientation technique, une étude plus détaillée permettra de faire ressortir les avantages et inconvénients de chacune d elles Focus sur le couplage téléphonie informatique (CTI) Le couplage téléphonie informatique recouvre un ensemble de techniques dont le but est de mettre en œuvre des applications utilisant simultanément des données informatiques et des données téléphoniques. Le CTI permet des échanges entre l infrastructure téléphonique centralisée et le système informatique du SAMU. Il offre la possibilité d utiliser les ressources du système d information pour améliorer le service rendu aux appelants et l efficacité générale du traitement des appels entrants comme sortants. Les gains de temps générés par le CTI ne sont pas négligeables à l échelle des SAMU. En 2008, l ensemble des SAMU a décroché 31 Millions d appels (source: Rapport Mardegan). Un gain d une seconde sur chacun des appels permettrait de libérer heures de travail pour décongestionner les centres d appels et améliorer la qualité du service par une meilleure disponibilité des opérateurs. Ce chiffre peut être bien supérieur si on prend en compte les appels émis par les opérateurs pour assurer la régulation médicale Appels entrants Pour les appels entrants, il permet de présenter l appel sur le téléphone de l opérateur et d afficher simultanément sur son écran les données relatives à l appelant. Par exemple, pour un numéro de téléphone déjà identifié dans l application de régulation, le CTI peut permettre d afficher la fiche d information de l appelant : Numéro de téléphone, nom et adresse, historique des appels et des interventions. Pour un nouvel appelant, le couplage peut permettre d adresser une requête vers l opérateur télécom pour afficher le nom et l adresse de l appelant dans la mesure où l opérateur fournit ce service dans le cadre du réseau intelligent Appels sortants Le CTI est également un facteur d optimisation de l émission d appels sortants. Il permet par exemple de numéroter directement à partir d une liste de numéros ou d un numéro dans l application de régulation (sélection du numéro à l écran puis clic sur numéroter). La numérotation sur le téléphone prend en moyenne 12 secondes contre 2 secondes pour la numérotation automatique émise par le CTI soit un gain de 10 secondes par appel. Classification : Public 79 / 119

80 Synergies et spécificités avec les concepts et les outils utilisés dans les grands centres d appel La communication avec les centres d appels s appuie sur 3 fonctions : La téléphonie dont la fonction est de mettre en liaison le téléphone d un opérateur du centre d appel avec l appelant. Si la réception de l appel est gérée par l IPBx, celui-ci échange ses informations avec le CTI par un des protocoles standard ou propriétaires du constructeur (dont les plus courants sont CSTA, Tapi, jtapi...) Le serveur vocal interactif (SVI) dont la fonction est d interagir avec l appelant pour qualifier l appel par la saisie d informations par le clavier de son téléphone : «pour... Merci de taper 1,...» ; La distribution automatique d appels (ACD : Automatic Call distribution) qui gère la distribution d appels en fonction de règles de routage prédéfinies, les files d attente et les messages d information. On retrouve ces grandes fonctionnalités présentes dans la solution cible pour les SAMU, et il est certainement intéressant de s inspirer des processus et des pratiques des grands centres d appel dans le cadre de la conception, voire de la réalisation de la solution cible. À l inverse, le contexte des SAMU Centre 15 est très spécifique et plusieurs points sont à mettre en évidence dans ce contexte; L identification de l appelant (service annuaire d urgence) est traitée en central et pas par le CTI. Il est ensuite injecté dans le dossier, l appel étant tagué comme lié au dossier par un identifiant commun. Le couplage avec des services du réseau intelligent de l opérateur est aussi une caractéristique particulière, dans la mesure où ceci est peu pratiqué (voire interdit) pour les centres d appel usuels. Tout ce qui concerne la vision des appels entrants, leur routage éventuel, leur prise en compte ne peut se satisfaire des algorithmes standards et classiques des solutions «pré-cablées» pour les centres d appels : la nature du contexte et la connaissance intime du métier permettent d imaginer des processus vraiment adaptés au métier et aux contraintes des SAMU. À titre d exemple : Classification : Public 80 / 119

81 le terme ACD est peu approprié comme mécanisme générique et simple, car les règles de distribution d appels doivent être finement définies et tenir compte des caractères de l appel, de la charge de travail et des interactions avec les agents du centre d appel... de même la surveillance par le système les salles d attente est nécessaire pour optimiser le traitement des flux, mais pour permettre aussi le droit au remord et repêcher les appels perdus ou raccrochés (fonctionnalités inexistantes dans les logiciels de type CTI standards). Il est à ce titre très intéressant de constater que dans le cadre purement local ou même régional, la mise en place de ces fonctionnalités très spécifiques et donc coûteuses est peu envisageable à la fois pour des raisons de compétences pour en élaborer les spécifications, mais également pour des raisons budgétaires. L intérêt du scénario mutualisé décrit présentement dans la solution 4 est justement de permettre d être ambitieux sur ces sujets précis, bénéficiant d une force de frappe importante pour en spécifier les exigences et d un budget qui mutualisé devient très conséquent Interactions avec les partenaires et les logiciels de santé La solution commune assurera des interfaces unifiées pour les échanges avec les partenaires et les logiciels de santé Interfaces avec les partenaires Côté partenaires, cette unicité favorisera la rationalisation des interfaces en capitalisant notamment sur les techniques existantes : Flux téléphoniques pour la transmission d appels entre SAMU et partenaires avec les informations opérateurs inhérentes à l appelant (n de téléphone a minima) ; Flux de données permettant d échanger les informations relatives à une prise d appel fournies par les partenaires (ex. : lieux, symptômes, etc.) ; Autres flux notamment pour les liens vers des acteurs comme les ambulanciers. Des démarches de normalisation devront être entreprises avec l ensemble des partenaires afin de définir des standards et protocoles d échanges qui seront utilisés par la solution commune et l ensemble des partenaires. De la même manière qu avec les SAMU, les éléments traités dans les groupes de travail existants (tel que le GT399) devront être réutilisés Cas particulier du lien L interconnexion téléphonique et informatique entre les services d urgences est obligatoire et réglementaire. Aujourd hui, ces interconnexions sont souvent réalisées au niveau local entre les deux centres d appels départementaux (SAMU et Sapeurs pompiers). A la cible et sur le sujet des échanges de données uniquement, les systèmes des pompiers devront être interfacés avec la solution unique pour : Classification : Public 81 / 119

82 échanger les données recueillies lors de l appel au 15 ou lors du traitement de l alerte au 18 ; échanger lors de l engagement des moyens ; suivre les moyens engagés et le devenir du dossier ; connaître la disponibilité des divers moyens Interfaces avec les logiciels de santé Sur le même principe que les interfaces avec les partenaires, la solution devra aussi implémenter des interfaces avec les logiciels de santé, dont notamment le ROR, le DMP et la «Messagerie sécurisée de santé (MSS)», etc. L usage de ces logiciels de santé permettra d enrichir et de compléter le dossier d un patient au moyen du DMP, d avoir une vue sur les ressources à disposition au moyen du ROR et enfin de pouvoir échanger des données avec les SIH Urgences et les autres acteurs de santé Le réseau ANTARES La stratégie des différents ministères implique dorénavant l utilisation systématique de la solution ANTARES pour communiquer avec les unités mobiles des pompiers. Le système ANTARES (Adaptation Nationale des Transmissions Aux Risques Et aux Secours) est un réseau de radiocommunications numérique réservé à la sécurité civile. L utilisation de ce réseau va devenir obligatoire pour communiquer avec les pompiers. Dans la pratique, les SAMU communiquent aujourd hui régulièrement avec les SDIS grâce aux téléphones mobiles. À court terme, ce mode de communication ne sera plus autorisé et sera progressivement remplacé par des communications radio via le réseau ANTARES. Le fonctionnement actuel du réseau ANTARES par les SAMU est décrit dans le schéma suivant : A termes, ANTARES doit pouvoir s intégrer totalement dans le paysage de la téléphonie centralisée de la solution (réception / émission d une communication ANTARES de la même façon qu un appel téléphonique). Certain SAMU bénéficient d ores et déjà d une intégration d ANTARES avec le logiciel de régulation (notamment pour l envoi et la réception des messages courts). Afin de réduire au maximum les changements du système ANTARES, la solution cible prévoit de conserver les Gestionnaires de voies radio (GVR) actuellement en place dans les SAMU. Classification : Public 82 / 119

83 Les gestionnaires de voies radio équipent aujourd hui les SAMU et ils reçoivent l ensemble des ressources radio d une ou plusieurs organisations et les distribuent vers des postes opérateurs, et permettent d harmoniser, l exploitation des différents réseaux radio hétérogènes et d en assurer l interopérabilité. En complément du système actuel, la solution cible prévoit de traiter les informations issues des GVR dans les «Gateway» dans SAMU. Ceci permettra au même titre que pour un appel téléphonique «classique» de faire remonter les informations de signalisation et les possibilités d enregistrement vers l infrastructure centrale de la solution. Le passage des flux radio au travers des équipements intelligents de téléphonie, permettra également une intégration forte de ce flux avec le logiciel de régulation (possibilité d émettre et de recevoir des communications ANTARES directement dans l application de régulation avec les mêmes fonctionnalités que pour la téléphonie...) Le réseau de télécommunication Au-delà du réseau téléphonique de l opérateur qui achemine uniquement les flux téléphoniques jusqu au centre d exploitation, on trouve aussi dans la solution commune un réseau privé sécurisé MPLS interconnectant le centre d exploitation à l ensemble des SAMU Centre 15 et des utilisateurs nomades (SMUR, poste médical avancé) quelle que soit la technologie disponible et quel que soit l endroit où se trouvent les utilisateurs. Classification : Public 83 / 119

84 Un réseau MPLS (Multi-Protocol Label Switching) est un réseau totalement privé et «étanche» qui supporte les usages convergents apportés par le protocole IP (mais aussi d autres protocoles) et apporte la sécurité des informations transportées grâce à une architecture privée propre à chaque opérateur et séparée de celle de l Internet. Il supporte nativement des niveaux de qualité de services et de priorité des flux : data (applications standards), Temps Réel (applications critiques et/ou voix sur IP, vidéo, etc.) et Best Effort (autres usages). Ce réseau privé et redondé, dont l usage serait strictement restreint aux SAMU Centres 15, doit être proposé et exploité par un opérateur disposant d une bonne granularité sur le territoire national. En effet, cette dernière caractéristique est primordiale pour assurer le raccordement des SAMU géographiquement isolés. Les liaisons au réseau seront assurées par : des connexions haut débit redondées au niveau du centre d exploitation respectant le principe de double induction / double pénétration des connexions primaires MPLS au niveau des SAMU complétées par des connexions secondaires sur un lien ASdSL/SdSL, 4G/LTE, etc Implémentation locale dans les SAMU centres 15 Un des principaux avantages de la solution en mode SaaS est de pouvoir s affranchir des infrastructures locales (serveurs d exploitation d applications) souvent coûteuses en ressources financières et humaines. Le nombre d équipements à mettre en place dans les SAMU est donc limité à : des équipements de type «terminaux» comme des postes de travail standardisés et des téléphones IP évolués ; Un réseau local performant et sécurisé. Bien que dépourvus de serveurs d applications locaux, les membres des SAMU Centre 15 auront à leur disposition des outils de pilotage permettant la gestion de leurs utilisateurs avec vue locale des fonctions d administration de la solution centralisée. Classification : Public 84 / 119

85 4.2.8 Gestion des moyens SMUR La modernisation SI et télécoms des SAMU Centre 15 doit favoriser l intégration des moyens mobiles (SMUR) dans la chaîne d informations des Urgences. Cette intégration s opérera à deux niveaux. Au niveau de la solution commune Comme vu précédemment, le centre d exploitation commun et mutualisé accueillera un référentiel unique de tous les moyens mobiles (SMUR/SDIS) des SAMU de France. Cette mise à disposition de la liste exhaustive de toutes les ressources permettra à chaque SAMU de piloter et d affecter en temps réel ses moyens. Cette mise en commun permettra aussi aux SAMU de partager des ressources (ex.: hélicoptère) pour faire de la co-régulation ou bien prendre la main sur les moyens d un autre SAMU qui seraient indisponibles. Un système intégré de géolocalisation et de positionnement GPS devra permettre la supervision et le pilotage en temps réel de l ensemble des véhicules d intervention. Au niveau des moyens mobiles L informatisation des SMUR doit faciliter le processus métier des SMUR en permettant l initialisation, la qualification/complétion sur le lieu d intervention et le transfert de dossiers d intervention électroniques. Pour cette partie du projet, il est important de capitaliser sur les nombreuses expériences «d informatique embarquée dans les SMUR» initiées au niveau des régions. Pour cela, les véhicules devront être équipés d un système de gestion de flotte intégrant : Le positionnement GPS ; La remontée des informations de géolocalisation par le réseau mobile 3G / LTE ; Une interface permettant de remonter les statuts horaires liés au véhicule ; Les états des véhicules d intervention (ex. : présent sur le lieu, départ du lieu, etc.) ; Les statuts horaires médicaux gérés depuis le dossier SMUR embarqué par l équipe SMUR (début et fin de médicalisation) Une intégration native entre ces deux niveaux permettra d accroître le nombre et la pertinence des interactions entre équipes mobiles et fixes Grandes fonctions transverses Au-delà des différentes parties de la solution évoquées précédemment, un certain nombre de grandes fonctions transverses devront être créées afin de veiller au bon fonctionnement de l ensemble. Classification : Public 85 / 119

86 Parmi ces fonctions, on retrouve notamment la fonction «Support et formation» qui consistera à mettre en place un Helpdesk commun pour les PARM en cas de défaillance de l application ou des infrastructures qui la supportent. Pour cette partie de la solution, il conviendra de capitaliser sur les offres du marché en termes de gestion d incidents pour bénéficier rapidement des bonnes pratiques. Par ailleurs, l élaboration d un programme de formation inscrit dans un programme plus global de conduite du changement permettra d accompagner les PARM dans l appropriation du nouvel outil. Une autre fonction transverse indispensable est la fonction «administration / supervision». Pour cela il convient d identifier les opérations d administration fonctionnelle de l application (hors gestion de l infrastructure) et de gestion des habilitations applicatives (ex.: gestion des comptes utilisateurs, configuration des droits, etc.). Il conviendra aussi de définir les procédures et les informations que les outils de supervision devront remonter du système. Pour garantir le respect des exigences de qualité, de sécurité, de coûts et de délais, une démarche qualité au sens SMQ (Système de Management de la Qualité) en mode projet devra être appliquée. Cette démarche décrit un processus de gestion de la qualité et de l amélioration continue. 4.3 Principe de déploiement (ROLLOUT) Les modalités de construction (BUILD) de la solution telles que décrites précédemment permettent d envisager la manière dont son déploiement opérationnel devra être organisé. Afin de pouvoir être correctement déployée, la solution retenue devra suivre une stratégie de déploiement bien définie. Celle-ci devra : Être progressive et maîtrisée ; Répondre aux attentes des SAMU les plus volontaristes ; Être claire et largement partagée par les SAMU. L objectif de cette stratégie de déploiement est d obtenir rapidement les premières «success stories» entraînant un effet d adhésion des autres SAMU Centres Les enjeux d un déploiement géographique Nous appelons déploiement sur l axe géographique les éléments qui concernent la migration progressive des SAMU depuis leurs anciennes solutions vers la nouvelle solution unique. Quelle que soit la solution retenue, il est indispensable de disposer d une stratégie de migration progressive. En effet, une première version de la solution sera déployée à court terme dans un certain nombre de SAMU préalablement sélectionnés puis les autres SAMU viendront progressivement se raccorder au système nouvellement créé. L ordonnancement de ces SAMU pourra suivre les règles suivantes : Migration des SAMU possédant la technologie la plus ancienne et les fonctionnalités les plus pauvres en priorité ; Migration des SAMU sur la base du volontariat (a minima lors des premières phases de migration). Le succès du déploiement géographique des SAMU doit être conditionné par les éléments suivants : Le déploiement doit comporter plusieurs vagues de migration ; Les périmètres de migration doivent être réduits à un nombre identifié, restreint de SAMU pour les premières vagues, quitte à monter en puissance progressivement ; Chaque vague de migration devra comporter une phase de pilote technique et de pilote fonctionnel de la solution. Cela permettra de valider l ensemble des pré-requis Classification : Public 86 / 119

87 techniques et fonctionnels. Cette phase pilote devra donner lieu aux recettes correspondantes. Le changement d environnement de travail étant majeur pour les populations concernées, il est nécessaire de mettre en place une conduite du changement adéquate ; A chaque nouveau raccordement à la nouvelle solution, les équipes de déploiement devront anticiper et supprimer toutes perturbations liées à l intégration d un nouveau SAMU dans la solution. Les SAMU déjà raccordés ne doivent en aucun cas subir une régression fonctionnelle ou de performance du service délivré. Il est également à noter que la stratégie industrielle choisie pourra s apparenter à un mode service (SaaS). Ce mode de fonctionnement implique un déploiement géographique et fonctionnel simplifié par le fournisseur de service (en comparaison à une exploitation de la solution en mode BUILD & RUN). La mise en disposition du service via une interface web ou une application virtualisée permettra de considérablement réduire l impact de la migration dans les SAMU Centres 15. Il s agit là d un point important qu il faudra porter à l attention du titulaire du futur marché Les enjeux d un déploiement fonctionnel Le déploiement fonctionnel de la solution va permettre la montée de version progressive de l application pour l enrichir en termes de fonctionnalités. La stratégie de déploiement à mettre en œuvre pourra être la suivante : démarrage à court terme par un déploiement fonctionnellement modeste (version 1) de la solution : o Cette première version est limitée au cœur de métier (téléphonie et logiciel de régulation basique) et doit permettre d améliorer la situation des SAMU les plus en difficultés aujourd hui ; o Elle doit également permettre «d éprouver» la solution en conditions réelles afin d en détecter les points d amélioration en vue de la mise en œuvre des versions suivantes. Le déploiement de nouvelles versions fonctionnelles de la solution tous les 6 mois dans le cadre de «versions» majeures. Le passage d une version x de la solution à une version x+1 devra pouvoir être effectué avec un minimum d impact sur l environnement utilisateur. Par ailleurs, nous pouvons considérer deux catégories de montée de version : les évolutions majeures et les évolutions mineures apparentées à une maintenance corrective. Il est à noter que les évolutions majeures de la solution seront traitées dans le cadre d un projet de déploiement fonctionnel comme énoncé ci-dessus. En revanche, les évolutions mineures de la solution devront être intégrées au processus de support correctif permanent. Dans le cadre d un projet d évolutions majeures, il est important de prendre en comptes les aspects suivants : Accompagnement des utilisateurs Les SAMU impactés par ces montées de version devront être informés des changements (majeurs, mineurs) au travers d une communication globale et également de supports de communication personnalisés (au niveau départemental). En complément, les équipes de déploiement et de RUN offriront aux SAMU concernés un support de formation adapté aux nouvelles fonctionnalités clés de la solution. «Retour arrière» Classification : Public 87 / 119

88 Il est important de prévoir la possibilité de faire un rollback rapide en cas de difficulté. Cela permettra de revenir à une situation stable utilisable par les SAMU. Comme expliquée précédemment, cette possibilité doit être prise en compte dès la construction de la solution, mais elle doit également s appuyer sur des processus détaillés d évolution applicative qui seront mis en œuvre dans le cadre du BUILD. Utilisation des processus La qualité des processus qui composent un projet de déploiement de release applicative est une clé de réussite importante : Mise en place d un cycle de déploiement itératif avec phase de test et pilote ; Contrôle du bon fonctionnement avant passage au RUN (intégration qualification) ; Etc. Par ailleurs, il est important de prendre en compte le décomissionnement des anciennes infrastructures. Il est courant dans un projet de migration d application et d infrastructure de voir la solution «légacy» conservée sur une longue période voir jamais supprimée. Ceci peut avoir des conséquences très graves sur le projet puisque les utilisateurs, par solution de facilité, continuent à utiliser leur système habituel sans s approprier la nouvelle solution. Ainsi, la suppression de l ancienne solution fait partie intégrante du projet de migration. Une période de cohabitation devra être préalablement définie avec le SAMU concerné (de préférence moins d un mois) puis le décomissionnement de l ancienne solution permettra de bénéficier d un système propre et moins coûteux. 4.4 Principe de fonctionnement (RUN) La solution du scénario 4 implique un mode de fonctionnement opérationnel radicalement différent du modèle actuel : Une solution unique, centralisée et mutualisée. Classification : Public 88 / 119

89 Un certain nombre d impératifs sont est à prendre en compte pour qu une telle solution puisse fonctionner au mieux : Un respect des exigences de confidentialité des données de santé (droit du patient, droit des professionnels de santé, exigence d hébergement, etc.) ; Une solution hautement disponible ; Un support utilisateurs capable de traiter avec une grande réactivité les incidents prioritaires remontés ; Un management des processus d exploitation parfaitement maîtrisé Qualité de service et management de la qualité L utilisation et le maintien de cette nouvelle solution dans des conditions optimales impliquent une gestion de la qualité et des processus très évoluée. Cela passe par : La mise en place d un système de management de la qualité (SMQ) La rédaction de toute la documentation technique et fonctionnelle Le suivi des bonnes pratiques de la gestion informatique orientée service et processus (ITIL) Mise en place d un système de management de la qualité (SMQ) La mise en place d un système de management de la qualité nécessite la définition d une politique qualité ainsi que la création des outils de suivi de cette politique. Ses objectifs sont de garantir la qualité du service rendue et d améliorer la satisfaction des utilisateurs de ce service. Cela passe nécessairement par la rédaction d un plan d assurance qualité (PAQ) applicable pendant toute la durée du projet (BUILD et RUN). Ce dernier a pour objectif de définir les dispositions nécessaires pour assurer la qualité de la solution. Le système de management de la qualité s inscrit pleinement dans des certifications qualité de type ISO Il sera donc envisagé de faire certifier le projet avec cette norme. Par ailleurs, afin de contrôler le plus efficacement et le plus régulièrement le niveau de qualité mise en œuvre dans le cadre du projet, des audits pourront être menés sur tout ou partie des processus récurrents ou des chantiers projet. Rédaction de la documentation fonctionnelle et technique Afin de supprimer les dépendances de l application et de son fonctionnement opérationnel avec les acteurs, il est indispensable de s assurer de la rédaction d une documentation précise et à jour. En effet, les étapes de DESIGN et de BUILD décrites précédemment, doivent impérativement être supportées par une documentation technique et fonctionnelle détaillée. De la même manière, les processus de support, de maintenance corrective ou d administration doivent être documentés et régulièrement mis à jour. Suivi des bonnes pratiques de gestion informatique (ITIL) ITIL est une collection de livres qui recense, synthétise et détaille les meilleures pratiques pour une direction informatique dont l objectif est d être un fournisseur de services au sein de l entreprise. L adoption des processus ITIL permet de répondre aux normes de qualité préalablement établies. La définition de contrats de niveaux de services (SLA) permet de s assurer de la fourniture d un service de qualité par le ou les différents fournisseurs de la solution. L enjeu d un SLA est double puisqu il permet de définir contractuellement la qualité du service délivré, mais également les sanctions qui seront appliquées en cas de non-respect de ces engagements. Classification : Public 89 / 119

90 Une organisation et des outils devront également être créés afin de suivre ces SLA (processus et outils de SLM). Seront ainsi associés à chaque SLA, des indicateurs de contrôle qui feront l objet d un reporting régulier et de réunions de suivi avec l entité gérante du contrat Outils d administration La mise en place d une telle solution implique le déploiement de l ensemble des outils et processus d administration qui permettent de garantir le niveau de service délivré. La solution cible devrait ainsi comporter les éléments suivants : Les outils d administration applicative ; Les outils d administration du parc informatique (postes de travail) ; Les outils d administration du réseau ; Les outils de supervision. Les outils d administration applicative Ces outils vont permettre de gérer l application au quotidien. Ils permettront notamment de créer des comptes applicatifs, des numéros de ligne ToIP associés aux comptes, de changer un affichage, de créer une redirection ou de modifier les niveaux d accès aux différentes fonctionnalités, etc. Plusieurs niveaux de responsabilités d administration applicative (niveau SAMU, niveaux utilisateurs, niveau «super-admin», etc.) peuvent également être définis. En effet, les responsables de SAMU devront pouvoir effectuer certaines tâches d administration de la solution sur le périmètre de leur SAMU. L ensemble des taches potentiellement déléguables localement doit être retiré de la responsabilité opérationnelle de l administration nationale et ceci afin de conserver l implication des SAMU. Ces éléments d administration permettront également de disposer d outils statistiques de régulation (nombre d appels, de DRM créés, etc.). Par ailleurs, l un des rôles de cette administration applicative sera de gérer le bon fonctionnement de tous les connecteurs de données avec les partenaires de santé. Ces connecteurs devront faire l objet de mises à jour et d un maintien en conditions opérationnelles. De plus, de nouveaux connecteurs pourront nécessiter des opérations spécifiques de gestion au sein des outils d administration. Les outils d administration du parc de poste de travail En fonction de la stratégie industrielle choisie, les équipements informatiques pourront être inclus dans l offre de service proposée à chaque SAMU Centres 15. Dans le cas d une offre de service complète, une gestion du parc informatique est nécessaire pour administrer l ensemble des postes de travail et éventuellement des postes téléphoniques des Centres de Réception et de Régulation d Appels. Au même titre que l administration de l application de régulation et de téléphonie, différents niveaux d administration pourront être créés afin de laisser les SAMU libres de certaines modifications. Les outils d administration réseaux Le modèle d architecture proposé pour la solution du scénario 4 implique une utilisation poussée des réseaux sur le périmètre national. Les réseaux permettent aux SAMU Centres 15 d accéder à l application centralisée. Composante indispensable du système d information, il est nécessaire de pouvoir administrer l ensemble des équipements qui composent ce réseau national. Ces outils d administration permettent ainsi d accéder aux interfaces des équipements réseaux (routeur, switch, etc.) ainsi qu au réseau opérateur lui-même. Les outils de supervision Classification : Public 90 / 119

91 Un outil de supervision permet la surveillance du bon fonctionnement de la solution dans sa globalité. Ce type d outil vient compléter les fonctionnalités énoncées précédemment des outils d administration. Il permet de surveiller techniquement les réseaux, les infrastructures (serveurs), les applications, les processus ou même certains indicateurs de niveau de service. Il fonctionne sous la forme d un système central contrôlant l activité de «sondes» préalablement installées sur l ensemble des points sensibles. Son intérêt est double puisqu il permet, d une part, d identifier rapidement la source de dysfonctionnements et d autre part d anticiper les dysfonctionnements avant qu ils n aient un impact sur l environnement utilisateur. La supervision est alors un élément important pour le respect des exigences de disponibilité du système. L utilité de tels logiciels pour une activité aussi critique que celle des SAMU est nécessaire. L ensemble des outils d administration et de supervision évoqués précédemment peut être regroupé en un seul et même logiciel (certaines solutions du marché permettant de remplir l ensemble des fonctionnalités nécessaires) Sécurité et confidentialité En complément des éléments à construire dans le BUILD, certaines règles de sécurité et de confidentialité doivent également s appliquer au RUN. On retrouve notamment : Un accès aux données de santé uniquement par les professionnels de santé de l établissement via la carte CPS (pas d accès aux données par le support, l exploitation ou la maintenance) ; Une possibilité de consultation/modification/suppression des dossiers de régulation par le patient lui-même. Ces deux éléments impliquent une construction de la solution bien spécifique, mais également la mise en place et le respect de processus de sécurité et d accès. Le droit du patient d obtenir ces informations de santé personnelles doit donc faire l objet d une procédure claire, même si elle doit être adaptée au concept d urgence Support aux utilisateurs Le support des utilisateurs d une solution informatique est crucial. Il l est encore plus dans un contexte métier comme celui des SAMU où un incident utilisateur même mineur peut avoir des conséquences très importantes. L objectif du support est d apporter aux utilisateurs un point de contact unique pour traiter tout incident ou demande qui concerne les outils informatiques ou la téléphonie. Le support devra notamment prévoir un accompagnement de proximité dans la période de transition vers la phase opérationnelle. À l issue de cette phase, le titulaire réalisera un bilan de satisfaction des utilisateurs et identifiera les axes d amélioration. La mise en service d un support efficace et compétent passe souvent par la mise en œuvre des bonnes pratiques ITIL tel que cité précédemment dans la gestion de la qualité. Classification : Public 91 / 119

92 La gestion des incidents L objectif de ce processus est de rétablir le fonctionnement nominal du service le plus rapidement possible, en minimisant la durée d interruption du service et l impact négatif sur les opérations métiers des SAMU. Les points clés de la gestion des incidents sont les suivants : Une CMDB à jour ; Une base de connaissance enregistrant les problèmes et les erreurs connues, leur résolution et les solutions de contournement ; Des outils de support efficaces ; Des liens étroits avec la gestion des niveaux de service. La gestion des incidents se traite à plusieurs niveaux : Le Helpdesk et support Niveau 1 sont principalement acteurs sur les premières activités du processus : o L agent du Helpdesk travaille afin de gérer, coordonner et résoudre l incident aussi vite que possible ; o Le groupe de support de niveau 1 travaille sur l enregistrement et la résolution d incidents bien connus, validés et référencés. Ils sont chargés de coordonner la résolution. Support Niveau 2 et 3 sont principalement acteurs sur les activités investigation, diagnostic et résolution : o Les groupes de support de niveau 2 et plus sont considérés comme des experts. Leur responsabilité principale est de fournir une analyse et un diagnostic précis des incidents qui leur sont affectés afin de rétablir le service pour leurs clients. Par ailleurs, la mise en place du support de la solution du scénario 4, devra prendre en compte le nombre de service desk, leur localisation, le nombre de support de proximité si cela est nécessaire, etc. En effet, il est possible de mettre en place un unique service desk. Cela est souvent plus efficace et moins coûteux, permettant à un nombre réduit de personnes de traiter un nombre plus important d appels. De plus, cela permet aux équipes d atteindre un niveau de compétence plus élevé puisqu elles sont familiarisées avec une fréquence d incidents plus importante. Classification : Public 92 / 119

93 En revanche, il peut être nécessaire de maintenir une certaine forme de présence «locale» appelée support de proximité, afin d assurer les demandes de support physique et matériel. Mais, si elles existent, ces équipes peuvent être gérées et déployées depuis la plateforme de support centrale. Indépendamment de la combinaison des options qui seront choisies pour construire la structure organisationnelle du support utilisateur, les membres des SAMU ne devront avoir aucun doute sur le moyen de contacter le support en cas de besoin. En effet, un unique numéro de téléphone devra être défini et largement diffusé. Il en va de même pour une adresse et une page de contact web qui devront également être uniques pour tous les SAMU Maintenance corrective En complément du rôle d assistance précédemment évoqué, la structure de «Support» aura également pour rôle de prendre en compte les modifications mineures de l application en cas d incidents répétés et de problèmes. Les enjeux d une maintenance corrective pour les SAMU sont multiples : Bénéficier d une application parfaitement fonctionnelle ; Réduire les incidents applicatifs. Il est donc nécessaire d identifier les incidents répétés sur une période donnée afin d en déterminer la cause et de «corriger» l applicatif en conséquence. Cependant, il s agit bien de maintenance corrective et non de maintenance évolutive. Cette dernière a pour rôle la prise en compte de nouvelles fonctionnalités remontées par les utilisateurs. Le projet de mise en œuvre et d exploitation de la solution du scénario 4 ne doit pas faire l objet d une maintenance évolutive. L exploitation de la solution cible du scénario 4 étant envisagée en mode SaaS (Software-as-aservice), on peut envisager que les modifications applicatives mineures (maintenance corrective) seront rendues «invisibles» aux yeux de l utilisateur. En effet, les corrections mineures ne nécessitent pas de déploiement applicatif et pourront ainsi être mises en production au fil de l eau sans perturbation du service en cours. 4.5 Stratégie industrielle proposée Eléments introductifs La stratégie industrielle et politique d achat à mettre en place doivent être optimales pour permettre: La spécification et la réalisation communes d une solution de régulation médicale et de centre d appels pour tous les SAMU Centres 15 permettant la mutualisation des investissements ; Une gestion opérationnelle mutualisée à travers une infrastructure robuste, redondée garantissant des niveaux de disponibilité élevés. Deux grandes orientations de stratégies industrielles se distinguent : Mode BUILD & RUN : o La solution est construite par un consortium d industriels pour le compte de la MOA ; o C est un mode projet de construction de la solution qui reste la propriété de la maîtrise d ouvrage (MOA) ; Classification : Public 93 / 119

94 o Au niveau du BUILD, le consortium peut être piloté par un intégrateur qui assemble les différentes filières technologiques, ou bien être directement piloté par le commanditaire qui accompagne les différents industriels ; o Au niveau du RUN, la solution peut être exploitée par un consortium ou plusieurs ; o Deux déclinaisons sont à considérer suivant que les phases BUILD et RUN sont assurées ou non par le même consortium ; o Les marchés classiques de ce type de projet sont des appels d offres d une durée de 4 ans ; o Il est importance de sécuriser l activation des clauses de réversibilité qui sont appliquées inévitablement durant la vie du système. L activation des clauses est souvent gage d amélioration de la qualité du système. Mode service (SaaS) : o La solution est accessible sous forme de service à un coût donné suivant l utilisation ; o C est l acteur industriel du marché qui prend à sa charge la construction et l exploitation de la solution et se trouve propriétaire de l application ; o La logique SaaS entraine une négociation uniquement au niveau des prix du RUN ; o La mise en place d un mode SaaS comprend des cycles d investissement importants pour l industriel qui doivent être rentabilisés par une activité assurée sur une période donnée. Les marchés d appel d offres classiques d une durée de 4 ans ne sont pas adaptés puisque trop court pour permettre au consortium d être rentable. Une extension de la durée du marché dès le début, un montage de type PPP (Partenariat public privé) ou DSP (délégation de Service Public) permettraient de présenter des engagements notamment de temps plus compatibles aux intérêts de l industriel ; o La réversibilité doit être gérée avec précautions, car si l industriel décide d arrêter son activité SaaS, le service doit pouvoir être repris par un autre acteur industriel dans des conditions satisfaisantes. Le Partenariat Public Privé (PPP) : Mode de financement par lequel une autorité publique fait appel à des prestataires privés pour financer et gérer un équipement assurant ou contribuant au service public. Le partenaire privé reçoit en contrepartie un paiement du partenaire public et/ou des usagers du service qu il gère. La Délégation de service Public (DSP) : Ensemble des contrats par lesquels une personne morale de droit public confie la gestion d un service public à un délégataire privé dont la rémunération est substantiellement liée au résultat d exploitation du service Stratégie industrielle choisie Une stratégie industrielle unique a été envisagée dans le cadre de la solution 4. Néanmoins deux variantes ont été élaborées suivant que la phase de sécurisation soit faite à l aide d un prototype ou d un pilote. La principale différence de ces deux variantes concerne les implications que cela entraine au niveau de la feuille de route avec les dates d utilisation de la solution en production par les SAMU. La stratégie industrielle choisie se décompose en deux volets : 1. La mise en place d un mode SaaS à la cible pour assurer le service auprès des SAMU dans une perspective cible dans le cadre d un montage de type PPP ou DSP afin de laisser l espace de temps nécessaire à l industriel pour rendre viable son modèle économique 2. La mise en place d un prototype ou d un pilote suivant la variante, en mode projet avant de lancer le mode SaaS afin de sécuriser la mise en œuvre du mode SaaS dans le cadre d un appel d offre standard. Classification : Public 94 / 119

95 o o o En effet, le mode SaaS ne peut être envisagé au départ, car aucun acteur du marché ne propose l offre globale attendue par les SAMU Centres 15, ni ne peut s engager à délivrer un service non parfaitement défini Le prototype ou pilote permettra de valider les grands principes de la solution et d obtenir un premier niveau de spécifications fonctionnelles, éprouvé par une implémentation opérationnelle Ces spécifications fonctionnelles seront communiquées à l acteur industriel proposant la solution en mode SaaS afin de se conformer parfaitement à ce cahier des charges. 4.6 Evaluation du modèle économique du programme Il est important de noter que les évaluations financières faites ci-dessous sont le résultat d affinages des analyses économiques faites dans le cadre du chapitre 3 dans l objectif premier de comparer les différents scénarios. Les éléments ci-dessous ne sont donc pas les budgets de la solution cible, dans les modes prototype et pilote. La phase d initialisation, qui sera présentée dans le chapitre «Feuille de route» de ce rapport, aura pour objectif de construire le budget précis du projet. Ce chapitre décline les deux politiques industrielles envisagées. Ces analyses économiques ont été construites en combinant les éléments suivants : des coûts réels déjà existants dans les SAMU par la présence de solutions ; des coûts spécifiques liés à la construction, au déploiement et l usage de l architecture technique du scénario 4. Ces coûts s appuient sur des montants déjà observés dans le cadre de projets similaires. Certains éléments de l analyse sont applicables uniquement à la maille d un SAMU et ont donc été comptabilisés autant de fois que de SAMU Centres 15. D autres coûts n apparaissent qu une seule fois pour l ensemble du territoire, ils sont ainsi intégrés dans la partie «éléments nationaux». Le montant total de la solution 4 est ainsi évalué à : Montant estimé de s4 en «Mode Prototype»: CAPEX : 27,4 M OPEX : 10,8 M Montant estimé de s4 en «Mode Pilote»: CAPEX : 27,8 M OPEX : 10,8 M Afin d avoir une meilleure visibilité sur les dépenses réelles qu un tel projet nécessitera, une estimation du «cash out» a été effectuée sur une période de 10 ans. Le cash out est la somme totale que les SAMU devront débourser pour mettre en œuvre et exploiter la nouvelle solution. Il intègre donc les CAPEX et les OPEX sur 10 ans. Afin d être le plus précis possible, un pourcentage variable des OPEX et des CAPEX existants actuellement sont également comptabilisés dans ce calcul. En raison du manque total de visibilité globale des budgets actuels des SAMU, l estimation des budgets actuels a été faite à partir des coûts réels de certains SAMU bénéficiant d une infrastructure moderne et performante Le cash out de la solution a donc été calculé en prenant en compte la montée en puissance de la solution 4 (investissements et frais récurrents) et la réduction progressive des OPEX et CAPEX des infrastructures actuelles. Classification : Public 95 / 119

96 Représentation graphique du «cash out» de la solution 4 en mode Prototype sur 10 ans Le total sur cash out sur 10 ans du scénario 4 en mode prototype est estimé à 172 M. Représentation graphique du «cash out» de la solution 4 en mode Pilote sur 10 ans Le total sur cash out sur 10 ans du scénario 4 en mode pilote est estimé à 175 M. 4.7 Feuille de route de la solution 4 Ce chapitre présente la feuille de route préconisée pour assurer la mise en œuvre de la solution 4 dans les meilleures conditions. Deux variantes de la feuille de route ont été envisagées suivant que le mode de démarrage se fasse sous la forme d un prototype ou sous la forme d un pilote. L intérêt principal de ces deux variantes est de présenter des dates de disponibilité de la solution en production pour les SAMU différentes. Avant de rentrer dans le détail de ces deux variantes de la feuille de route, une section énonce les principes structurants qui façonnent globalement la feuille de route. Classification : Public 96 / 119