Classification : Confidentiel / Non sensible interne / Non sensible public 1 / 113

Transcription

1 Classification : Confidentiel / Non sensible interne / Non sensible public 1 / 113

2 Sommaire 1 Présentation générale de la demande d information Programme SI-Samu Stratégie d achat du programme SI-Samu Objet de la demande d information Processus de gestion de la demande d information Contenu de la demande d information Modalités de réponse Traitement des réponses et suites données à la demande d information Présentation du système SI-Samu Description du système envisagé Présentation de l architecture retenue Principe d architecture de téléphonie retenu Architecture détaillée de la solution SI-Samu Rôles des opérateurs de télécommunication dans l architecture SI-Samu Principe de distribution géographique des infrastructures techniques Logique nominale d acheminement des appels Logique nominale d accès aux applicatifs Capacités d échange avec les partenaires et les logiciels de santé Focus sur les modalités d interaction entre le SI-Samu et Antarès Capacité d archivage du SI-Samu Dimensionnement technique du SI-Samu et gestion de crise Une architecture hautement disponible Les mécanismes de haute disponibilité du SI-Samu Focus sur la sécurisation de l étape de collecte Focus sur les dispositifs de sécurisation de l opérateur de service Prise en compte de la dynamique d évolution des technologies Particularités du système attendu La capacité d accueil téléphonique La gestion des modes dégradés La qualité de service Le respect des normes La réversibilité La haute disponibilité Hypothèses de dimensionnement Informations attendues par l ASIP Santé Informations sur les orientations retenues Informations sur les composants cœur du système Serveurs vocaux interactifs Besoins Principes structurants Demande d informations Fonctions de téléphonie Besoins Principes structurants...42 Classification : Public 2 / 113

3 Demande d informations Intégration des fonctions IPBX dans un domaine opérateur Besoins Demande d informations Fonctions d ACD locale ou centrale Besoins Demande d informations Conférence ou communications multi-lignes Besoins Demande d informations Service de couplage de téléphonie Besoins Demande d informations Informations sur les composants connexes au système Enregistrement des conversations téléphoniques Besoins Demande d informations Affichage et diffuseurs des informations Gestion multicanal Besoins Demande d informations Autres fonctionnalités potentielles Informations liées à l exploitation de la solution Statistiques d appels Supervision des appels Gestion des indicateurs de service Contraintes d exploitation Gestion des environnements Configuration type de production Informations transverses Références similaires Gestion des tickets d appels/communication et interaction Besoins Demande d informations Qualité de service Besoins Demande d informations Tarification Besoins Demande d informations Organisation des fournisseurs de solutions Organisation de la maintenance Approvisionnement Gestion des évolutions Prise en compte des demandes spécifiques Processus d escalade...99 Classification : Public 3 / 113

4 5 Annexes Besoin métier Cinématique de l appel et architecture Cinématique de traitement du service d accueil vocal Cinématique de traitement d un appel entrant Intégration des réseaux Radio Présentation du réseau ANTARES Les gestionnaires de voies radio Configuration des SDIS Glossaire Classification : Public 4 / 113

5 1 Présentation générale de la demande d information 1.1 Programme SI-Samu Le programme SI-Samu vise à apporter une réponse fonctionnelle et technique adaptée aux difficultés constatées ces dernières années par les Centres de Réception et de Régulation des Appels (Samu-Centre 15) et à garantir à la population une égalité d accès à des soins de qualité sur le territoire national. Cette modernisation constituera également une harmonisation et une interopérabilité à l échelle régionale et nationale des équipements de télécommunication et d information des Samu. Ainsi, l entraide entre les Samu et la coopération avec leurs partenaires seront facilitées, tant au quotidien que dans la gestion des situations exceptionnelles. En outre, ce nouveau dispositif permet de développer des travaux de recherche multicentriques sur la régulation médicale et sur les données qui en sont issues. La Ministre chargée de la santé a pris la décision de poursuivre le programme de modernisation du SI-Samu et en a fait l annonce, le 4 juin 2014, au Congrès Urgences, en soulignant notamment qu il s agissait de «permettre plus de coopération et une meilleure coordination de l ensemble des acteurs qui interviennent dans le champ des soins urgents». L amorçage du programme constitue la première étape de la phase de réalisation du SI-Samu. Cette étape qui a démarré en septembre 2014 est prévue pour durer 18 mois. Elle répond aux objectifs suivants : Mise en place de l organisation et de la gouvernance du programme ; Constitution de l équipe de projet SI-Samu, avec le recrutement d expertises spécifiques ; Lancement des procédures de marchés publics requises ; Démarrage des travaux d expression détaillée du besoin métier. L étude de faisabilité, finalisée en 2014 et disponible sur le site esante.gouv.fr 1, détaille les enjeux et orientations de ce programme de modernisation SI-Samu. 1.2 Stratégie d achat du programme SI-Samu Comme présenté par l ASIP Santé organisme en charge de la maîtrise d ouvrage opérationnelle du programme SI-Samu lors de la session d information tenue le 27 janvier 2015 à la maison de la Chimie, la stratégie d achat du SI-Samu (en cours de finalisation) prévoit une réalisation de ce système de télécommunication et d information mutualisé via 5 marchés distincts : M1 - Marché de collecte et de distribution des appels des Samu ; hébergement et fourniture des infrastructures télécommunications du SI-Samu (marché «Hébergement, téléphonie et distribution»). Ce marché a notamment pour objet la réalisation de prestations : o De services de télécommunication standards et hautement disponibles (y compris le SVI), avec une maîtrise de la bascule entre des architectures TDM et VoIP ; o D hébergement de l ensemble des infrastructures techniques centrales du SI- Samu ; 1 Classification : Public 5 / 113

6 M2 - Marché de développement / maintenance des applicatifs opérationnels du SI-Samu, et fourniture / exploitation des infrastructures nécessaires pour ces applicatifs (marché «Logiciels applicatifs SI-Samu»). Ce marché vise à la réalisation de la partie applicative du SI-Samu comprenant : o Un logiciel de régulation médicale (LRM) ; o Le couplage téléphonie informatique (CTI) et le bandeau téléphonique étendu ; o Le serveur vocal interactif (SVI). Le composant SVI est fourni par le marché M1 tandis que le titulaire du marché M2 est responsable des développements applicatifs relatifs au SVI ; o Des outils de cartographie ; o Des consoles d administration technique et fonctionnelle ; M3 - Marché de mise en place et de maintien du réseau SI-Samu (marché «Réseau Wan IP MPLS»). Ce marché est relatif aux prestations de services de télécommunication réseau banalisés ; M4 - Marché de développement, de maintenance et de fourniture des infrastructures du système décisionnel SI-Samu (marché «BI SI-Samu»). Ce marché a pour objet de fournir aux acteurs du programme SI-Samu des outils de pilotage et de suivi de l activité (il nécessite une stabilisation préalable du périmètre des marchés M1 et M2 et sera donc lancé dans un second temps) ; M5 - Marché de prestation d architecture, d intégration / qualification et d exploitation / support du SI-Samu (marché «Architecture, Intégration & Qualification, Exploitation & Support global). Ce marché porte sur : o Des prestations de conseil en architecture, relativement aux différentes filières techniques nécessaires à la maitrise du SI-Samu (téléphonie, réseau, radio, applications) ; o Des prestations de recette (intégration et qualification) des différents composants du SI-Samu issus des marchés M1, M2, M3 et M4 ; o La mise en place des processus d administration et la fourniture des moyens d analyse et de coordination du support et de l exploitation (technique et applicative). Les marchés M1 à M4 assurent l exploitation applicative et le support de niveau 3 des composants qu ils réalisent ou fournissent. Schématiquement, cette stratégie d achat peut être représentée de la manière suivante : Classification : Public 6 / 113

7 1.3 Objet de la demande d information En amont des différents appels d offres visant à construire le futur SI-Samu, le présent document est à destination des industriels fournisseurs de solutions liées à la téléphonie, centres d appels et écosystèmes associés, fournisseurs qui ne seront pas a priori directement destinataires des futurs appels d offres, mais dont les solutions seront proposées et incluses par les répondants à ces appels d offres. Dans ce contexte, les objectifs poursuivis par l ASIP Santé via la présente demande d information sont de : Présenter l architecture cible du SI-Samu en mode nominal ainsi qu en modes dégradés, et, sur cette base, collecter auprès des industriels du marché les remarques, conseils ou propositions alternatives à même d améliorer les caractéristiques de l architecture cible du SI-Samu ; entifier la capacité des solutions et produits disponibles sur le marché à s intégrer à l architecture préconisée ; Mieux comprendre l articulation entre le choix des différents composants de l architecture du SI-Samu, notamment entre les composants de type IPBX et les composants de type CTI ; Mieux identifier la répartition possible des fonctions d intelligence de gestion des contacts entre les composants IPBX installés à un niveau central et ceux installés localement ; In fine, d accroître la capacité de l ASIP Santé à publier des marchés de réalisation du SI-Samu intégrant des spécifications conformes à l état de l art, en s appuyant sur une connaissance accrue des fournisseurs de solutions. Relativement à la stratégie d achat envisagée supra, les informations collectées via la demande d information auront pour l ASIP Santé un intérêt particulier lors de la rédaction du marché M1, relatif à la collecte et à la distribution des appels des Samu ainsi qu à l hébergement et la fourniture d infrastructures pour le SI-Samu et lors de la rédaction du marché M2, portant sur le développement et la maintenance des applicatifs opérationnels du Classification : Public 7 / 113

8 SI-Samu ainsi que la fourniture et l exploitation des infrastructures nécessaires pour ces applicatifs. 2 Processus de gestion de la demande d information 2.1 Contenu de la demande d information La demande d information est composée : Du présent document, celui-ci visant à : o Présenter le contexte général du programme SI-Samu et les modalités de gestion de la demande d information ; o Sensibiliser les répondants au caractère vital de la solution mise en œuvre, avec un focus sur la haute disponibilité demandée ; o Permettre une meilleure connaissance des répondants ; o Préciser le contexte technique de mise en œuvre du SI-Samu, selon une approche thématique (SVI, CTI, etc.) et exposer, sur cette base, les interrogations de l ASIP Santé ; o Obtenir du marché un regard critique sur les orientations prises par l ASIP Santé ; o Préciser les questionnements transverses aux composants techniques mis en œuvre (tarification, gestion de la qualité de service, etc.) ; D un cadre de réponse, reprenant l ensemble des questions posées via le présent document et permettant aux répondants de structurer leur réponse, chaque répondant pouvant adresser tout ou partie des questions posées dans le présent document (selon le périmètre de ses activités dans le domaine des solutions de télécommunications). La demande d information est décomposée en 19 domaines, soit : 6 domaines liés au cœur du système : o Les serveurs vocaux interactifs ; o Les fonctions de téléphonie ; o L intégration des fonctions IPBX dans un domaine opérateur ; o Les fonctions d ACD centrales ou locales ; o Les conférences ou communications multi-lignes ; o Le service de couplage téléphonie-informatique ; 4 domaines connexes au système : o L enregistrement des conversations ; o L affichage et les diffuseurs d informations ; o La gestion du multicanal ; 4 domaines liés à l exploitation du système : o Les statistiques d appels ; o La supervision des appels ; o La gestion des indicateurs de service ; o Les contraintes liées à l exploitation ; 4 domaines transverses : o Les références du fournisseur; o La gestion des tickets d appels/communication et interaction ; o La qualité de service ; o La tarification ; 1 domaine lié à l organisation du fournisseur. Classification : Public 8 / 113

9 Cette demande d information est disponible sur le site esante.gouv.fr. 2.2 Modalités de réponse La date limite de réponse à la présente demande d information est fixée au 10 avril Les répondants (équipementiers et les éditeurs souhaitant répondre à cette demande d information) sont invités à transmettre leur réponse à l ASIP Santé par mail à l adresse suivante : asip-sisamu@sante.gouv.fr : En utilisant le document «cadre de réponse» au format prévu à cet effet ; En mettant en objet du mail «Demande d Information Téléphonie et Centres d Appels». Les réponses sont attendues, de préférence, en langue française. Au vu de la typologie des questions posées, cette demande d information s adresse prioritairement aux fournisseurs et éditeurs de solution de type SVI, CTI, ACD, enregistreurs, etc. Cependant, tout répondant peut transmettre sa réponse à l ASIP Santé. En fonction de l étendue de ses propres capacités, chaque répondant est invité à répondre aux domaines thématiques le concernant. Ainsi, il est demandé à chaque répondant de bien vouloir préciser en annexe du cadre de réponse les domaines auxquels il répond. Autant que possible, chaque répondant est invité à fournir les informations pertinentes le concernant pour l ensemble des domaines transverses. Les informations fournies par les répondants sont susceptibles d être publiées par l ASIP Santé dans le cadre du lancement de ses marchés. Aussi, il est demandé à chaque répondant de bien vouloir préciser de manière expresse au sein de sa réponse les éléments protégés par un secret industriel ou commercial ou qu il juge confidentiels. Eu égard au respect et à la protection du secret industriel et commercial, l ASIP Santé s engage à ne communiquer aucun de ces éléments désignés comme tels par les répondants. Pour ce faire, chaque répondant utilise une balise de début et de fin de confidentialité au sein de sa réponse (<CONFIDENTIEL> ; </CONFIDENTIEL>). 2.3 Traitement des réponses et suites données à la demande d information L ensemble des réponses reçues dans les délais susmentionnés sera étudié par l ASIP Santé. Cette étude sera de nature à permettre à l ASIP Santé d affiner ses besoins pour le programme SI-Samu et de préciser ses exigences relatives aux futurs marchés de mise en œuvre du SI-Samu. En revanche, la présente demande d information ne constitue ni une consultation, ni un appel d offres, ni un quelconque engagement de l ASIP Santé à lancer ultérieurement une opération sur le même objet. Réciproquement, les réponses à la demande d information ne constituent pas des engagements contractuels ou précontractuels de la part de leurs auteurs, y compris pour les informations liées à la tarification des services. Enfin, aucun répondant à cette demande d information ne pourra prétendre à une rémunération ou indemnisation pour les réponses apportées. Classification : Public 9 / 113

10 3 Présentation du système SI-Samu 3.1 Description du système envisagé Présentation de l architecture retenue Principe d architecture de téléphonie retenu L architecture retenue pour le SI-Samu s appuie sur les principes fondamentaux suivants : Une centralisation de l ensemble des briques de téléphonie, centre d appel et écosystème associé dans deux datacenters nationaux ; Une interconnexion de l ensemble des CRRA et des Datacenters via un réseau WAN MPLS ; Le maintien de fonctions de téléphonie en local (Gateways au sein de chaque CRRA) ; Une gestion des flux de communication entrant/sortant : o En TDM au niveau de chaque CRRA en mode nominal ; o En IP via le WAN MPLS en mode secours ; Une architecture hautement résiliente au niveau de tous les composants du service Architecture détaillée de la solution SI-Samu Le schéma ci-dessous propose une représentation des infrastructures qui permettent de mettre en œuvre un système SI-Samu à haute disponibilité : Recours à un opérateur de collecte et à un opérateur de service. L opérateur de service offrira les fonctions de Serveur Vocal Interactif (SVI) et des fonctions de routage et distribution de type IPBX (autocommutateur). L accueil de l appel est déporté vers un opérateur de service : ceci permet d augmenter considérablement la capacité d accueil, la capacité de routage, la possibilité de modifier dynamiquement les appels, tout en conservant en nominal le fonctionnement actuel. En cas de crise sanitaire aigue cet opérateur servira d amortisseur de charge pour les CRRA, permettant la qualification des appels par des systèmes interactifs vocaux avant de présenter les appels aux Samu ou sites de crise ad hoc suivant une stratégie configurable. Classification : Public 10 / 113

11 Mise en œuvre de deux datacenters téléphoniques chez un opérateur de service (site primaire et site secondaire) : o Chacun de ces datacenters hébergera les infrastructures de routage téléphonique de type IPBX, ainsi que les applications SI-Samu ; o Chaque datacenter est en capacité de traiter la charge liée à l activité nationale des Samu. Conservation en local, au sein des Samu, de tous les matériels nécessaires à la prise d appel et à la gestion des appels en cas d incidents graves impactant les systèmes situés en amont. Les enregistreurs vocaux et les infrastructures de radiocommunication sont également maintenus dans les centres de réception et de régulation des appels. Ces principes garantissent le maintien de la capacité de prise d appel, dans le respect des obligations juridiques (enregistrement, ) en cas d indisponibilité des équipements centraux. Mutualisation du système d information afin de permettre un potentiel partage des informations. Les informations et logiciels sont hébergés au sein de deux datacenters applicatifs distincts. Les applications sont accessibles via un réseau privé sécurisé à l état de l art de type WAN IP-MPLS. Couplage téléphonie-informatique afin d assurer une remontée directe automatisée de l ensemble des informations relatives à l appel et au patient le cas échéant. L'ASIP Santé souhaite également que les dossiers de régulation médicale (DRM) soient enrichis de leurs données phoniques et plus généralement de leurs données multicanales afin de réaliser un reporting multi dimensionnel. Grâce à ce modèle d architecture, en cas de défaillance locale d un Samu pour des problèmes techniques ou d incapacité d un Samu à traiter un pic de charge lié à un évènement conjoncturel, le SI-Samu permet de basculer la charge vers un autre Samu afin de fournir au niveau de service identique aux appelants Rôles des opérateurs de télécommunication dans l architecture SI-Samu Le schéma ci-dessous propose une vue plus détaillée de l architecture retenue, et en particulier de l architecture prévue au niveau des différents opérateurs : Classification : Public 11 / 113

12 3 rôles d opérateurs de télécommunication sont identifiés dans ce schéma : Opérateurs de boucle locale : o Chaque opérateur fournit les appels émis par un tiers à l opérateur de collecte, enrichis par les données de géo-localisation. Cette partie de l acheminement de l appel ne fait pas partie du SI-Samu mais constitue le départ de l appel téléphonique par le citoyen ; Opérateurs de collecte : o L opérateur de collecte est en charge de globaliser les appels et de leur appliquer les règles de chaque PDAAU ; o L opérateur de collecte applique ensuite la stratégie de traitement unifiée en fonction de la charge globale des appels ; Opérateur de service : o Apporte des fonctionnalités avancées telles que : La prise en charge des fonctionnalités de pré-routage et de serveurs vocaux, via les serveurs frontaux SVI qui sont capables de jouer les scénarii fonctionnels d accueil vocal et de qualification de l appelant ; L hébergement des composants de routage, en particulier ceux qui doivent communiquer en voix sur IP avec les équipements opérateurs Principe de distribution géographique des infrastructures techniques Parmi les mécanismes de sécurisation mis en œuvre permettant de garantir la haute disponibilité du système, l architecture de type «cluster de haute disponibilité» permet de répartir le traitement des données et des évènements entre plusieurs infrastructures, de manière à permettre la continuité des traitements lors de la défaillance de l un des nœuds. Le schéma ci-dessous propose une représentation du cluster de haute disponibilité envisagé. Classification : Public 12 / 113

13 Deux datacenters applicatifs (site primaire et site secondaire) en redondance l un de l autre utilisés et qui sont synchronisés en quasi temps réel. o Chacun de ces datacenters héberge l ensemble des équipements du Couplage Téléphonique Informatique (CTI) et l ensemble des briques applicatives du système d information dénommé globalement Logiciel de Régulation Médicale. Concernant le serveur LRM, il sera localisé dans le datacenter ; o Chaque datacenter seul peut gérer la charge d activité nationale ; Un large réseau dédié WAN (Wide Area Network) d architecture IP MPLS (MultiProtocol Label Switching) pour offrir de la qualité de service et permettre l interconnexion de l ensemble des CRRA entre eux, avec les deux datacenters applicatifs et avec les infrastructures de l opérateur de service ; Au sein de chaque CRRA, la présence d équipement de téléphonie, d enregistrement des conversations vocales et de radiocommunication. Il s agit de gateway téléphoniques avec licence SAS (Stand Alone Survivability), de gestionnaires de voix radio (GVR) permettant l interconnexion avec Antarès, d enregistreurs des conversations vocales, d équipements réseaux et d une connexion internet. Le maintien en local d un nombre d équipements non négligeable introduit un maillage de l architecture du SI-Samu à même de garantir une robustesse forte au niveau phonie (téléphonie et radiocommunication). Les infrastructures techniques hébergées par l opérateur de service n apparaissent pas au sein de ce schéma Logique nominale d acheminement des appels L ensemble des appels est acheminé vers l opérateur de collecte, celui-ci délivrant ensuite ces appels à l opérateur de service. Il peut également être envisagé, pour les opérateurs ayant des fonctions de type routage intelligent (changement de configuration rapide au sein des réseaux), un acheminement direct entre leurs abonnés et l opérateur de service. Au sein des infrastructures SI-Samu localisées chez l opérateur de service, des échanges applicatifs sont initiés entre le service SVI, le service ACD (Automatic Call Distribution) et le service CTI (Couplage Téléphonie Informatique) pour que l intelligence centralisée de la solution détermine le routage de chaque appel. Deux cas de figure peuvent se produire : Situation standard : chaque appel est traité par le CRRA en charge de la zone géographique de provenance de l appel. Dans le cas où les T2 de ce CRRA sont défectueuses, l opérateur de service - qui aura la capacité technique nécessaire à l identification de ce problème - pourra continuer à acheminer ces appels vers ce même CRRA via le WAN central ; Situation d entraide : l appel sera envoyé vers un autre CRRA que celui géographiquement en charge de l appel (dit CRRA de référence pour l appel) pour des raisons de suractivité du CRRA de référence ou de défaillances de ses infrastructures. Chaque appel est donc acheminé par l opérateur de service au sein d un CRRA déterminé et est traité par un équipement local de téléphonie (gateway) qui assure sa conversion en téléphonie sur IP et son acheminement jusqu au poste de l agent (assistant à la régulation médicale, médecin de régulation urgentiste, ). Classification : Public 13 / 113

14 3.1.4 Logique nominale d accès aux applicatifs Les agents d un CRRA travaillent d un point de vue applicatif avec deux outils principaux : L interface graphique de téléphonie («bandeau») : il s agit d une véritable application à part entière qui offre une console de supervision de l activité globale d un CRRA et permet de visualiser la totalité des appels en cours à tout instant ; Le logiciel de régulation médicale (LRM/SIG) : il s agit de l application métier permettant de gérer le processus de prise en charge d un appel médical urgent. Ce logiciel intègre en particulier des outils de cartographie. Ces deux applications sont accessibles depuis un poste de travail équipé d un navigateur internet (ou d un autre client facilement déployable) qui accède en mode nominal aux serveurs LRM et CTI via le réseau WAN Capacités d échange avec les partenaires et les logiciels de santé Les Samu sont en interconnexion avec de nombreux partenaires (SDIS, médecine libérale, ambulanciers privés, pharmacie, forces de l ordre, ). Le SI-Samu doit aussi pouvoir s interfacer avec les logiciels de santé structurants que sont le DMP, la MSSanté ou encore le ROR. L architecture retenue vise à implémenter des échanges standardisés avec chaque type d acteurs au travers de la mise en place de connecteurs conformes aux spécifications de référence des interfaces. Ces connecteurs sont disponibles depuis les datacenters applicatifs du SI-Samu et accessibles via un canal sécurisé sur internet. Le SI-Samu respecte suivant la nature du tiers les standards en vigueur. Le schéma ci-dessous présente les quatre catégories existantes : Interfaces du DSFT-DMP Parmi les partenaires, le cas des échanges informatiques avec les SDIS (lien 15-18) est spécifique car les interfaces sont soumises aux exigences AFNOR NF «logiciels de sécurité civile». Le SI-Samu implémentera un interfaçage compatible à ces exigences. 2 *NF-399 est une marque gérée par la société INFOCERT par l intermédiaire du GT399. L ASIP Santé aura accès à l ensemble de la documentation utile pour le programme SI-Samu dans le respect des règles fixées en accord avec la société INFOCERT. Classification : Public 14 / 113

15 3.1.6 Focus sur les modalités d interaction entre le SI-Samu et Antarès En plus des communications téléphoniques, les Samu utilisent la radio pour échanger avec certains de leurs partenaires. Le programme Antares (Adaptation Nationale des Télécommunication Aux Risques Et aux Secours) s inscrit dans le cadre de ces échanges. Il vise à une interopérabilité des moyens de communication des différents services publics participant aux missions de la sécurité civile. À ce titre, il permet aux SDIS et aux Samu de communiquer via un réseau radio numérique propriétaire crypté. Selon une étude menée par la DGOS en 2013, 79% des Samu ont déployé Antares ou sont en cours de déploiement. Dans le cadre de ce déploiement, certains Samu ont choisi de s équiper de leurs propres moyens radio Antares, alors que d autres, pour des raisons essentiellement économiques, ont choisi d utiliser les moyens des SDIS. Pour les premiers, le SI-Samu permettra une intégration des appels radio de sorte qu un appel radio reçu (sur un canal surveillé par un utilisateur) puisse : Être réceptionné par un agent de régulation ; Pris en compte par les fonctions de pilotage et de supervision de l activité ; Être réécouté en différé. Antares permet également des échanges de données. Ces échanges qui doivent s effectuer conformément aux exigences AFNOR NF-399 «logiciels de sécurité civile» seront pris en compte par le SI-Samu. Pour les Samu n ayant pas déployé Antares, l architecture type proposée (cf. figure suivante) permet à un Samu d accéder à l infrastructure Antares tout en conservant la maitrise totale de ses moyens radios. Dans cette configuration, le Samu devra déployer localement : Un Gestionnaire de Voie Radio (GVR). Le GVR est l équipement permettant la gestion et l orchestration des communications radio ; Les postes opérateurs radio ; Une «Access Gate» (AG) radio nominale (l AG radio est le point d accès au réseau Antares) ; Un lien vers une AG radio de secours localisée sur un site distant (en cas de défaillance de l accès nominal, le réseau Antares peut être atteint via l AG de secours) ; Un enregistreur. Le GVR et les enregistreurs présents dans un Samu garantissent à celui-ci la maitrise de ses communications radios et de ses enregistrements. Le GVR offre également la possibilité de piloter à distance d autres postes opérateurs radio pour le compte d autres Samu. Dans le schéma présenté ci-après, le lien symbolisé entre le Samu et le SDIS permettra l accès aux données du serveur de localisation automatique des véhicules (AVL), aux données du serveur de transmission automatique des alertes (TAA) et servira aux échanges effectués dans le cadre du lien Les points notables de cette configuration sont : L indépendance des Samu par rapport au SDIS pour les communications radio ; La maitrise totale du Samu sur les réseaux radio nécessaires à son fonctionnement ; L enregistrement numérique au sein du Samu de toutes les communications radio, qu elles soient prises en charge par l AG nominale ou de secours ; La possibilité pour un Samu d utiliser les ressources radio d un autre Samu grâce à l interconnexion entre GVR. Classification : Public 15 / 113

16 SDIS Samu Site de secours Capacité d archivage du SI-Samu Le SI-Samu archive l ensemble des données qu il produit ou dont il a besoin pour fournir le service attendu (dossier de régulation médicale, enregistrements vocaux des conversations téléphoniques ou radio, données référentielles, protocoles de prises en charge, logs techniques, etc..). Parmi ces données, certaines sont par nature volumineuses, comme par exemple les enregistrements vocaux des conversations téléphoniques ou radio. De plus, certaines de ces données sont soumises à des obligations légales de conservation. D un point de vue technique, le SI-Samu prévoit la conservation pendant 10 ans de l ensemble des données qu il archive. Le dossier de régulation médicale devant être conservé 20 ans, le SI-Samu doit être en capacité de restituer ces archives à chaque établissement de santé concerné, afin que celui-ci assure l archivage de ces données pendant 10 années supplémentaires. D un point de vue technique, une interface spécifique du SI-Samu vers le SIH de chaque établissement de santé sera mise en place afin d assurer l envoi régulier de ces données archivées. Cette interface ne sera pas mise en place de manière prioritaire, puisqu utile uniquement après 10 ans d utilisation du SI-Samu Dimensionnement technique du SI-Samu et gestion de crise Le SI-Samu est dimensionné pour faire face, en mode nominal, à une volumétrie d appels simultanés supérieure de 10% au pic d appels simultanés actuellement constaté et évalué à 4300 appels simultanés au niveau national. L activité cyclique des Samu fait que ce dimensionnement permet au SI-Samu de largement faire face à l activité régulière et aux pics d activité liés à des crises locales. En cas de gestion de crise sanitaire nationale, le nombre d appels simultanés peut augmenter de manière significative pour atteindre à appels simultanés. Il n est économiquement pas possible d envisager de construire et de maintenir une infrastructure SI-Samu nominalement dimensionnée pour ces très hautes volumétries de prise d appels alors que ces capacités ne seront quasiment jamais utilisés. Classification : Public 16 / 113

17 L arrivée d une crise sanitaire majeure n est généralement pas immédiate et laisse le temps (plusieurs semaines voire mois) nécessaire au lancement de projets d infrastructure d augmentation capacitaire. En cas de crise sanitaire majeure immédiate (explosion, accidents, évènement climatique), la fonctionnalité de SVI avec la pré-qualification de l appel permettra d organiser au mieux la réponse aux appels d urgence suivant une stratégie de routage spécifique (par exemple en concentrant les appels liés à la catastrophe sur un nombre limité de CRRA, laissant les autres CRRA fonctionner normalement) Une architecture hautement disponible Les mécanismes de haute disponibilité du SI-Samu Par son activité de gestion des appels médicaux urgents, chaque Samu doit être une organisation hautement fiable (High Reliability Organisation - HRO) du point de vue de ses infrastructures physiques (par exemple avec la présence d une salle de régulation distincte de la salle de crise, etc.), du point de vue organisationnel (par exemple avec la disponibilité d une équipe formée de taille suffisante pour porter une activité 24h/24 et 7J/7, etc.) et donc également du point de vue de ses équipements techniques et informatiques. Sur ce dernier aspect, l architecture du SI-Samu assure la continuité de fonctionnement à la fois par la redondance de l ensemble de ses équipements techniques, mais également par la mise en place systématique d au moins deux modes (un mode d accès nominal, sécurisé par un ou plusieurs modes d accès alternatifs) pour l acheminement des appels téléphoniques et l accès aux applicatifs métiers. Le principal risque d une solution unique est qu en cas de défaillance de tout ou partie des équipements mutualisés, l ensemble des CRRA se retrouvent dans une incapacité d action. Pour cette raison, l architecture technique retenue a été élaborée avec comme exigence fondamentale d offrir les meilleures garanties d une disponibilité 24h/24 et 7J/7 et de permettre la continuité du service même en cas de défaillance des équipements mutualisés (destruction d un datacenter, défaillance du réseau WAN, etc.). Les mécanismes de haute disponibilité mis en place pour le SI-Samu se distinguent en six familles de dispositifs décrits ci-après : Les dispositifs de redondance matérielle et logicielle : ces dispositifs permettent de garantir que, lorsqu un composant connait une panne, un composant équivalent prend immédiatement le relais pour assurer la continuité du service à qualité constante. Ces dispositifs couvrent par conséquent un très grand nombre de pannes et se déclinent sur des cas de panne agissant à des niveaux locaux ou globaux de l architecture, comme par exemple la perte d un datacenter, la perte d un serveur applicatif ou téléphonique au sein d un datacenter, la perte d une carte de processeur, etc. o Au niveau central : Chaque datacenter SI-Samu de la solution, qu il soit applicatif chez un hébergeur ou qu il soit téléphonique chez un opérateur de télécommunication, est couplé avec un site secondaire en redondance l un de l autre à chaud (selon un mécanisme actif-passif). En cas de faillite du site primaire, le site secondaire reprend immédiatement le traitement opérationnel ; Chaque datacenter du SI-Samu, pour la tâche qui lui incombe, est dimensionné pour gérer la charge liée à l activité nationale ; Les datacenters qui sont jumelés en site primaire et site secondaire sont : Strictement équivalents en termes d infrastructures et de procédures techniques et fonctionnelles ; En synchronisation quasi temps-réel; Classification : Public 17 / 113

18 Au sein de chaque datacenter, l ensemble des équipements applicatifs et techniques présents est redondé et les mécanismes de virtualisation sont largement utilisés. o Au niveau local (dans les CRRA) : Chaque équipement qu il soit téléphonique ou réseau est redondé pour garantir une haute disponibilité : Doublement des équipements gateway téléphoniques et enregistreurs ; Classification : Public 18 / 113

19 Doublement des T2 ISDN qui acheminent les appels pour les Samu gros et moyens ; Sécurisation des T2 ISDN avec une double pénétration dès lors que l établissement de santé offre cette possibilité ; Doublement des équipements réseaux d interconnexion avec le WAN ; Sécurisation des flux voix IP en local au CRRA avec séparation des flux voix et des flux data dans des réseaux virtuels distincts (voix dans un VLAN dédié prioritaire) ; Sécurisation des enregistrements grâce aux enregistreurs positionnés devant les gateways téléphoniques ; Une répartition des responsabilités entre opérateurs de télécommunication tenant compte des logiques industrielles du secteur : o Le service critique de collecte est confié à un des opérateurs de télécommunication habilité à fournir ce type de services : le point critique de l architecture est celui de la collecte nationale des appels par un opérateur de collecte. Seuls certains opérateurs de télécommunication sont habilités à offrir ce service qui est assuré grâce des infrastructures de télécommunication de classe opérateur et exploité par les équipes techniques expertes des opérateurs de télécommunication. Suivant les accords avec les opérateurs fixes (FNO) ou mobile (MNO) ayant une boucle locale et un réseau dit «intelligent», l architecture permet d autoriser la remise directe, par ces opérateurs, des appels destinés au 15 vers l opérateur de service en charge de la gestion du numéro d appel des Samu ; o Le service de collecte intègre la détection de saturation : un service de détection de saturation des appels sera souscrit auprès de l opérateur de service afin qu il puisse déclencher des traitements automatiques en cas de saturation d appel dans un ou plusieurs CRRA, afin de rerouter ces appels vers d autres CRRA. Ce dispositif permet aussi de gérer une défaillance des T2 ISDN qui alimentent un Samu, comme par exemple la détérioration des lignes téléphoniques physiques suite à incident de type génie civil ou simplement en cas de détérioration de la qualité sonore, indispensable dans le cadre des traitements des appels d urgence. Avec l architecture proposée, la solution SI-Samu sera en capacité de détecter cette panne et de renvoyer les appels via le réseau WAN (voir la section ultérieure dédié à ce sujet) ; o L opérateur de service fournit : Les fonctions de serveur vocal interactif (SVI) : c est le premier niveau d arrivée de la pression téléphonique. En acquérant le service SVI chez un opérateur de service, le SI-Samu bénéficie d une redondance d équipements de type SVI en cluster d un niveau opérateur. Cela offre des capacités de montées en charge («scalability»), de réactivité optimale en cas de panne, tout en conservant l autonomie de gestion des Samu ; Les fonctions de routage et de gestion de la téléphonie de type IPBX : le SI-Samu bénéficie d une exploitation et d une réactivité optimale en cas de panne sur ces composants critiques de l architecture ; Classification : Public 19 / 113

20 o L architecture recherchera à homogénéiser autant que faire se peut l ensemble des équipements de téléphonie (IPBX, gateway téléphonique et téléphone) dans le respect de la gestion du bug dit «fatal». Lors de la phase de conception et de la phase de dialogue compétitif, le niveau précis d homogénéisation des équipements sera défini, prenant en compte la complexité d intégration que des équipements différents induisent, afin de faire le meilleur choix que préconisent les industriels ; o Financement de T2 ISDN, technologie mature et éprouvée pour acheminer les appels dans l ensemble des CRRA. L architecture, sans aménagement spécifique, permettra de s affranchir de certains coûts liés à la location des T2 ISDN, à la maturité des technologies et des réseaux VoIP ; Dispositifs de double acheminement des ressources téléphoniques et applicatives : o Concernant le volet voix : Par construction de l architecture, la voix arrive directement dans les CRRA sans passer par le réseau WAN avec une qualité de T2 ISDN ; En cas de panne ou de défaillance de totalité ou parties des T2 ISDN qui acheminent un appel, passage par le réseau WAN pour atteindre le CRRA destinataire, ou choix d une stratégie d entraide inter- Samu ; o Concernant le volet applicatif : L accès nominal aux applications (interface graphique de la téléphonie «bandeau» et LRM) pour les agents en CRRA se fait via protocole WEB (HTTP/HTTPS) à travers le réseau WAN qui interconnecte les CRRA avec les datacenters applicatifs ; En cas d incapacité à accéder aux logiciels des datacenters applicatifs suite à une panne du réseau WAN, l accès se fera via un accès internet sécurisé. Cet accès internet ne s active qu en situation d indisponibilité du réseau WAN ; Les dispositifs natifs de mode dégradé pour garantir le service minimum : o En cas d incapacité d accès d un CRRA aux fonctions ACD centrales (Automatic Call Distribution) et/ou au serveur CTI (par exemple suite à une chute du réseau WAN), fonctions qui contiennent l intelligence centrale de distribution des appels s appuyant sur la connaissance précise de l activité de chaque CRRA, le SI-Samu va mettre en action un mode dégradé. L arrivée des appels téléphoniques est sécurisée par l arrivée des appels via l opérateur de service (pré-décroché) et l acheminement par cet opérateur en direct dans les CRRA. Les appels sont pris en charge par les gateways téléphoniques locales qui, en cas d incapacité à joindre les serveurs ACD et CTI centraux, vont activer leur mode SAS (Stand Alone Survivability) permettant d offrir une distribution et un routage des appels via des logiques de salles d attente auprès des agents du CRRA, sans support d une interface graphique (bandeau) mais via les touches du téléphone (fonction ACD locale) ; Classification : Public 20 / 113

21 Les dispositifs de sécurisation du référentiel opérationnel des ressources (ROR) : o Une copie disponible en local dans le CRRA : les données opérationnelles des ressources vers lesquelles envoyer les patients sont indispensables à l activité de régulation médicale. Ces données sont accessibles au travers de l application LRM disponible dans les datacenters applicatifs. Afin de garantir dans tous les cas de figure l accès à ces données, celles-ci sont copiées en local dans le CRRA pour pouvoir être consultées. Le dispositif envisagé est de télédistribuer toutes les semaines les données opérationnelles de ressources du SI-Samu vers un poste de travail sanctuarisé au sein du CRRA sous forme de fichier de type PDF ou EXCEL ; o À terme, une copie des données issues du ROR : pour garantir la performance et la disponibilité des données de type ROR, l application SI- Samu fera une copie régulière de ces données en interne pour sécuriser le temps d accès à ces données critiques ; Le dispositif de «Plan de Reprise d Activité (PRA)» : o Un datacenter applicatif et téléphonique est disponible pour être rendu opérationnel dans un délai de 24h à 48h. Ce datacenter de reprise d activité doit être à même de gérer la charge d activité nationale. Une fois le datacenter PRA opérationnel, les actions pour remettre les datacenters primaires et secondaires des parties téléphoniques et applicatives pourront être relancées pour revenir à un mode nominal. Fort de l ensemble de ces mécanismes de sécurisation, l ensemble de l architecture a été travaillé sous forme de scénario primaire scénarii secondaires ou mode nominal mode secours. Les principes métiers ont été travaillés selon les mêmes principes : scénario d entraide, évènement géographique, centre de crise, crise sanitaire majeure. Ainsi, le SI-Samu sécurise l acheminement des appels suivant trois mécanismes successifs pour garantir le service. Le schéma ci-dessous présente cette logique de mode nominal (niveau 1) et les deux scénarios de sécurisation successifs (niveau 2, puis niveau 3) pour garantir la continuité du service. Classification : Public 21 / 113

22 Continuité de service en cas de défaillance des infrastructures centrales et du réseau d interconnexion De manière identique l accès des CRRA aux applicatifs en client léger suit 3 niveau de sécurisation et ce sans dégradation des fonctionnalités utilisées. En effet, en cas de défaillance du réseau WAN, les CRRA accèdent aux applications du datacenter applicatifs de manière sécurisé via un accès internet. Le troisième niveau de sécurisation consiste à faire traiter les appels par un autre CRRA, si l accès internet du CRRA en question est également défaillant. L architecture de la solution technique SI-Samu intègre dans sa conception la haute disponibilité et la capacité à augmenter son dimensionnement pour faire face à une crise sanitaire majeure. La sécurisation est apportée par un assemblage complet de dispositifs de haute disponibilité que sont principalement : la forte redondance des équipements, l existence de doubles chemins d accès aux infrastructures mutualisées, le caractère distribué du maillage local des équipements de téléphonie et les capacités novatrices d entraide natives entre les Samu. Grâce à ces dispositifs HRO, même en cas de panne des infrastructures centrales mutualisées (perte d un datacenter, perte du réseau WAN, etc.) nécessitant la survenue très peu probable de la défaillance de nombreux dispositifs de redondance des infrastructures, les CRRA peuvent continuer à assurer leur régulation médicale. Classification : Public 22 / 113

23 Focus sur la sécurisation de l étape de collecte L opérateur de l abonné effectue le transcodage du numéro 15 selon une table fixe associée à l opérateur de service, sur plusieurs numéros noirs (appelés aussi numéros géographiques) où il peut être joint. Deux logiques de livraison distinctes des appels sont appliquées suivant la nature de l opérateur de boucle locale : Pour les petits opérateurs, ils sont regroupés en plusieurs groupes et chaque groupe est pris en charge par un opérateur de collecte distinct qui assure la distribution sur les différents points de connexion de l opérateur de service ; Pour les grands opérateurs, la livraison vers l opérateur de service se fait sur plusieurs chemins différents (plusieurs points d interconnexion directe) autant au niveau lien que nœud (équipement totalement différent). Cette alternative présente aussi une capacité de répartition des appels entre plusieurs opérateurs de collecte, à des fins de sécurisation. Néanmoins, cette sécurisation est limitée car en cas de chute de la collecte d un des opérateurs, l ensemble des appels concernés par cette collecte ne seront pas acheminés. C est pourquoi, dans l ensemble des implémentations présentant des fonctions de garantie d acheminement intelligente de l appel, la distribution n est opérée que par un seul et unique opérateur de service. Classification : Public 23 / 113

24 Focus sur les dispositifs de sécurisation de l opérateur de service Présentation de l architecture du SI-Samu au niveau de l opérateur de service Le schéma ci-dessous présente un focus sur les liens entre l étage de collecte, l opérateur de service et les CRRA. Cercle jaune : distribution par les grands opérateurs et les opérateurs de collecte sur les datacenters de l opérateur de service. Pour les grands opérateurs, deux points d interconnexion minimum sont exigés par datacenter ; Cercle noir : possibilité d acheminer les appels entre datacenters par les infrastructures internes ; Cercle vert : distribution sécurisée en fonction de la géolocalisation ou selon les scénarii définis dans une optique de prise en charge la meilleure et la plus rapide Scénarios d architecture envisagés Suite à l analyse de deux scénarios : Scénario 1 : recours à un seul et unique opérateur de service ; Scénario 2 : recours à deux opérateurs de service. Le scénario 1 a été retenu. Classification : Public 24 / 113

25 Mécanismes de sécurisation natif mis en œuvre chez les opérateurs de service Des mécanismes de sécurisation très puissants sont mis en place chez les opérateurs de télécoms : L architecture propose de multiples datacenters en redondance les uns des autres et un «backbone» réseau de type MPLS / boucle SDH autorisant une rupture sans incident (changement du sens de circulation de la voix et des données) ; Les équipements de l opérateur de service sont des équipements de classe opérateur Prise en compte de la dynamique d évolution des technologies Compte tenu de l accélération du rythme de renouvellement des technologies, l architecture a été pensée en prenant en compte les différentes évolutions technologiques prévisibles dans la prochaine décennie : Le choix a été d effectuer une distribution téléphonique par les réseaux classiques RNIS éprouvés. En l état actuel de la technologie ces réseaux disposent d une meilleure robustesse à la fois en termes de fiabilité et de supervision par les opérateurs. D autre part, l utilisation de ces réseaux (RNIS) permet une conduite du changement plus aisée car elle utilise l architecture existante dans la plupart des Samu. À moyen terme, les technologies Telecom vont vers un ensemble de solutions tout IP : le choix de passer directement sur les technologies IP engendre actuellement des risques, principalement du fait d une moindre robustesse et des risques relatifs à la qualité de voix (sensation d éloignement, hachage, voix métallique). Néanmoins, il est possible d espérer une fiabilité de ces technologies à un horizon de 5 ans, les expérimentations d échange interopérateurs sur de gros volumes téléphoniques ayant commencé début L évolution de l architecture sera alors une décision économique (inversion des priorités, avec le flux téléphonique passant par le réseau privé IP WAN, secouru par les T2) et technologique (en fonction du degré de fiabilité) ; Le passage en IPV6 constitue une opportunité plus qu un risque. Les équipements réseaux commercialisés depuis trois ans disposent tous de la dualité IPV4/IPV6, voire uniquement IPV6. L IPV6 apporte principalement deux type de fonctions : des fonctions de sécurité et un plan d adressage plus large, permettant d éviter le recours à des solutions NAT (Network Translate Address, afin d effectuer des plans d adressages privés et d éviter le conflit d adresses IP). La capacité à faire évoluer les infrastructures du SI-Samu vers IPv6 est un impératif ; L architecture a été pensée en prenant en considération les cycles de persistance et de maturité des évolutions technologiques durant les 20 dernières années et les technologies émergentes. Par exemple, la voix sur IP, considérée comme un épiphénomène au début des années 2000, est vue comme incontournable depuis les années 2008 en termes d évolutions technologiques sur le LAN (Local Area Network), et comme une orientation raisonnable dans les architectures télécoms (WAN) et les offres aux entreprises depuis Les premiers retours observables dans les domaines télécoms sur des cycles de production complets permettront de faire évoluer l architecture, comme évoqué précédemment. Les cycles télécoms sont des cycles longs (premier service en reconnaissance vocale en France dans les télécoms en 2003 à base de technologie définie en 1991). Même les technologies ayant été diffusées à grande échelle dans le domaine par exemple, la base des développements pour iphone (janvier 2007) vient des outils développés pour la NeXT station en 1992 ont des cycles très longs avant d arriver à maturité. La stratégie choisie dans Classification : Public 25 / 113

26 l architecture est de faire porter les évolutions futures relatives au traitement de la voix par l opérateur de service, la gestion du multicanal par connexion avec le système de gestion centrale des centres d appels, la mobilité et la vidéo par la maîtrise des échanges IP ; La mobilité et la gestion multicanale sont deux évolutions majeures actuelles prises en compte dans le cadre du dossier. La mobilité a subi trois révolutions majeures : en 2007, premier iphone diffusant l usage des smartphones en France ; en 2010, les smartphone disposent de la puissance nécessaire pour la gestion de la vidéo ; en 2012 l apparition de la 4G en France permet une utilisation de la vidéo sans perte de qualité d information. L architecture dispose des entrées nécessaires pour intégrer ces technologies sans remise en question du système établi. La gestion multicanale (interaction par différents canaux, à la fois entrants et sortants, et de manière indifférente), n est pas à proprement parler une nouvelle technologie, mais un usage commun depuis les années 2008 (appel, confirmation par SMS ou mail, information et partage sur un portail vocal ou internet, tchat, etc.). Le degré de convergence est plus à lier à l usage du système que souhaitent les Samu, l architecture centralisée permettant un grand nombre d usages. Le premier système multicanal à grande échelle a été mis en place en France au profit de l ANPE en 2002 (sans toutefois prendre en compte la vidéo, l usage étant peu répandu et les réseaux et technologies non matures) ; Un enjeu complémentaire dans les années futures sera l assistance à distance ou la télémédecine. L assistance à distance (conseil) a été mise en place par le NHS en Angleterre sous la forme de conseil par moyen multicanal, avec comme canal principal la voix par téléphone. L assistance à distance et l aide au diagnostic vont être plus un enjeu d usages qu un enjeu technologique : les réseaux télécoms permettent de répondre à cet enjeu et les technologies, dérivées des usages domotiques, sont matures. La supervision des systèmes à distance est basée sur les réseaux IP et ne pose pas de problème d intégration technique, ni d usage. Concernant ce dernier point, l ensemble du système conçu pour les Samu est bâti sur trois principes : le premier est la connaissance à un instant t donné de la disponibilité d un ARM ou d un médecin, le second est la possibilité par un ARM de «prendre» la main sur une demande de contacts, et enfin le suivi des contacts et des dossiers. Le SI-Samu doit pouvoir être une structure d accueil pour accueillir progressivement les outils de diagnostics à distance, et même de soins, au fur et à mesure de l apparition des solutions dans ce domaine. 3.2 Particularités du système attendu Afin de faciliter la compréhension du système attendu, un focus est fait sur certains points de vigilance et particularités du système attendu que l ASIP Santé souhaite mettre en évidence. Cette liste de points n a pas pour objectif d être exhaustive : elle apporte un éclairage et précise certaines notions, afin d éviter une mauvaise interprétation des réponses attendues. Il est à noter que les attentes formulées dans le présent document ne sont pas à ce stade priorisées. Bien que l ensemble des questionnements présentés au chapitre 4 porte sur une variété très large de composants, la priorité reste axée sur les composants cœurs de système. Classification : Public 26 / 113

27 L ASIP Santé souhaite donc, dans le cadre de la demande d information ci-après, que les réponses soient adaptées au contexte décrit dans le cadre d architecture retenu présenté dans ce document et ses annexes La capacité d accueil téléphonique Une caractéristique des appels aux numéros d urgences est qu il sont à la fois prévisibles et imprévisibles : Prévisible, car de par l expérience acquise par l observation de la typologie de trafic, il est possible de déterminer les heures d affluence d appels entrants probables, ainsi que les journées chargées, et la corrélation avec des évènements saisonniers. Cette prévision permet de mettre en place un nombre d agents (ARM) en adéquation avec la demande de prise en charge, atténuant l impact sur le nombre de ports téléphoniques nécessaires pour l accueil téléphonique automatique par les Serveurs Vocaux Interactifs ; Imprévisible, du fait d évènements exceptionnels. Ces évènements peuvent se classer en trois catégories : o o o Des évènements générant une indisponibilité totale ou partielle d un CRRA (génie civil, défaillance de composants). Ce cas sera traité par la logique d entraide entre Samu. Néanmoins ces évènements diminuent le nombre d agents potentiellement disponibles pour répondre, entrainant un afflux complémentaire d appels à traiter en amont par les SVI, en aval par la prise en charge des appels par d autres CRRA. L objectif de l architecture duale TDM/IP est de diminuer encore ces cas d occurrence ; Des évènements à portée locale (par exemple explosion, accidents, évènement climatique) impactant un CRRA ou un ensemble de CRRA, mais en nombre limité. Ces évènements ont très souvent une cinétique rapide, ne permettant pas l approvisionnement en matériel et/ou logiciel pour pallier cette augmentation. L architecture prévue doit permettre à la fois la répartition de ces appels dans d autres CRRA (en utilisant notamment la possibilité de salles de crise) mais également la possibilité de «parquer» les appels en amont et faire une pré-qualification. De fait la capacité d accueil vocal doit pouvoir s étendre de manière rapide ; Des évènements à portée nationale (par exemple, une pandémie grippale). Ces évènements, souvent à cinétique lente, imposent à la fois une augmentation du nombre d agents (ARM/MR) mais également une amélioration de la pré-qualification des appels, afin d effectuer une prise en charge des appels par degré de priorité d urgence. Ces évènements augmentent également la capacité d accueil vocal. L ASIP Santé souhaite de fait ne pas être «bridée» sur le nombre de ports SVI, et de fait ne souhaite pas faire l acquisition d une architecture surdimensionnée de ports SVI pour pouvoir gérer des évènements exceptionnels. De fait la capacité SVI sera louée en mode service à un opérateur de service télécom, à qui il est envisagé de demander de proposer une architecture duale, avec certains ports SVI réservés au SI-Samu, afin de garantir une qualité de service, avec un débordement sur des architectures mutualisées, afin de gérer le caractère évènementiel. L ASIP Santé souhaite néanmoins connaître les caractéristiques des matériels effectuant le service d accueil vocal, afin de comparer les offres, l accueil vocal étant un élément prépondérant en cas d afflux d appels La gestion des modes dégradés Le SI-Samu, comme tout système informatique ou télécom, peut subir un incident imprévu endommageant la chaîne de traitement nominale des appels. L objectif est de mettre en Classification : Public 27 / 113

28 place un ensemble de moyens permettant de suppléer une panne du système nominal. Il sera désigné par mode dégradé tout modèle de fonctionnement différent du nominal, avec une classification de ces modes par risque ou sensibilité (baisse de la disponibilité moyenne) et par degré de perte de fonctionnalités. À ce titre, différents modes dégradés sont identifiés. Les principaux modes dégradés sont : Passage en mode dégradé par panne sur un composant sans défaillance de la redondance : ce type de mode dégradé est caractérisé par une absence d impact à la fois sur l appelant et sur la gestion des appels par les ARM. Il peut néanmoins avoir des conséquences, que l ASIP Santé souhaite minimiser, sur des systèmes connexes (notamment statistiques) ; Passage en mode dégradé par panne sur un composant avec défaillance de la redondance, intra ou inter-sites : ce type de mode dégradé a un impact sur la gestion des appels par les ARM/MR et sur le métier de la régulation médicale, sans impact visible pour l appelant. Une classification sera effectuée en fonction de l impact sur le métier de la régulation médicale ; Passage dans des modes dégradés de fait classifiés de mode «ultime» : la notion de distribution est faite de manière désordonnée et «basique», avec perte d efficacité des ARM/MR, seul l acheminement de l appel est garanti ; Passage dans des modes dégradés de manière volontaire (cf. premier cas), soit à des fins de maintenance, d upgrade, ou de bascule ; à l inverse du premier cas ces modes dégradés peuvent être anticipés et donc beaucoup mieux maîtrisés. Ils seront obligatoires à un moment ou un autre du cycle de production La qualité de service L ASIP Santé souhaite connaître la capacité de l offre du marché à atteindre les niveaux de SLA attendus dans le cadre du SI-Samu. Pour se faire, les répondants à la présente demande d information sont invités à fournir toute information utile relative à la qualité de service fournie par les solutions logicielles et équipements en standard (voir chapitre de la demande d information dédié à la qualité de service). L ASIP Santé, lors des consultations à venir, portera particulièrement son attention sur trois points très structurants, le SI-Samu ne pouvant être exposé à des temps de transition importants (état entre mode nominal et mode dégradé) : Le temps moyen entre deux pannes de chaque équipement ou composant logiciel (désigné aussi par les acronymes MTBF ou Mean Time Between Failure), permettant éventuellement d opérer des opérations de maintenance préventive ; La Garantie de Temps de Rétablissement (GTR). Si cet indicateur est un SLA au niveau des engagements de l opérateur économique soumissionnaire, il est important, pour l ASIP Santé, de connaître pour chaque équipement le temps de «remontée» du système (temps de reboot, de réinitialisation du composant ou de la chaîne des composants, si les composants sont interdépendants) ; La durée de bascule, pour chaque équipement ou composant, entre l élément en mode normal et l élément en mode secours. L ASIP Santé envisage par ailleurs de mettre en œuvre une supervision déportée fournie par les titulaires des marchés M1 à M4. Cette supervision doit permettre de suivre les indicateurs de qualité de service mais également de superviser les éléments fournissant ces indicateurs Le respect des normes Un point d attention sera apporté au respect des normes et de «l état de l art» lors de la conception du SI-Samu. Ce critère est lié notamment à la volonté de l ASIP Santé : De créer un «patrimoine» applicatif et plus généralement, de capitaliser au niveau des solutions mises en place ; Classification : Public 28 / 113

29 De faciliter la réversibilité du système, afin de pouvoir garantir la concurrence dans le cadre du renouvellement des marchés ; De pouvoir développer, le cas échant, des couches d abstraction permettant de changer de solutions logicielles ou matérielles dans le cadre de l évolution du SI- Samu dans les années futures. L ASIP Santé portera un regard notamment sur les points suivants : Le respect de la norme VXML pour faciliter la réversibilité sur les développements vocaux et la reprise par un tiers ; Le respect de la norme SIP (dans son intégralité, en indiquant les écarts éventuels) pour les communications téléphoniques locales au sein des Samu ; Respect de la norme définissant les interfaces entre IPBX et CTI ; La gestion des compatibilités avec certains types de téléphone / softphone ; L adhérence des solutions à des logiciels tiers, notamment en cas d intégration propriétaire La réversibilité Une réversibilité totale de la solution nominale du SI-Samu doit être garantie, y compris pour les interfaces spécifiques développées dans le cadre du SI-Samu. L ASIP Santé souhaite acquérir l ensemble des droits des développements et intégrations effectués dans le cadre du SI-Samu. De la même manière, afin d assurer la réversibilité, les répondants à la présente demande d informations sont invités à mettre en évidence : Les modalités de transfert des droits de licences vers l ASIP Santé et aux tiers mandatés par l ASIP Santé (notamment les droits d usage, les droits liés aux modifications et à la production) ; Les droits liés à des œuvres dérivées éventuelles ; L utilisation d éléments opensource au sein de la solution, en précisant la liste et l usage de ces éléments ; L utilisation de logiciel tiers, et les droits associés (Embedded OEM) ; Toute autre information permettant d assurer la réversibilité du SI-Samu, notamment dans le cadre d un renouvellement de marché public. La réversibilité n est pas abordée en tant que telle dans le cadre de la demande informations ci-après, même si certaines questions y font référence La haute disponibilité L ASIP Santé souhaite inviter les répondants à cette présente demande d informations à détailler tout élément qui permettra de mettre en évidence la haute disponibilité de l équipement ou de la solution logicielle (CTI, ACD, SVI, ) qu ils proposent en tant que tels, ainsi que les mesures souhaitables à mettre en œuvre afin de garantir cette haute disponibilité. Classification : Public 29 / 113

30 À cette fin dans ce document l ASIP Santé a souhaité : Fournir une définition claire des éléments caractérisant la haute disponibilité du système attendu pour le SI-Samu, à savoir la disponibilité, la performance, la réactivité et la résilience ; Préciser ses attentes dans le cadre du SI-Samu et demander aux répondants de compléter leurs réponses par tout élément qu ils jugeront utile à des fins de garantie de la haute disponibilité à savoir l état de l art concernant la manière de mettre en place ses produits et solutions. Disponibilité La disponibilité d un équipement ou d un système est une mesure (taux de disponibilité) faisant le rapport entre la durée totale de fonctionnement de l équipement ou du système rapportée à la durée de fonctionnement demandée. Taux Disponibilité = Durée de fonctionnement réelle Durée de fonctionnement demandée Dans le cadre des conventions de services il sera rappelé la définition exacte de chacune de ces durées : La durée de fonctionnement réelle est la période mesurée, minorée des temps de panne, des temps nécessaires à la remise en fonctionnement, et des temps de maintenance effectuée s ils engendrent une indisponibilité ; La durée de fonctionnement demandée est la période «utile au fonctionnement» du service. La particularité du SI-Samu est l absence d interruption du système. Dans le cadre du SI-Samu, la durée de fonctionnement demandée du système est 24/24 et 365j/an, à l instar des opérateurs d importance vitale. Un élément important dans la mesure est la notion de durée. La durée d observation envisagée sera le mois dans le cadre des engagements contractuel demandés, même si une observation sera faite sur la disponibilité annuelle (par segment de mesure). Cette définition est importante : les périodes de maintenance ne seront pas ôtées du calcul des taux de disponibilité (la notion de taux de disponibilité «hors maintenance» ne sera pas acceptée) sauf accord express de l ASIP Santé. Le fournisseur de solutions ou équipementier précisera les méthodes ou équipements nécessaires à la prise en compte de cette contrainte (à l instar de mécanismes de type raid/hotswap). Performance La performance d un équipement correspond, pour un ensemble de caractéristiques environnementales et de conditions d exploitation, à un indicateur ou une combinaison d indicateurs. L un de ces indicateurs est le temps de réponse constaté par rapport à un certain niveau d activité. Les temps de réponse intéressants particulièrement l ASIP Santé sont : Le temps de réponse du serveur de bandeau téléphonique, fonction du nombre d agents connectés ou à un nombre de supervisions actives ; Le délai de réponse de l ACD aux demandes de routage, en cas de flux d appels importants. Le répondant est invité à fournir toute information qu il jugera utile en annexe de sa réponse à la demande afin de préciser : Classification : Public 30 / 113

31 Les taux de performance obtenus sur les produits envisageables dans le cadre des SI-Samu ; Les conditions environnementales dans lesquelles ont été effectués ces tests. L objectif, pour l ASIP Santé, est de valider la possibilité d utiliser les produits précités au sein de la solution SI-Samu, eu égard au nombre d utilisateurs / agents concurrents. Réactivité La notion de réactivité s applique à la fois au domaine informatique et aux organisations humaines qui permettent aux moyens informatiques de fonctionner. L unité de mesure principale de la réactivité est le temps, la valeur attribuée en terme d engagement (SLA ou OLA) est fonction de l élément mesuré, et fonction de la criticité de l élément au sein du service (la criticité étant définie par l association du couple urgence-importance de gestion des risques). Afin de pouvoir caractériser le degré de réactivité nécessaire dans les processus d exploitation, l ASIP Santé souhaite avoir connaissance des logiques d interdépendance et le niveau de criticité des équipements et logiciels au sein des produits proposables par chaque répondant à la demande d information. Résilience La notion de résilience d un système informatique vient des notions de mécaniques (résistance des métaux, robustesse) et des domaines psychologiques (capacité à résister aux conditions externes et à rebondir). Chaque répondant est invité à fournir les indicateurs de résilience qu il juge utiles en annexe concernant les produits proposés, l un de ces indicateurs étant notamment le MTBF (voir ci-avant). La notion de résilience d un système est très souvent également assimilée à la capacité des systèmes à résister à «l effet du temps». Classification : Public 31 / 113

32 3.3 Hypothèses de dimensionnement Les hypothèses de dimensionnement à prendre en compte sont les suivantes : Nombre de CRRA Volumétrie d appels entrants Volumétrie d appels sortants Nombre d appels en rappel Nombre d appels de suivi de régulation Nombre d appels «Callback» Durée des appels Passage dans le SVI Nombre de postes de travail 97 CRRA en métropole et 5 CRRA dans les DOM. 31 millions d appels entrants par an en base Hypothèse d évolution annuelle du nombre d appels fixée à 2,5 %. 50% du volume total d appels entrants soit 15,5 millions d appels par an : 3% du volume total d appels entrants soit appels par an. 46% du volume total d appels entrants soit 14,3 millions d appels par an. 1% du volume total d appels entrants soit appels par an. 5 minutes (moyenne sur tous les appels entrants citoyens et professionnels). 75% des appels ne passent pas dans le SVI dynamique. Durée moyenne d un appel dans le SVI : 1 minute (qualification + attente) agents en simultané en situation normale agents en simultané en situation de crise. Par volumétrie d appels simultanés, nous considérons les volumétries de trafic d appels suivantes (appels pris par agent + appels en parcage sur le serveur vocal) : appels simultanés en mode nominal : correspond à la capacité nominale que devra supporter le système ; appels simultanés en mode nominal crise (événement à portée locale) : le système devra être dimensionné pour pouvoir résorber au moins un pic de charge de appels simultanés ; appels simultanés en mode crise (événement de portée nationale ex : H1N1,..): en cas de situation de crise de portée nationale, un projet de renforcement de l'infrastructure doit permettre d'anticiper une charge de appels simultanés. Le dimensionnement du service devra être effectué afin de supporter l ensemble du trafic. La solution devra être évolutive pour gérer un changement de volume d appels, qu il soit permanent ou ponctuel (évènementiel par exemple). Classification : Public 32 / 113

33 4 Informations attendues par l ASIP Santé Le présent chapitre, listant les demandes formulées par l ASIP Santé, est décomposé en 5 parties : Les remarques et commentaires attendus des répondants sur les orientations retenues pas l ASIP Santé telles que présentées dans ce document ; Le cœur de système, correspondant à la prise d appels : comprend la partie accueil téléphonique par service vocal interactif, la partie téléphonie, la partie routage/distribution et la partie de couplage téléphonie informatique ; Les parties connexes au système, à savoir notamment l enregistrement et la gestion multicanal ; Les fonctions d exploitation et d administration des solutions ainsi que de reporting, comprenant la gestion des statistiques, la supervision, la gestion des indicateurs, l intégration globale du système SI-Samu, les contraintes d exploitation liées à la mise en place de la solution et une description des environnements associés aux solutions ; Les domaines transverses tels que la gestion des tickets de communication, la gestion de la qualité de service, les modèles tarifaires des solutions applicables au SI-Samu. Il est à noter que les exigences à ce stade ne sont pas priorisées. Bien que l ensemble des questionnements ci-dessous portent sur une variété très large de composants, la priorité reste portée sur les composants cœurs de système. 4.1 Informations sur les orientations retenues De par leur expertise et connaissance du marché, il est demandé aux répondants de formuler un avis et l ensemble des remarques qu ils souhaitent sur les orientations retenues par l ASIP Santé pour construire les infrastructures téléphonie et centre d appel du futur SI- Samu. Classification : Public 33 / 113

34 Orientations prises par l ASIP Santé dans le cadre du SI-Samu Les informations de contexte vous semblent elles claires, pertinentes et exhaustives? Si ce n est pas le cas, de quelle manière pouvons-nous améliorer cette partie du document? Les grands choix d architecture retenus vous semblent-ils pertinents? Y a-t-il des éléments critiquables dans ces choix et le cas échéant, lesquels? Des solutions alternatives sont-elles envisageables et le cas échéant, lesquelles? COM-COMM-1 Existe-t-il à votre connaissance des grands projets similaires, où le couplage entre les applications métiers SI et la téléphonie dispose d un volet métier très contraignant et ceci dans un cadre très décentralisé, qui pourraient être cités en référence et servir d exemple à l ASIP Santé pour le futur SI-Samu? Quels sont à votre avis les facteurs de succès clefs, limités au domaine des technologies et choix de solution concernés dans cette demande d information, que l ASIP Santé doit prendre en compte impérativement pour réussir? À noter que vos remarques et réserves ne doivent pas remettre en cause les orientations et les réponses aux questions attendues dans la suite du document. 4.2 Informations sur les composants cœur du système Serveurs vocaux interactifs Besoins Service d accueil Vocal Le «Service d accueil Vocal» correspond aux services permettant la mise en œuvre d applications vocales de traitement automatique d appels comme un menu vocal, la diffusion de messages. Ce service intervient dans le cadre de la qualification de l appel qui permet de différencier les types d appelants et d identifier leurs problématiques pour permettre leur routage (ou distribution) sur le personnel Samu le plus à même à répondre au besoin de l appelant. Ces services couvrent des besoins : De qualification des appels ; D annonce vocale, par exemple pour faire une annonce spécifique lors de conditions spécifiques pour un CRRA, d une région donnée ou au niveau national ; De parcage d appels, pour gérer les appels mis en attente lorsqu aucun ARM n est disponible ; D écoute passive, pour activation de fonction par réception de signal DTMF. Ces services peuvent être activés individuellement par numéro d accès ou par CRRA sur le numéro d accès du 15 ou 112 (ou plus généralement d autres numéros via le PDAAU, le PDSA, des numéros à 10 chiffes, etc.). Certains services devront disposer d accueil (et de comportements) différents suivant à la fois le numéro d appels (médecine de garde, numéros régionaux) et la localisation géographique de l appelant. Classification : Public 34 / 113

35 Cas d usage et de fonctionnement D une manière générale, le patient appelle le 15 ou le 112 (partie principale du trafic concerné), alors qu un effecteur peut également composer un numéro entrant dédié pour entrer en relation avec le Samu. Le traitement de l appel est organisé en 4 grandes phases : Test du numéro appelé afin de permettre une première personnalisation de l accueil vocal, si nécessaire ; un premier routage intelligent intervient ici : o Dissuasion des appels malveillants ; o Dissuasion des appels non vocaux ; o Routage des appels non francophones ; o Last call agent ; o Re routage des appelants connus sur un flux spécifique. Attente et saisie d un code Pin : un code Pin peut être saisi durant le message d accueil diffusé lors du décroché. Le code Pin est fourni uniquement aux partenaires et est différent pour chaque partenaire (SDIS, Ambulances privées, SOS Médecin, Hôpital ). L'activation de cette fonctionnalité reposera sur des mécanismes paramétrables selon des critères propres au CRRA appelé, de la région ou du numéro appelé ; Orientation de l appel : o Si l appelant ne saisit pas de code Pin, il est alors orienté vers la file d attente dite «15». Si un agent est disponible alors l appel passe directement au «Routage» puis à la «Distribution» afin de mettre en relation l appelant et l agent ; o Si au contraire l appelant saisit un code Pin, il est alors orienté vers les files d attente dites «Partenaires / Professionnels» et un «SVI Professionnel». Le type d appelant sera différencié à l affichage en file d attente suivant le code Pin saisi ; Gestion de l attente : dans l hypothèse où aucun agent n est disponible, l appel est alors mis en attente sur une application vocale SVI 15-Samu spécifique. Cette application vocale peut être personnalisée en fonction du CRRA, du n appelé ou bien en fonction de scénarii événementiels préalablement activés (ex : déclenchement d un scénario de crise sanitaire comme H1N1). Dès qu un agent est disponible l appel passe directement au «Routage» puis à la «Distribution» afin de mettre en relation l appelant et l agent ; De ce principe de fonctionnement qui constitue le socle de base des services d accueil vocal du 15, quatre principales déclinaisons sont envisagées pouvant associer et mettre en œuvre de nouvelles fonctionnalités de service vocal interactif : o Parcours du patient qui appelle le 15 ou 112 (ou autres numéros pouvant être gérés par le CRRA) ; o Parcours de l effecteur qui appelle le 15 ou des n d accès dédiés ; o Parcours du professionnel via le 15 ou des n d accès dédiés ; o Parcours en cas de crise ou d événementiel activé spécifiquement, soit nationalement soit localement sur un CRRA. Classification : Public 35 / 113

36 Fonctionnalités de services vocaux interactifs Les fonctionnalités attendues de SVI du Service d Accueil Vocal sont les suivantes : Arborescence et menu vocal pour qualifier l urgence vitale de l appel afin d en définir la priorisation ; Déclenchement du scénario vocal en fonction d un calendrier ; SVI dynamique : le SVI doit pouvoir changer en fonction de la provenance (15 et Samu), permettre ainsi les entrées masquées (pour les professionnels de santé via code Pin ou par le numéro de l appelé) ; Capacité de faire un lien avec une application cliente (DRM dans notre cas) et avec un annuaire interne (savoir si le numéro de l appelant est référencé dans l annuaire interne du Samu (CHU, CTA, )) ; Masquage et activation à la demande des applications vocales SVI ; ces SVI sont utilisés par exemple pour les crises ; Personnalisation des messages d accueil et d attente par CRRA ; Gestion programmée d activation/désactivation de messages vocaux ou de menus ; Guides vocaux personnalisables et modifiables par le Samu, s appuyant entre autres sur la fonctionnalité de TTS (Text To Speech) qui permet de créer un message vocal à partir de la saisie d un texte ; Reconnaissance vocale et identification linguistique afin de connaître le besoin du client et/ou sa langue par interprétation des mots prononcés par l appelant et recueillis par l application vocale ; Détection de l humeur et donc du stress de l appelant afin de connaître son degré de panique. Cette fonctionnalité est utilisée lors de l attente de l appelant Principes structurants Pour délivrer le Service d Accueil Vocal, les principes suivants sont considérés comme structurants : Le service vocal interactif sera centralisé et hébergé côté opérateur de services : le SVI est placé au niveau de l opérateur de service de façon à centraliser l intelligence et permettre une gestion simplifiée lorsqu un Samu est coupé du réseau ou en cas de pic d activités. Ceci permet de plus une forte mutualisation des équipements et des services ; Le développement du service d accueil vocal respecte les standards d interface du marché dont en particulier «Voice XML», de façon à développer les scénarios vocaux rapidement et faciliter la portabilité et la réversibilité du service dans un autre environnement. Ce point devra être précisé, afin de permettre une capitalisation des développements ; Forte disponibilité : la fonction phonie des Samu ne peut tolérer une panne de plus de 5 minutes par an mettant en péril la téléphonie de plusieurs Samu. La solution de téléphonie doit donc avoir une disponibilité 5-9. La perte du service SVI seul n est pas considérée comme perte de disponibilité du service de téléphonie. Toutefois le SVI devient un élément critique en cas de crise car le service vocal devient le premier élément d accueil. De fait le répondant est invité à fournir tout indicateur, architecture et méthodologie garantissant à la fois la disponibilité et la résilience du SVI (voir chapitre haute disponibilité). Pour plus d informations, se référer aux annexes présentées au chapitre 5.2 pour la cinématique de l appel et l architecture et au chapitre 5.3 pour la cinématique de traitement du service d accueil vocal. Classification : Public 36 / 113

37 Demande d informations Présentation du Service d Accueil Vocal SAV-PRES-1 Pouvez-vous présenter votre service de Serveur d Accueil Vocal en mettant notamment en évidence par rapport à nos orientations ses avantages et précisant : Architecture de la solution : description générale, localisation des composants, scalability, niveau de résilience ; Technologies utilisées pour le développement ; langages, protocoles et standard supportés ; Dimensionnement : nombre maximum d appels simultanés par entité. Quelle norme/version de VXML supportez-vous? SAV-PRES-2 Préciser les protocoles et langages de développement des applications vocales, en privilégiant les normes reconnues sur le marché, en particulier : MRCP (Media Resource Control Protocol) ; SSML (Speech Synthesis Markup Language) ; PLS (Pronunciation Lexicon Specification). Si ces normes ne sont pas aujourd hui entièrement implémentées, l ASIP Santé souhaite connaître la roadmap de leur intégration, ainsi que les écarts actuels par rapport à la norme. SAV-CAPA-1 Parc et Gestion de Capacité Les Samu doivent faire face à des pics de charge dus à des crises. Il peut s'agir de crise à cinétique rapide (accident industriel type AZF) ou lente (épidémie de grippe). Le SVI est dans ce cas activé pour palier la saturation du niveau 1 (ARM) des centres 15. Pouvez-vous préciser votre capacité à provisionner X voies supplémentaires pour le SVI et le délai associé (incluant les trunks voix supplémentaires) pour : (Voir la taille des pics d appels, 5 K appels simultanés en nominal et 15K en pic) 100 voies ; 500 voies ; 1000 voies ; Multiplication de la capacité nominale par 3 (soit voies). SAV-RECO-1 Gestion de la reconnaissance vocale Quelles technologies de reconnaissance vocale employez-vous? Si ces technologies sont mises en œuvre, avec quelle technologie êtes-vous interfacé? Par mots clefs? Par mots clefs dans un flot continu? En langage naturel? Comment opérez-vous la reconnaissance de langue étrangère? Quelle technologie utilisez-vous pour lancer la reconnaissance vocale depuis une application VXML? Quelles langues reconnaissez-vous nativement? Classification : Public 37 / 113

38 Support du TTS Votre SVI VXML dispose-t-il d une solution intégrée de text-to-speech? Dans le cas contraire avec quel(s) logiciel(s) votre SVI est-il intégré? SAV-TTS-1 Avez-vous des outils et interfaces permettant aux CRRA de synthétiser une voix humaine, à partir d éléments de texte écrits? Disposez-vous d API permettant de développer un logiciel intégrant le dépôt de sons dans une arborescence, sons issus de logiciels de text-to-speech? Avez-vous la capacité à offrir un service de voix ou une base de voix sur mesure, personnalisée pour le SI-Samu? Quelle technologie utilisez-vous? SAV-INTE-1 Interconnexion avec le service de collecte des flux d appels Disposez-vous de références d intégration de vos SVI chez un opérateur de service français? Le cas échéant le(s)quel(s)? Quelles sont les contraintes d interconnexion de votre SVI avec le service de collecte opérateur? SAV-INTE-2 Intégration avec des flux externes Quelles contraintes d intégration voyez-vous avec des applications en back office du SI-Samu (Logiciel de Régulation Médicale, à comparer avec un logiciel CRM en architecture n-tiers)? Pouvez-vous préciser la capacité à appeler ces fonctions de back office depuis des documents/application VXML? SAV-INTE-3 Quelles sont vos limitations et mécanismes offerts pour transférer dans le contexte de l appel tous les champs d informations saisis ou collectés dans le SVI et les utiliser dans des appels à des fonctions de back office (ex : numéro de dossier DRM, mot de passe partenaire,.)? Pouvez-vous préciser les mécanismes offerts adaptés à notre contexte? Classification : Public 38 / 113

39 Interconnexion avec un ACD Quelles sont les contraintes d interconnexion du service SVI opéré avec un service de distribution d appels fourni par un tiers? SAV-INTE-4 SAV-INTE-5 Merci de bien vouloir préciser : Les contraintes d'interconnexion dans le cas d'un ACD associé à un IBPX ; Les contraintes d'interconnexion dans le cas d une solution ACD logicielle ; L'architecture nécessaire à chaque type d'interconnexion (ACD logicielle ou associée à un IPBX) : interconnexion directe ou via un connecteur, langages de dialogue ; La liste des éditeurs ACD avec lesquels votre service SVI VXML est compatible. P Préciser votre capacité et le cas échéant vos contraintes limitations pour : Conserver tous les éléments de contexte de l appel, collectés en reconnaissance vocale et le parcours client ; Transmettre tous les éléments de contexte de l appel à la fonction ACD et CTI ; Transmettre des parcours abandonnés pour engager un call back par le Samu (de manière manuelle ou sur un automate d appels sortants). SAV-INTE-6 Transfert de l appel vers un conseiller Quelles sont les contraintes pour assurer le transfert d un appel depuis le SVI vers un conseiller : Via un aboutement par le réseau de collecte? Via une double communication appelant-svi et SVI-conseiller? Parmi ces différentes architectures, laquelle préconisez-vous? Quelles sont les raisons de cette préconisation, notamment au regard des caractéristiques du programme SI-Samu (réversibilité, haute disponibilité)? SAV-STAT-1 Supervision et Statistiques d appel après transfert Quelles sont les contraintes et prérequis pour la supervision (et la génération des statistiques) d un appel de bout-en-bout : Si l appel est acheminé vers le téléphone d un conseiller par aboutement? Si l appel est acheminé vers le téléphone d un conseiller par double communication? Quelles contraintes additionnelles pourrait apporter une interconnexion par IP Trunking avec l environnement ToIP? Classification : Public 39 / 113

40 SAV-ADMN-1 Administration fonctionnelle Quels sont les services d administration fonctionnelle que vous pouvez-mettre à disposition de l ASIP Santé, répondant notamment aux besoins suivants : Ajout/suppression/modification d une branche de l arborescence pour l acheminement des appels? Enregistrement d un message par synthèse vocale? Quels outils êtes-vous en mesure de proposer pour permettre cette administration fonctionnelle, notamment pour la synthèse vocale? Quels sont les prérequis d utilisation, notamment en matière de compétence technique? SAV-ADMN-2 SAV-ADMN-3 Quel type d outil (type éditeur graphique) utilisez-vous pour décrire les applications SVI? Préciser s'il s'agit d'un outil du marché ou d'un outil propriétaire, ainsi que les caractéristiques de l outil. Préciser les interfaces disponibles permettant aux CRRA de mettre à jour des messages en Text To Speech dans des portions prédéfinies de l'arborescence vocale Fonctions de téléphonie Besoins Description générale La solution recherchée est un système de téléphonie sur IP centralisé et à haute disponibilité. La solution doit permettre plusieurs niveaux de modes dégradés (haute disponibilité sur un datacenter, bascule entre datacenters, fonctionnement des CRRA isolés des datacenters centraux). Le système de téléphonie est couplé à un système de gestion de centre d appels assurant le routage intelligent, la distribution des appels et le couplage CTI avec le SI-Samu. La gestion de centre d appels de même que les services d enregistrement et de SVI sont décrits par ailleurs. Fonctionnellement, le service de téléphonie assure les fonctions suivantes : Fonctions centrales Service de téléphonie Samu ; Service de téléphonie administrative sur les mêmes postes téléphoniques (dualité centre d appel/téléphonie administrative) ; Acheminement des flux d appels entrants sur les postes téléphoniques des CRRA, en TDM en nominal, en IP en secours (la priorité pouvant être inversée dans le temps). Les appels entrants (partie de l appel entre la boucle locale de l abonné et l IPBX central) sont aboutés aux appels sortants vers les CRRA (partie de l appel partant de l IPBX central vers le CRRA) ; Acheminement des flux d appels sortants ; Interface TDM avec le réseau téléphonique public, ou liaison avec d autres organes opérateurs ; Interface avec : o Applications externes (lien CTI par exemple) ; o Fonction de SVI ; o Fonction d enregistrement ; o Annuaire ; Fonctions d ACD disponibles dans la solution de téléphonie. Ces fonctions peuvent être activées en backup des fonctions ACD fournies par la solution de centre d appels externe à la solution de téléphonie ; Classification : Public 40 / 113

41 Messagerie vocale ; Évolution vers des fonctions de visioconférence/chat entre agents. Fonctions d exploitation Supervision/statistique ; Administration ; Configuration. Fonctions fournies sur les sites locaux Les besoins de téléphonie sont : Interface RTC (lignes T2) en particulier pour la réception des appels 15 en provenance du site central ; Interface avec le WAN, ou une interface LAN ; Interface avec la téléphonie hospitalière (téléphonie administrative) ; Modes dégradés : capacité à maintenir le service de téléphonie dans le cas où le réseau IP/MPLS est indisponible (mode «survie») ; Fourniture de téléphone IP Architecture envisagée Ces éléments sont donnés à titre indicatif pour faciliter la compréhension. Toute solution qui répond aux exigences fonctionnelles et non fonctionnelles exprimées reste acceptable, quand bien même l architecture proposée est différente, mais les principes structurants présentés doivent cependant être pris en compte. Classification : Public 41 / 113

42 La solution centrale est un ensemble de «Call Manager» répartis sur deux datacenters. Le second datacenter est passif. Pour assurer la meilleure disponibilité du système, des gateways avec option de «survabilité» sont prévues sur les sites locaux des CRRA. Elles permettent l'acheminement nominal : Du flux téléphonique TDM depuis l'opérateur de collecte vers le CRRA ou depuis le CRRA vers l extérieur ; De la signalisation depuis et vers les Datacenters centraux. Elles permettent l acheminement nominal du trafic en TDM depuis les datacenters centraux Principes structurants Pour délivrer le service de téléphonie, les principes suivants sont considérés comme structurants dans la solution pressentie : La stratégie d achat prévue est la suivante : o Les matériels et les licences de la solution de téléphonie sont achetés par le SI-Samu ; o Les datacenters sont également fournis par l'opérateur de service, les solutions de téléphonie et logicielles (notamment le logiciel de régulation médicale) étant colocalisées au sein de chaque datacenter (actif et passif) ; La solution doit être homogène entre les parties téléphonie, call management et gateway afin d'éviter les problèmes d interopérabilité ; Classification : Public 42 / 113

43 La collecte des appels est centralisée en TDM. L acheminement vers les CRRA se fait par aboutement sur réseau RTC en mode nominal et en IP en backup. En effet, la qualité de la voix est primordiale : la tonalité de la voix, le stress etc. sont des indicateurs indispensables à la pause d un diagnostic efficace. Les phénomènes de compression/décompression sont donc à éviter au maximum ; La capacité à tenir la charge : la solution mise en place doit être capable d absorber des pics d activité sans que le service soit interrompu ; La capacité à croître de manière rapide en cas de phénomène à cinétique dite «lente» (cas de grippe, épidémie, nécessité d accroître le nombre de postes téléphoniques et/ou d agents) ; Forte disponibilité : la fonction phonie des Samu ne peut tolérer une panne de plus de 5 minutes par an. La solution de téléphonie doit donc avoir une disponibilité 5-9 ; Une répartition sur deux datacenters (actif/passif) est prévue Demande d informations TLC-PRES-1 Présentation de la solution de téléphonie Pouvez-vous présenter la solution de téléphonie que vous envisagez pour répondre à nos orientations: Architecture de la solution : localisation des composants, résilience, interaction avec des logiciels ou équipements tiers sans oublier le CTI link ; Gamme/modèle d équipements envisagés, technologies utilisées (hardware spécifique, matériel IT standard +l ogiciel, etc.), protocoles et standards supportés, interfaces d intégration avec des applications ou périphériques tiers (APIs, etc.). TLC-CAPA-1 TLC-CAPA-2 Gestion de la capacité Quelles sont les limites de la solution en termes de positions, extensions, d interactions simultanées, etc.? Préciser notamment : Le nombre maximum d appels simultanés ; Le nombre d agents maximum ; Le nombre de nœuds de routage. Pouvez-vous indiquer les durées d approvisionnement matériel et logiciel types des composants concernés pour le SI-Samu au niveau central et au niveau local? Quelles sont les solutions mises en œuvre pour pallier des défaillances matérielles? TLC-FNCT-1 TLC-FNCT-2 TLC-FNCT-3 Fonctionnalité du service de téléphonie Concernant la gestion de flux d appels entrants, préciser la disponibilité ou le niveau de couverture des fonctions suivantes : Fusion d appels entrants sur un même poste sans avoir à passer par la fonction conférence : fonction téléphonique qui permet de mettre en relation deux communications téléphoniques sans être obligé de se connecter à l une d entre elle et/ou de mettre en attente l une d entre elle ; Transfert accompagné ou non ; Usage de fréquence vocale ; Reprise d'appels internes. Concernant votre service de messagerie vocale, quelles sont les interfaces disponibles? Quelles sont les API disponibles pour une intégration informatique? Est-il possible de s intégrer avec l annuaire des abonnés au système (au SI-Samu) et selon quels mécanismes? Classification : Public 43 / 113

44 TLC-FNCT-4 TLC-FNCT-5 Gestion des appels sortants : confirmez-vous qu il est possible d afficher : Le numéro «15» à la place du numéro de la ligne sortante lors d un appel sortant du SI-Samu vers l extérieur ; Le numéro de l agent ou du poste physique, si aucun agent n est logué sur le poste téléphonique de la personne appelée lors d un appel interne. Concernant le téléphone supportant les fonctions de gestion de flux téléphoniques décrites plus haut, l ASIP Santé souhaite les caractéristiques suivantes : La possibilité de gérer plusieurs conversations simultanées (6) et des conférences (minimum 3 personnes) avec mixage local ; Gestion du casque : o Depuis le téléphone ; o Depuis un PC ; Sécurité : o Support authentification 802.1x ; o Gestion des VLAN ; o Signature des logiciels téléchargés sur le téléphone ; o SIP/TLS ; o HTTPS. Préciser les modèles de téléphones/gammes correspondant à ces besoins. Préciser également : La liste des touches paramétrables, le moyen de les paramétrer ainsi que les différentes fonctions paramétrables par le biais de ces touches, y compris des fonctions avancées, en cas de dysfonctionnement de l organe de couplage téléphonie informatique ; La taille de l écran (nombre de lignes, caractères par ligne) pour chaque poste. Le schéma ci-dessous décrit de manière simplifiée le périmètre de responsabilité des fonctionnalités ACD. Le marché M2 (cf. chapitre 1.2) sera en charge en mode nominal. En cas de défaillance des fonctionnalités ACD nominales, le marché M1 devra assurer en backup des fonctionnalités de type ACD. Classification : Public 44 / 113

45 Routage intelligent/distribution L objet des questions sur le routage/distribution est d apprécier les capacités propres du système de téléphonie en termes de routage/distribution des appels, dans le cas où la solution de gestion de centre d'appels (solution ACD/CTI externe) est hors service. TLC-DIST-1 TLC-DIST-2 Préciser votre support des fonctions de routage suivantes : Blacklist : fonction qui permet de gérer les appels malveillants et d appliquer un traitement particulier, dynamique dans le temps ou selon les actions du «malveillant». Même question pour la gestion des whitelist (numéro privilégié) et graylist (numéro à traitement spécifiquement) ; Traitement des appels inappropriés : exemple d'un fax sur le 15 ; Traitement des appelants connus : annuaire interne du Samu ; DRM récents connus au sein du LRM ; Fonction «Last Call Agent» : fonction téléphonique qui permet de distribuer l'appelant sur le dernier agent avec qui il a été en contact, par la reconnaissance de son numéro de téléphone ; Traitement des numéros étrangers avec identification du pays d'origine. Préciser votre support des fonctions d ACD/routage suivantes : Gestion des débordements ; Mise en retrait, en pause, en wrap-up (pause traitement post-appel) ; Intrusion : fonction téléphonique qui permet à un agent logué comme «superviseur» de pouvoir se connecter à une conversation et le cas échéant d'intervenir dans la conversation en cours ; Double écoute : fonction téléphonique qui permet à un agent logué comme «superviseur» de pouvoir se connecter à une conversation sans possibilité d'intervenir dans les échanges ; Gestion des fermetures de salle d attente (téléphone) : la gestion des fermetures de salle est l'action qui suit la prise en compte de l'indisponibilité d'une salle. Une salle peut être indisponible soit parce qu'un calendrier indique qu'elle est fermée, soit parce qu'aucun agent n'est connecté. Préciser votre mode de gestion des appels perdus : TLC-DIST-3 TLC-DIST-4 entification et visualisation des appelants ayant été mis en attente dans une file ou salle d attente et qui ont raccroché avant que la fin du traitement de l appel soit intervenue ; Surveillance de certaines salles d'attente ; Alerte en cas de perte de communication ; Proposition de rappel dans le groupe de traitement à l'origine du transfert en salle d attente (Last Call Agent). Est-il possible de placer l appel dans 2 files d attentes simultanément? Par exemple, l appel est présent dans la file de l agent «lambda» car c est l agent qui a pris cette interaction lors d un précédent appel mais il est souhaité que cet appel soit dans la file globale du CRRA pour être pris dès qu un agent est disponible même si ce n est pas lui le dernier agent appelé. Classification : Public 45 / 113

46 Téléphonie administrative Téléphonie administrative : tout appel en dehors du cadre de l activité SI-Samu. Préciser la disponibilité des fonctions suivantes : TLC-TLAM-1 Dans notre contexte, quels modèles/possibilités envisagez-vous pour : L accès au plan de numération du Samu par l ES ou l'accès au plan de numérotation de l ES de rattachement du Samu par la solution ; L accès à l annuaire de l ES/du Samu. Pouvez-vous décliner votre réponse en fonction : Du point de vue de l usager (utilisation de préfixes) ; Du point de vue de la configuration (impact sur la solution Samu). TLC-TLAM-2 Comment gérez-vous les appels de système bippeur et retour éventuel? TLC-TLAM-3 TLC-TLAM-4 TLC-TLAM-5 TLC-TLAM-6 TLC-TLAM-7 Précisez vos modèles de gestions des appels sur DECT (dualité téléphonie fixe physique - téléphonie fixe en situation de mobilité). Précisez l intégration possible d un appel (signalisation de présence sur un interphone commandant une porte) vers le système de téléphonie. Précisez la capacité à intégrer un système d interphonie (permettant des appels d interphone à partir de la ligne téléphonique d un agent). Cas des configurations téléphoniques issues des PABX (ou IPBX) de l ES de rattachement (groupes d appel, filtrage) : Préciser les fonctions disponibles sur le poste via une interface intra PABX (type QSIG ou autres précisez par signalisation utilisable) ; Préciser la possibilité de limiter l usage de ces fonctions aux appels «administratifs» ; Préciser les besoins en préfixages éventuels. Précisez la capacité de vos matériels à accepter une communication de type visioconférence entre agents : Intra CRRA ; Inter CRRA. TLC-INTE-1 TLC-INTE-2 TLC-INTE-3 Intégration avec flux externes S agissant de l intégration avec l opérateur de collecte : quelle architecture préconisezvous à l interface avec les liens TDM de l opérateur ou des opérateurs? Même question concernant d une livraison en trafic IP? Préciser la modularité des équipements envisagés (compte tenu de la capacité envisagée) et leur résilience. Interface avec les PABX (majorité) ou IPBX des Établissements de Santé : Préciser les signalisations supportées ; Précisez la liste de PABX classiques/ipbx déjà interfacés en cas de protocoles propriétaires ; En particulier, préciser votre support de la signalisation QSIG. Intégration avec le Serveur Vocal Interactif : Préciser les interfaces et protocoles supportés ; Préciser les SVI tiers compatibles. Cela nécessite-il un développement spécifique? Classification : Public 46 / 113

47 TLC-INTE-4 TLC-INTE-5 Intégration avec les enregistreurs : Préciser les interfaces et modes d intégration supportés : Actif : établissement d un appel avec l enregistreur ; Passif : duplication du flux media ; Passif : utilisation d un service de conférence. Préciser les interfaces (media, signalisation). Préciser les équipements avec lesquels vos solutions sont déjà intégrées. Solution call center tiers : Préciser les solutions supportées avec votre solution de téléphonie ; Préciser si le protocole SIP standard est supporté et les éventuelles limitations ; Préciser les interfaces disponibles pour l intégration (interface CTI) et les limitations en termes d échanges de données entre les deux systèmes ; Préciser les informations fournies au CTI/ACD notamment sur le login/logout et les états de l agent. TLC-QOSV-1 Qualité de la voix Qualité auditive : Préciser les outils disponibles de mesure de la qualité audio (mesure qualité objective), ou du moins ceux que vous préconiseriez? Préciser les paramètres suivis : Mesure issue des recommandations P800 (type PESQ) ; Délais de transit moyen, minimum et maximum constatés, gestion de la latence ; Écho, gigue, diaphonie, niveau du signal acoustique, niveau de bruit, perte de paquets, temps d établissement des appels. TLC-SPRV-1 Supervision/reporting Est-il possible de superviser : Tous composants de la solution? Le trafic sur les liens? D autres éléments? Précisez les possibilités d intégration de cette supervision avec un système tiers. TLC-SPRV-2 Disposez-vous d'un outil de taxation? Le cas échéant, présenter cet outil. TLC-SPRV-3 TLC-SPRV-4 TLC-SPRV-5 La supervision est-elle compatible avec un outil d hypervision? Préciser : Le type d interface : SNMP, autres ; La capacité à filtrer/agréger des alarmes significatives (franchissement de seuil). Pouvez-vous confirmer la possibilité d export des différents compteurs/mesures vers une solution de reporting? Pouvez-vous décrire le principe (format, export, durée de conservation)? Dans le cadre d un processus de supervision globale : Pouvez-vous préciser les indicateurs que votre solution est capable de remonter? Pouvez-vous préciser d autres indicateurs qu il vous semble pertinents de remonter? Classification : Public 47 / 113

48 TLC-ADMN-1 TLC-ADMN-2 TLC-ADMN-3 TLC-ADMN-4 TLC-ADMN-5 Configuration Configuration des utilisateurs : Concernant la mise à disposition de service de configuration des abonnés en masse (une unique opération pour configurer un groupe d abonnés), l ASIP Santé souhaiterait : Des fonctions d export de base de données de tous les paramètres d abonnés ; Un outil de vérification de la cohérence des configurations des abonnés (cohérence entre différents paramètres des postes d abonnés) ; Le paramétrage des fonctions téléphoniques pris en compte de manière dynamique (ou différée selon les besoins). Pouvez-vous confirmer et préciser la capacité de votre solution à couvrir ces points? Gateway pour l acheminement local via les T2 des CRRA : Précisez la faisabilité des deux points suivants : L interface de configuration permet de modifier l ensemble des paramètres de chaque passerelle d interconnexion avec le RTC (activation / désactivation des interfaces, modification de la configuration des interfaces, modification des options de secours de la téléphonie locale embarquées sur la passerelle) ; Chaque passerelle doit pouvoir être accessible via un protocole de prise en main à distance. La configuration de chaque passerelle doit pouvoir être stockée et sauvegardée. Décrire les possibilités d administration de la passerelle même en cas d isolement de site (administration «out of band»). Paramétrage de masse de la configuration IP : L ensemble des paramètres IP d un ou de multiples composants doit pouvoir être changé à distance au travers de l interface d administration : Paramètres du serveur DHCP ; Paramètres liés aux options DNS, DHCP et IP éventuellement nécessaires au bon fonctionnement de la solution. Pouvez-vous confirmer et préciser la capacité de votre solution à couvrir ces points? Configuration des composants centraux : La solution doit permettre la modification de l ensemble des paramètres des serveurs centraux. La solution permet-elle : La gestion des plans de numérotation (préciser, la problématique étant nationale et locale) ; La configuration des paramètres de routage ; La configuration des matrices de distribution (fonction ACD). Configuration des routes : Préciser le mode de configuration des acheminements du trafic téléphonique. Acheminement des appels entrants vers les CRRA : Priorisation route TDM versus IP (et réciproque) ; Répartition entre deux T2 sur un CRRA (en supposant qu ils ont un NDI distinct) ; Cas où l un des T2 est indisponible ; Limitation du trafic IP vers certains sites (dimensionnés à 50% du trafic nominal) ; Trafic sortant : o Choix de la route en Least Cost Routing (T2 local, lien QSIG ou SIP, route par le central). Classification : Public 48 / 113

49 TLC-ADMN-6 TLC-ADMN-7 TLC-ADMN-8 Administration Préciser les impacts des mises à jour sur les fonctionnalités de téléphonie (durée de coupure, nécessité de redémarrage compte tenu de l architecture 5-9 envisagée). Préciser les capacités de retour arrière en cas de bug critique. Pour un accès par un administrateur local à un CRRA, préciser les possibilités de restriction sur les données (ex : gestion des abonnés limités au CRRA de rattachement). La solution propose-t-elle nativement une interface graphique permettant de réaliser des actions simples telles que la création/modification/suppression d un agent, d un poste? Le cas échéant, pouvez-vous la décrire? Dans le cas contraire, existe-t-il une API permettant le développement d une telle IHM? Classification : Public 49 / 113

50 Gateway dans les CRRA Fonctions demandées pour la gateway : Service assurant nominalement l interopérabilité avec le réseau RTC (liens T2) local pour la réception des appels entrants ; Fonction de «survie» : dans le cas où le site est isolé du site central : les téléphones IP doivent pouvoir continuer à recevoir et émettre des appels tout en conservant leur configuration ; Possibilité d interface analogique ; Interface avec les PABX des ES (interface QISG). Préciser les modèles de gateways en fonction de la typologie de sites suivante : TLC-FNCT-7 CRRA Nombre de Sites Nombre de personnes moyen en pointe Petit Moyen Grand Central Un utilisateur traite en général plusieurs appels simultanément. Préciser la connectivité (types d interface), la capacité, le type de hardware et l OS. Un site comporte 1 ou 2 T2. Dans le cas à deux T2, les T2 arrivent a priori dans deux locaux techniques distincts et il peut y avoir deux gateways. TLC-FNCT-8 Préciser le modèle de redondance. Mode «survie» (survivability) : Préciser le mode de fonctionnement en cas de perte des liens avec l IBPX principal : Critère de passage en mode local ; Fonctions disponibles sur le téléphone ; Éléments de configuration préservés (restriction d appels, programmation des touches, etc.) ; Temps de bascule (réenregistrement des téléphones) ; Pertes ou pas des sessions en cours. Décrire la remontée en mode nominal (polling du site central par les téléphones, la gateway)? Comment s assure- t-on de la stabilité du retour au mode nominal avant de rebasculer? TLC-FNCT-9 Préciser les échanges et le protocole liés au service de survie (échanges gateway/cm pour dupliquer la configuration, déclaration des gateways dans les terminaux; etc.). Préciser le fonctionnement (nominal et survie) s il y a deux gateways (pour deux T2) sur le site (fonctionnement actif/actif ou maître/esclave). TLC-FNCT-10 Préciser la visualisation par l utilisateur sur le téléphone s il est en mode «survie». TLC-FNCT-11 Préciser les mécanismes de maintien de l intégrité de la configuration / resynchronisation en cas de changement de configuration (modification locale). Classification : Public 50 / 113

51 Modes dégradés Rappel: une disponibilité de type 99,999% est envisagée. Elle est répartie sur deux datacenters. Cas envisagés : Perte du Call Server (appelée aussi Call Manager dans le document) principal sur un site, bascule sur un call server de backup ; Perte d un datacenter, passage sur le second datacenter. Préciser le mode de fonctionnement nominal que vous envisagez entre les calls managers pour permettre d assurer la reprise en cas de besoin (propagation des configurations). TLC-RESL-1 En cas de déclenchement, préciser : Événement déclencheur ; Conséquence pour les appels en cours ; Temps de bascule pour les téléphones ; Mode de retour à la normale. Perte des fonctions call center (nominal et backup) : en cas de perte des fonctions CTI/routage/distribution, préciser selon quel processus les fonctions natives d ACD de la solution de téléphonie peuvent reprendre la distribution des appels. Préciser si la reprise est automatique. TLC-RESL-2 TLC-RESL-3 Préciser la configuration des fonctions ACD en mode nominal (file de taille nulle par exemple). Pouvez-vous préciser la capacité de votre solution à réaliser des upgrades ou opérations de maintenance sans arrêt ou dégradation de service? Préciser la stratégie type à adopter pour mettre à niveau les datacenters. Préciser la possibilité de votre solution de continuer à fonctionner (signalisation, acheminement des appels) en cas : D indisponibilité des gateways sur les sites locaux ; Ou en cas d indisponibilité des fonctions centrales de téléphonie. Préciser les mécanismes mis en place ainsi que les éventuelles limitations fonctionnelles. TLC-SECU-1 Sécurité Préciser les mécanismes de sécurité pouvant être mis en œuvre dans la solution : Poste IP ; Administration des équipements ; Sécurisation des échanges entre les différents équipements qui composent l architecture de téléphonie ; Le contrôle d accès au réseau ; La vérification de signature de fichiers. Préciser comment les mécanismes cryptographiques employés dans la solution sont gérés (ex : usage de certificats : stockage, diffusion). TLC-SECU-2 Note : le cryptage des flux media n est pas retenu (SRTP). Disposez-vous d une offre de Session Border Controler (ou à défaut précisez les matériels fréquemment utilisés avec vos solutions)? Quelles sont le cas échéant vos recommandations de positionnement de ces SBC Classification : Public 51 / 113

52 dans l architecture Samu? TLC-SEXP-1 TLC-SEXP-2 Matériel et logiciel de base Préciser pour chaque élément les plates-formes matérielles et les OS et logiciels de bases utilisés. Préciser s il s agit de composants banalisés ou propriétaires. Préciser si les éléments peuvent être installés dans un environnement virtualisé. Préciser les contraintes de la solution sur : Les services DHCP, DNS, NTP ; L adressage IP. TLC-INTX-1 IPv6 La solution que vous proposez est-elle compatible IPv6? En mode nominal ou dualstack? Intégration des fonctions IPBX dans un domaine opérateur Besoins Le service d Acheminement intervient dans le cadre de la distribution de l appel depuis l opérateur de service vers le meilleur agent se trouvant dans un CRRA local via l opérateur de boucle locale. Le service d Acheminement concerne tout le trafic téléphonique entrant, reposant bien sur le 15 et le 112 mais aussi tous les numéros d accès direct propres à chaque CRRA, ainsi que potentiellement d autres numéros gérés par les personnels du Samu. En mode nominal, un appel arrive sur les infrastructures télécoms de l opérateur de service des Samu (IPBX + T2, ou autre architecture définie par l opérateur de service), puis il est qualifié par le système CTI qui détermine le meilleur agent cible pour la distribution. L appel est alors acheminé vers le CRRA local par un lien T2 et une gateway afin de mettre en relation l appelant et l agent. Plusieurs cas de modes dégradés sont possibles : Le site local est en panne ; La liaison T2 est tombée ; Le réseau MPLS est tombé ; L opérateur de Service présente un dysfonctionnement. Le site local est en panne (par exemple coupure d électricité) Dans ce cas, il faut nécessairement que l entraide soit activée pour distribuer les appels sur les autres CRRA suivant les stratégies de débordement mises en place. L acheminement de l appel se fait normalement via le lien T2 vers le CRRA d entraide identifié. La liaison T2 entre l opérateur de service et le CRRA local est tombée Dans ce cas, l appel est acheminé vers le site local via le réseau IP-MPLS. Classification : Public 52 / 113

53 Le réseau IP-MPLS entre l opérateur de service et le CRRA local est tombé Dans ce cas : Les gateways locales sont en mode autonome et assurent la distribution locale des appels ; L IPBX central doit pouvoir distribuer et déclencher l acheminement des appels en TDM (au moins les numéros accessibles publiquement des CRRA : numéro de tête de ligne de la T2 et/ou numéros des agents en SDA). L état des agents peut être connu dans la mesure où les applications sur le poste de travail de l agent peuvent communiquer avec le central via un réseau VPN Internet en secours du WAN MPLS. Les modes de distribution envisageables peuvent donc être : Basés sur les états du CTI ; Basés sur l ACD (test de la disponibilité des agents par appel) ; Aveugles (pas de connaissance de l état des agents). L opérateur de service présente un dysfonctionnement Dans ce cas, l appel est acheminé vers le site local depuis l opérateur de collecte ou les premiers équipements de l opérateur de service via des tables de routage statiques. La fourniture du service d Acheminement est encadrée par des exigences opérationnelles fortes : Une haute disponibilité du service en 24/24 7/7 ; la fonction phonie des Samu ne peut tolérer une panne de plus de 5 minutes par an mettant en péril toute la téléphonie de plusieurs Samu. La solution de téléphonie doit donc avoir une disponibilité 5-9 ; Une résilience forte de la solution pour répondre à tout type d incident de fonctionnement et permettre la continuité du service ; Une capacité d absorption de pics d appels, tout en préservant la qualité vocale et la performance de traitement des appels ; Une capacité industrielle de la solution du service vocal pour faciliter son déploiement et maitriser l évolutivité et la pérennité de la solution ; Une capacité à gérer la dualité d acheminement TDM/IP, à des fins de résilience de chemin d accès. L acheminement vers le CRRA est fait nominalement en T2 et par aboutement avec l appel entrant. L aboutement est privilégié pour garantir le meilleur contrôle de l appel en cas de défaillance et pour maintenir certaines fonctions en central (ex : enregistrement). Pour plus d informations, se référer à l annexe du chapitre 5.1 présentant la cinématique de l appel. Classification : Public 53 / 113

54 Demande d informations Acheminement des appels ACH-ACHC-1 ACH-ACHC-2 Reprise de l'appel acheminé vers le CRRA (via TDM ou via WAN) : Selon votre expérience, l'acheminement par aboutement est-elle la solution la plus appropriée? Y a-t-il des alternatives? Préciser si votre solution est capable de gérer la commutation d appel visioconférence (Le cas échéant, une description générale des grands principes sera appréciée). Préciser les spécificités sur l acheminement (route WAN/MPLS en QoS visio par exemple). Acheminement WAN IP Les liens de raccordement des sites au WAN ne sont pas nécessairement dimensionnés pour traiter 100% du trafic dans un premier temps (usage de backup par rapport au TDM). ACH-ACHC-3 Pouvez-vous préciser vos recommandations liées : Aux règles d ingénierie/dimensionnement concernant la saturation d un lien WAN d acheminement des appels ; Aux mécanismes permettant de s appuyer entre autres sur la remontée d une information de saturation, pour permettre le déclenchement d'un scénario d'entraide. ACH-RESL-1 ACH-RESL-2 ACH-RESL-3 ACH-RESL-4 Traitement de la signalisation d appel Avez-vous la capacité à discriminer et gérer les différents cas d'échecs d'un appel : L'agent ne répond pas ou est occupé ; T2 saturée ; T2 hors service ; Gateway(s) du CRRA hors service (plus de service de téléphonie) ; WAN/IP hors service ; Autres (préciser). De quelle "intelligence en propre " dispose l'acheminement pour traiter les «retentatives» en respectant les règles pré définies : Bascule de chemin TDM vers le WAN sur un même CRRA (T2 du CRRA toutes saturées ou hors service par exemple) ; Bascule vers un CRRA d'entraide lorsque ce CRRA est injoignable ou lien data du CRRA saturé. Pouvez-vous préciser votre capacité à remonter ces informations de signalisation vers le CTI pour que des décisions de «réacheminement» puissent être prises? (scénario d'entraide par exemple)? La solution de téléphonie est répartie sur deux datacenters. Un opérateur de collecte assure la fourniture des flux d appels en amont vers le datacenter actif. En cas de bascule entre deux datacenters, pouvez-vous préciser les conséquences : Sur les communications en cours (via TDM ou via WAN) ; Sur les statistiques ; Sur la bascule des postes IP (reconnexion au second datacenter). Classification : Public 54 / 113

55 ACH-RESL-5 ACH-RESL-6 En complément de RESL-1, dans le cas de perte du WAN IP/MPLS, pouvez-vous fournir une description «de bout en bout» de votre fonctionnement? Capacités résiduelles à distribuer/acheminer les appels (préciser les numéros accessibles) ; Notification à la solution centre d appels pour que celle-ci se limite aux agents accessibles en cas de perte du WAN. Dans le cadre d une communication tripartite provenant d un autre centre d appel (par exemple l appelant a contacté le centre d appel du 18, qui met en conférence à 3 avec un CRRA), vous semble-t-il possible malgré l entrée initiale externe au SI-Samu (appel sur le 18) de maintenir l aboutement direct entre l appelant et le CRRA et sortir de la boucle le correspondant 18? ACH-SVLA-1 Supervision et SLA Pouvez-vous préciser, selon vos retours d expérience, le temps d'établissement d'appel atteignable : En dégradé, pour un appel transitant par le WAN/IP après échec du T2 ; Pour un appel transitant par le WAN/IP après avoir testé que les deux T2 sont Hors Service. Le temps d établissement, exprimé en secondes, est défini comme suit : temps entre la désignation d une extension (un agent) par la solution de centre d appels et la présentation de l appel à l agent (première sonnerie). ACH-SVLA-2 Pouvez-vous préciser les informations de supervision de l'acheminement (alarmes, indicateurs) pouvant être remontées à un système d'hypervision (signalisation, autre)? Par quel outil et quelle interface? Qualité de la voix ACH-QOSV-1 Pouvez-vous préciser votre capacité à diagnostiquer les problèmes de voix sur des trajets IP (LAN/WAN)? Fonctions d ACD locale ou centrale Besoins Le service de «Routage et Distribution» intervient dans le cadre de la qualification et de la segmentation des interactions entrantes ou sortantes puis leur distribution depuis l opérateur de service vers l'agent (ARM ou médecin régulateur) se trouvant dans un CRRA local selon des règles définies par les Samu. Le service de routage et de distribution ici décrit n'intègre pas le SVI. La qualification et la segmentation des appels (ou interactions) permettent d enrichir la connaissance de l appel, de l appelant et de son historique interactionnel et d orienter la décision de routage distribution de l appel. Les mécanismes mis en œuvre reposent sur la capacité à : Collecter tous les éléments amont de qualification de l appel comme par exemple : o o La définition du département de provenance de l appel (donnée fournie par l opérateur télécom ou de collecte) ; Le numéro appelé pour contacter le Samu et la typologie de l appelant (particulier, professionnel de santé, pompier,..) ; Classification : Public 55 / 113

56 o Les éléments de qualification de la demande connus du SVI ; Interroger des systèmes de base de données (SI-Samu ou base de données d interactions : réitération d appels et historique interactionnel) en vue de segmenter l appel ; Gérer des priorités d appels pour la distribution, fonction de la combinatoire de tous les éléments de qualification segmentation collectés ; entifier le CRRA nominal en charge du traitement de l appel et les compétences nécessaires ; Orchestrer la gestion de mécanismes d entraide vers d autres CRRA ; Enrichir et stocker la connaissance de l appel, des informations collectées et de leur traitement selon des mécanismes à définir ultérieurement. La distribution des appels (ou d interactions) rend les services suivants : Établir la décision de distribution de l appel sur : o La base du statut de la personne à même de prendre l appel (principalement ARM), remonté via le bandeau téléphonique ; o La base des principes de routage (paramétrage de files d attentes) ; Piloter les appels en attente de traitement au travers de files d attente (ou salles d attente) spécifiques ; Engager, si besoin, des mécanismes de débordement vers d autres CRRA selon des principes d activation soit manuelle soit automatique en fonction des règles définies par les Samu ; Dans le cadre des Samu, contrairement à la logique de centre d appels habituels, les mécanismes de dissuasion ne seront pas mis en œuvre ; par ailleurs, il est mis en place un système de rappel des appels raccrochés : o o Pendant le parcours vocal dont la durée de communication est supérieure à X secondes ; En salle ou file d'attente après prise en compte par un agent, quelle que soit la durée de communication. Principales caractéristiques de la solution attendue : Capacité à gérer des services et stratégies de routage distribution soit communs à tous les CRRA, soit par ensemble de CRRA présentant des besoins communs, soit de manière spécifique à un CRRA donné ; Gestion de compétences et de profils communs/spécifiques : o Compétences métiers communes à tous les Samu ; o o Compétences locales spécifiques à chaque Samu (département, métier spécifique,..) ; Profils métiers communs pour les utilisateurs de centre d appels mais différenciés par la compétence locale. Par exemple, mise en place d un profil général ARM pour lequel on affecte la compétence géographique 94 afin de cibler un ARM du Samu de Créteil. Forte disponibilité de la solution : la fonction phonie des Samu ne peut tolérer une panne de plus de 5 minutes par an mettant en péril toute la téléphonie de plusieurs Samu. La solution de téléphonie doit donc avoir une disponibilité 5-9 ; Classification : Public 56 / 113

57 La capacité à tenir la charge : la solution mise en place doit être capable d absorber des pics d activité sans que le service soit interrompu ; Administration métier de la solution, offrant des interfaces orientées «utilisateur final» apportant souplesse et réactivité ; Urbanisation des développements et des paramétrages des fonctions ou des services, sous-services de routage et distribution (pour augmenter la réutilisabilité de développements de routage distribution et faciliter sa maintenance et évolutivité) ; Capacité pour un utilisateur de réaffecter manuellement un appel en file d attente vers une autre file d attente ou à prendre un appel dans une file d attente pour le traiter même si cette interaction ne lui est pas destinée ; Capacité à mettre des appels en attente par un agent et de gérer plusieurs conversations en parallèle. Résilience et modes dégradés de la solution En mode nominal, le service est assuré par la solution de traitement des appels ou interactions qui gère l ensemble des fonctionnalités (hors SVI) ; En mode dégradé, une distribution de backup de type ACD intégrée à l IPBX (distribution des appels par compétence dans le système téléphonique) est mise en place ; La solution doit être hautement disponible et la bascule primaire/backup de la solution ne doit pas perturber les interactions en cours. Il ne doit pas y avoir de perte de communication ni de statistiques. Plusieurs cas de mode dégradé sont possibles : Le site local est en panne ; L un des deux datacenters hébergeant la solution de traitement des interactions présente des dysfonctionnements majeurs ; Le SVI est totalement ou partiellement indisponible ; Le SI-Samu ne répond pas (partie informatique) ; Les deux datacenters hébergeant la solution de traitement des interactions présentent des dysfonctionnements majeurs ; L opérateur de service présente un dysfonctionnement majeur ; Le réseau IP_MPLS entre l opérateur de service et le CRRA local est coupé. Le site local est en panne (par exemple coupure d électricité) : Dans ce cas, il faut nécessairement que l entraide soit activée pour distribuer les appels sur les autres CRRA suivant les stratégies de débordement mises en place. L acheminement de l appel se fait normalement via le lien T2 vers le CRRA d entraide identifié. L un des deux datacenters hébergeant la solution de traitement des interactions présente des dysfonctionnements majeurs : Dans ce cas, la solution étant hautement disponible, une bascule doit se faire automatiquement vers le second datacenter sans impact sur l activité en cours, notamment sans perte d appels ni de statistiques. Le SVI est totalement ou partiellement indisponible : Dans ce cas, c est la solution de gestion des interactions qui réalise une qualification par défaut des interactions en fonction de règles définies par l'asip Santé. Classification : Public 57 / 113

58 Le SI-Samu ne répond pas : Dans ce cas, c est la solution de gestion des interactions qui réalise un traitement par défaut des interactions en fonction de règles définies par l'asip Santé. Les deux datacenters hébergeant la solution de traitement des interactions présentent des dysfonctionnements majeurs Dans ce cas, c est la couche ACD de l IPBX qui prend la main afin de distribuer avec un minimum d intelligence les interactions vers l ARM ou le médecin régulateur le plus pertinent. L opérateur de service présente un dysfonctionnement majeur Dans ce cas, l appel est acheminé vers le site local depuis l opérateur de collecte via des tables de routage statiques de type réseau intelligent de l opérateur de collecte, ou par routage statique par l opérateur de service. Le réseau IP_MPLS entre l opérateur de service et le CRRA local est tombé Dans ce cas, l IPBX teste la disponibilité des conseillers via la tonalité de retour d appel (ou sonnerie de retour d appel) afin d acheminer l interaction téléphonique vers le site local par un mécanisme à préciser de l opérateur de service ou depuis l opérateur de collecte via des tables de routage statiques de type réseau intelligent. Pour plus d informations, se référer à l annexe du chapitre 5.4 présentant la cinématique de traitement d un appel entrant Demande d informations ACD-PRES -1 Présentation de l ACD Pour répondre à nos besoins, pouvez-vous présenter les éléments structurants/différenciants de votre service de distribution des appels notamment : Architecture de la solution : dédiée ou mutualisée, localisation des composants, résilience ; Éditeur de la solution, technologies utilisées, langages, protocoles et standard supportés ; Dimensionnement : nombre maximum d appels simultanés, nombre d agents maximum ; Gestion des appels en parcage (attente de mise en relation) et mise en attente (conservation de l appel dans la salle de l agent). ACD-CAPA-1 ACD-CAPA-2 Gestion de la capacité Quelles sont les limites de la solution en termes de positions, d interactions simultanées, etc...? Les Samu doivent faire face à des pics de charge dus à des crises. Il peut s'agir de crise à cinétique rapide (accident industriel type AZF) ou lente (épidémie de grippe). Pouvez-vous préciser votre capacité à provisionner X positions supplémentaires et le délai associé (entrant et sortant) pour les rendre opérationnelles : 100 positions agent ; 500 positions agent ; 1000 positions agent. ACD-ADMN-1 Administration de la solution Pouvez-vous préciser si des outils d'administration fonctionnelle sont disponibles ainsi que la listes exhaustives des fonctionnalités couvertes, avec par exemple : La mise en place de parcours simple ; Classification : Public 58 / 113

59 L activation d un segment dans une stratégie de routage ; La modification de calendrier d ouverture fermeture ; L activation de la lecture d un message ; L activation du débordement ; L'activation d'un scenario de crise ; Etc. Quel est le niveau d'autonomie en termes de configuration pour chacun des sites? Quels outils d'imports ou de provisioning mettez-vous à disposition (exemple : ajout d'un nouveau CRRA)? L IHM d administration (à préciser par outil) est-elle intégrable dans un portail web? ACD-ADMN-2 ACD-ADMN-3 Pouvez-vous préciser s il s agit d un client lourd ou léger? Existe-il une application smartphone permettant d opérer des actions d administration fonctionnelle ou orientées métier? (le cas échéant, préciser les fonctionnalités offertes) Pouvez-vous préciser le fonctionnement de la gestion des droits et des rôles? Est-il possible de coupler l IHM à un annuaire LDAP? Pouvez-vous préciser les contraintes et les incompatibilités éventuelles? ACD-ROUT-1 ACD-ROUT- 2 ACD-ROUT- 3 ACD-ROUT- 4 ACD-ROUT- 5 ACD-ROUT- 6 ACD-ROUT- 7 Routage La solution dispose-t-elle d une fonction native permettant de gérer une «blacklist» d appels malveillant et d appliquer un traitement particulier, dynamique dans le temps ou selon les actions du «malveillant»? Pouvez-vous préciser son fonctionnement? Préciser également les mécanismes de «whitelist» (numéro prioritaire) et «graylist» (traitement sur listes de numéros en pré-routage). La solution dispose-t-elle d une fonction native permettant de traiter les appels inappropriés (gestion des appels de type fax)? Pouvez-vous préciser son fonctionnement, notamment sur le périmètre de la détection du signal? Quel est impact sur l architecture à mettre en place? Si la présentation du préfixage du n appelant n est pas réalisée, la solution est-elle capable d identifier nativement le pays d origine de l appelant? Le cas échéant, comment? Faut-il alimenter manuellement une table des préfixes téléphoniques? La solution permet-elle de réaliser (de manière native ou intégrée à un produit) : De la reconnaissance vocale avec analyse linguistique? De l analyse contextuelle du stress vocal? Ces fonctions liées à la question ACD-ROUT-4 peuvent être utilisées pendant les moments d attente pour identifier la charge émotionnelle (cris), le nom, le motif de recours. Est-il possible de re-prioriser l appel ou de lui affecter un traitement particulier en fonction des informations obtenues? Est-il possible d activer un scénario de routage (une branche spécifique) en fonction du login d un agent ayant une compétence donnée ou dans une file d attente donnée? La solution est-elle capable de router des appels visio? Pouvez-vous préciser les éventuels prérequis et spécificités pour gérer les appels visio? Dans le cas contraire, cette fonctionnalité est-elle dans votre roadmap, à quelle date? Classification : Public 59 / 113

60 ACD-ROUT-8 ACD-DIST-1 Si l appelant raccroche avant que l appel ne soit pris par un agent du CRRA, le Samu souhaite qu une campagne de rappel soit alimentée (appel sortant unitaire). Cette fonctionnalité est-elle proposée en standard par la solution? Ou bien nécessitet-elle des développements spécifiques? Distribution De quelle façon préconisez-vous le déclenchement du débordement sur un autre CRRA? est-ce faisable ou recommandé : À partir d indicateurs techniques ; Selon un paramétrage de seuils ; Manuellement via une IHM ; Suite à détection d une déconnexion du CRRA ; Selon un autre mécanisme (merci de préciser). Comment est détecté le fait qu un CRRA n est pas disponible? La fonction «Last Call Agent» est-elle proposée nativement par la solution? ACD-DIST-2 ACD-DIST-3 ACD-DIST-4 ACD-DIST-5 Dans le cas où l appel initial a été débordé sur un autre CRRA, est-il possible de distribuer le second appel du patient : Sur l agent ayant reçu le premier appel (fonction LCA)? Sur un agent du CRRA qui aurait dû prendre l appel s il n y avait pas eu de débordement? Pouvez-vous préciser s il s agit de paramétrage ou de développement spécifique? Est-il possible de placer l appel dans 2 files d attentes simultanément? Par exemple, l appel est présent dans la file de l agent «lambda» car c est l agent qui a pris cette interaction lors d un précédent appel mais il est souhaité que cet appel soit dans la file globale du CRRA pour être prise dès qu un agent est disponible même si ce n est pas lui le dernier agent appelé. La solution permet-elle de sélectionner le type d acheminement (via T2 ou IP MPLS, voir un load balancing entre les deux)? La solution permet-elle de choisir la règle en fonction du CRRA appelé? Préciser si des développements spécifiques sont nécessaires. La solution permet-elle le media blending (rappel automatique en période d activité basse)? Quelles en sont les contraintes ou les limites? ACD-INTE-1 Intégration Quels sont les différents IPBX supportés par la solution? Quels sont les types de liens possibles vers ces solutions? ACD-INTE-2 Quelles sont les éventuelles limitations de votre solution liées au protocole SIP? ACD-INTE-3 ACD-INTE-4 Un des besoins majeurs est l intégration du canal voix radio au centre de contacts Samu. La problématique principale de l interopérabilité de la radio sur le plateau du centre d appels est le manque d échanges d évènement entre la radio et la téléphonie. Cette non-communication engendre donc une difficulté de gestion de l activité pour un ARM ou un MR (Médecin Régulateur) qui peut recevoir un appel téléphonique alors qu il est en train de traiter un appel radio. éalement, il faudrait qu un appel radio puisse être traité comme un appel téléphonique (sans SVI). Quelle solution proposez-vous pour répondre à ce besoin? Avez-vous des expériences et références mettant en œuvre ce besoin? Quelles sont les différentes méthodes d interfaçage supportées avec le SI-Samu? Utilisation de requêtes SQL, Web services? Classification : Public 60 / 113

61 ACD-STAT-1 Pilotage et données historiques La solution propose-t-elle une IHM de pilotage permettant, quel que soit le média (même la radio) : D afficher des rapports statistiques temps réel? En client lourd ou léger? Existe-il une application Smartphone? D afficher des rapports standards? Des données statistiques unitaires? Agrégées? (préciser l agrégat le cas échéant) Un outil de reporting est-il fourni? En un client lourd ou léger? Des rapports standards sont-ils inclus? Pouvez-vous donner des exemples judicieux dans ce contexte? Prérequis Techniques ACD-TECH-1 Quels sont les types de bases de données compatibles avec la solution? ACD-TECH-2 ACD-TECH-3 Pouvez-vous nous fournir la matrice de compatibilité avec les systèmes d exploitation pour la partie serveur? La solution privilégiée est LINUX ; si cet OS n est pas supporté merci d en préciser la raison? La virtualisation est-elle supportée? Le cas échéant, sur quelle plateforme? Préciser les mécanismes concernés. Indicateurs / SLA Pouvez-vous préciser le taux de disponibilité maximale de la solution? ACD-SVLA-1 Merci de préciser quel est ou quels sont les éléments les plus sensibles de la solution. ACD-SVLA-2 Quels sont les différents SLA sur lesquels vous pouvez-vous engager? ACD-SPRV-1 ACD-SPRV-2 Supervision Pouvez-vous préciser les informations de supervision (alarmes, indicateurs) pouvant être remontées à un système d'hypervision du Samu? Par quel outil et quelle interface? Quels sont les intégrations possibles, l objectif pour le SI-Samu étant d avoir une vue unifiée? Dans le cadre d un processus de supervision globale : Pouvez-vous préciser les indicateurs que votre solution est capable de remonter? Pouvez-vous préciser d autres indicateurs qu il vous semble pertinents de remonter? Classification : Public 61 / 113

62 ACD-RESL-1 ACD-RESL-2 Modes dégradés En cas de bascule entre deux datacenters, pouvez-vous préciser les conséquences : Sur les communications en cours (via TDM ou via WAN) ; Sur les statistiques ; Sur la bascule des bandeaux (reconnexion au second datacenter). En cas de pandémie, le besoin peut être de fonctionner avec des agents dispersés (ex : télétravail) avec des téléphones banalisés (non reliés à la solution de téléphonie du SI-Samu). Pouvez-vous préciser vos offres pour faire face à de telles situations? Quel est le délai de déploiement de ces offres? ACD-INTX-1 IPv6 La solution que vous proposez est-elle compatible IPv6? En mode nominal ou dualstack? Conférence ou communications multi-lignes Besoins Le service de conférence intervient dans le cadre de la gestion des interactions téléphoniques afin de faciliter le traitement d un dossier et coordonner les moyens à mettre à œuvre sollicitant plusieurs intervenants. L agent régulateur du CRRA dispose de plusieurs lignes téléphoniques entrantes ou sortantes lui permettant de décrocher plusieurs appels ou d émettre plusieurs appels depuis un même poste téléphonique. A minima, il doit disposer de 2 lignes, voire plus. Chaque ligne peut recevoir des appels ACD, internes (entre 2 CRRA) ou administratifs (entre un CRRA et l Établissement de Santé par exemple). 1 : Gestion de double appel. En cours de communication avec un premier tiers, l agent doit pouvoir décrocher un deuxième appel avec la mise en garde du premier et pouvoir basculer d un appel en communication vers l appel en garde. Pour chaque appel, l agent doit pouvoir : Soit engager un transfert accompagné ou supervisé ; Soit mettre en conférence les 2 appels ; Soit raccrocher un des 2 appels. Il est à noter que tout appel peut être mis en attente dans la salle d'attente personnelle de l'agent. Cette fonctionnalité sera néanmoins déclarée sous cette appellation de «gestion de double appel». 2 : Gestion de conférence à n tiers. En cours de communication avec un premier tiers, l appelé peut décrocher un deuxième appel et piloter les 2 appels selon le principe de la bascule d états d appels décrit ci-dessus (communication / mise en garde). L agent met en conférence de 1 à n appels. L agent peut mettre fin à un appel (avec son raccroché) tout en maintenant la conférence des appels en cours et ajouter un nouvel appel dans la conférence. 3 : Organisation de secours. Le principe est identique à la gestion de conférences à n tiers, mais appliqué à l émission d appels sortants. L agent doit pouvoir émettre et gérer une conférence d appels à n tiers et également associer dans la conférence un ou n appels entrants. Par défaut et a minima, la mise en conférence est calibrée pour pouvoir gérer 3 tiers (entrants ou sortants). Classification : Public 62 / 113

63 4 : Gestion d écoute discrète. L ASIP Santé envisage de pouvoir mettre en place lors d une conversations le fonctionnement dit «d écoute discrète», qui consiste à mettre la conversation en cours en liaison avec un canal ou plusieurs canaux d écoute, à des fins d enregistrement, ou d amélioration de traitement (la fonction dite de «chuchotement», grâce à laquelle un superviseur peut parler à l ARM sans que l appelant ne l entende, peut être envisagée). 5 : Fusion de file d attente. En complément de ces fonctionnalités de base, il est envisagé un nouveau cas d usage de fusion d appels en file d attente. Cette fonction s entend par le fait qu un agent régulateur en communication sur un appel ou en conférence à n appels, puisse sélectionner un appel en file d attente et créer soit une mise en conférence soit l associer à la conférence en cours. Ce cas d usage repose sur la capacité de la solution à présenter les appels en file d attente avec des éléments de qualification (exemple : saisie du numéro de DRM dans le SVI, n appelant, ). L agent régulateur peut ainsi identifier l appelant ou l appel correspondant. La fourniture du service de conférence est encadrée par des exigences opérationnelles fortes : Une haute disponibilité du service en 24/24 7/7 ; la fonction phonie des Samu ne peut tolérer une panne de plus de 5 minutes par an mettant en péril toute la téléphonie de plusieurs Samu. La solution de téléphonie doit donc avoir une disponibilité 5-9 ; Une résilience forte de la solution pour répondre à tout type d incident de fonctionnement et permettre la continuité du service ; Une capacité d absorption de pics d appels, tout en préservant la qualité vocale et la performance de traitement des appels ; Une capacité industrielle de la solution du service vocal pour faciliter son déploiement et maitriser l évolutivité et la pérennité de la solution ; La mise en conférence d appels ACD et non ACD, tout en sachant qu il est nécessaire de disposer de statistiques complètes sur les interactions ; Une souplesse dans la mise en place de la conférence Demande d informations CFR-PRES-1 Présentation de la fonctionnalité Quelles fonctionnalités de mise en conférence préconisez-vous à l ASIP Santé selon : Besoin classique ; Besoin spécifique de «fusionner» des appels ; Dimensionnement : nombre maximum d intervenants sur une conférence (ACD et non ACD). CFR-PRES-2 CFR-PRES-3 CFR-PRES-4 Pouvez-vous préciser s il est possible pour un agent de rejoindre une conférence téléphonique en cours? Préciser les modes envisageables. Est-il possible de réaliser une conférence entre un appel ACD et un appel non ACD? (réconciliation d appels de type «centre d appels» et d appels de type «accès direct sur SDA») Dans l hypothèse où un ARM possède deux lignes ACD, s il réalise une conférence avec ses deux appels ACD, peut-il recevoir un nouvel appel ACD? Autrement dit, la mise en conférence de 2 ou 3 appels ACD, libère-t-elle une ligne ACD? Classification : Public 63 / 113

64 CFR-INTE-1 Intégration Préciser de quelle manière la fonctionnalité est implémentée notamment pour la «fusion» d appels. CFR-INTE-2 Quelles sont les éventuelles limitations liées au protocole SIP, à l IPBX ou autres? CFR-INTE-3 Un des besoins majeurs est l intégration du canal voix radio au centre de contacts Samu. Est-il possible d envisager une conférence voix radio et voix téléphonie? Dans l affirmative, quelle solution proposez-vous pour répondre à ce besoin? Avez-vous des expériences et références mettant en œuvre ce besoin? CFR-STAT-1 CFR-STAT-2 Pilotage et données historiques La solution propose-t-elle des données statistiques historiques sur les conférences? Comment sont gérés les identifiants des appels, pendant et après la conférence? À combien de lignes d enregistrements en base de données correspond une mise en conférence? La réconciliation de ces lignes est-elle possible et le cas échéant comment? Lors d une conférence à 4, suite à un appel entrant, si l agent initialement ciblé raccroche, comment est géré l appel entrant (maintien de communication sur «lâché» d appel)? Qui en devient «propriétaire» (responsabilité de raccroché) et comment? Qu en est-il au niveau statistique? Est-il possible de tracer les différentes étapes? CFR-RESL-1 Modes dégradés En cas de bascule entre deux datacenters, quelles conséquences voyez-vous : Sur les conférences en cours (via TDM ou via IP)? Sur les statistiques? Service de couplage de téléphonie Besoins Ce chapitre décrit les besoins et les informations structurantes pour offrir un Service de couplage Téléphonie-Informatique dans le cadre du SI-Samu. Il présente les principales fonctionnalités attendues, les principes structurants qui encadrent la solution à mettre en œuvre ainsi que certaines hypothèses prises. Service de Couplage Téléphonie Informatique Le service de couplage téléphonie-informatique intervient dans un premier temps dans le processus de traitement d un appel téléphonique, mais devra par la suite être en mesure de traiter des interactions au sens large : radio, vidéo, mail, fax, SMS, et des tâches de back office. Les modalités de traitement sont différentes pour chaque CRRA, en fonction des processus et organisation mis en place. Le couplage est réalisé au travers d une application dite «application téléphonique» qui réalise la passerelle entre le monde des télécoms (réception des appels, des interactions et Classification : Public 64 / 113

65 acheminement intelligent) et le monde de l informatique (création et gestion d un dossier de régulation médicale). Cette application téléphonique est utilisée par les agents des CRRA (notamment ARM, MR) pour réceptionner les demandes des patients et faire la connexion avec des logiciels tiers tels que le LRM et l application de cartographie SIG (annuaire inversé, localisation des appels). Le service de couplage combine à la fois des fonctions de bandeau téléphonique (et par extension multimédia) et des fonctions de supervision de l activité téléphonique (et par extension multimédia). Les utilisateurs (ARM, MR, superviseur) disposent sur leur poste informatique de toutes les fonctionnalités standards de téléphonie, d une vue synthétique de leur activité, d une vue de l état des salles d attente personnelles, fonctionnelles et dynamiques avec la possibilité d interagir directement via l interface graphique. L application téléphonique est ainsi à la fois une IHM, le point d entrée et le point de liaison entre les demandes d un patient, le système d information et son utilisateur. Cas d usage et de fonctionnement D une manière générale, le traitement d un appel par un agent téléphonique est organisé en 4 grandes phases : Attente et réception d un appel : o Concerne la distribution automatique de l appel vers l agent. En fonction de sa disponibilité, de ses compétences, de règles d équité, l agent reçoit une notification visuelle et/ou sonore de l arrivée d un appel ; o Par défaut, nous sommes dans un mode de décroché manuel avec un système de prévisualisation de l appel. Il est cependant envisagé de gérer une distribution en décroché automatique, à paramétrer en fonction de certaines typologies d utilisateurs, de salles d attente et/ou de CRRA ; o La notification s accompagne de l affichage des informations disponibles relatives à l appel, l appelant (issues de la PFLAU) et au motif d appel (issues du Service d Accueil Vocal) ; Se référer au chapitre pour plus de détail sur le service de routage et distribution. Prise d appel : o L agent peut accepter l appel qui vient de lui être proposé, soit en décrochant physiquement son téléphone soit via l interface graphique de l application téléphonique. Le décroché automatique est également possible selon le paramétrage. Cette fonction doit être paramétrable par CRRA ; o L agent peut également, à son initiative, sélectionner via l IHM un appel d une des salles d attente dont il a la visibilité selon un principe de picking de l appel dérogeant à la règle de premier arrivé, premier servi. Ce mode de fonctionnement est très largement utilisé car il permet aux agents de traiter des appels plus prioritaires arrivant dans une même salle d attente, et de faire gérer par l agent des règles dites d élargissement ; Traitement de l appel : lorsqu un appel est pris en traitement, l état de l agent passe automatiquement en non prêt et l interfaçage applicatif déclenche automatiquement : o La création d un DRM (dossier de régulation médicale) dans le LRM, ou l appel à un DRM existant (rappel) ; o L affichage de la position géographique de l appelant dans le SIG (information en provenance de la PFLAU : adresse de facturation pour une ligne fixe, coordonnées géographiques pour une ligne mobile) ; Classification : Public 65 / 113

66 Fin d appel : à la fin de l appel, l état de l agent passe temporairement en AfterCallWork (d une durée paramétrable) avant le retour à l état disponible. Il est à noter que les fonctions de picking restent actives, permettant à l agent de mettre de manière automatique un appel en attente afin de prendre un autre appel. Fonctionnalités du service de couplage téléphonie attendues Le pilotage graphique des fonctions standards de téléphonie : composition par numéro ou par nom (d un CRRA), le décroché, le transfert direct/accompagné, le changement d état, la mise en attente, la mise en conférence,... ; La mise à disposition d un annuaire interne Samu : CRRA, CHU, SDIS, ROR (annuaire téléphonique des moyens liés à la mission des Samu,.) ; La visualisation des informations de l appel : numéro appelant, origine 15/17/18/112, parcours SVI, annuaire inversé PFLAU, etc. ; La visualisation des salles d attentes personnelles/fonctionnelles/dynamiques, des salles de crises et d entraide le cas échéant. La liste est personnalisable en fonction du CRRA dans lequel opère l agent ; La visualisation de l historique : appels reçus, sortants, manqués, complétés des informations associés à l appel ; La gestion graphique des appels : picking d appel depuis une salle d attente, transfert vers autre salle d attente ; La capacité de communication avec des applications clientes : LRM et SIG dans notre cas ; Le pilotage de l enregistrement : bien que 100% des conversations avec des patients soient enregistrées, l agent peut interrompre l enregistrement dans le cadre des appels non liés à la régulation médicale : (appels internes, personnels, ) voire réécouter des appels enregistrés. Dans le cadre de ce besoin l interface graphique de l application téléphonique devra être adaptable selon le profil utilisateur (ARM, MR) et son CRRA d appartenance. Principes structurants Pour délivrer le Service de Couplage Téléphonie Informatique, les principes suivants sont considérés comme structurants dans la solution pressentie : L application téléphonique est de type client léger et hébergée dans un datacenter où sont colocalisés les services de téléphonie et le SI Santé. Disponible par une simple connexion web, de préférence, l application téléphonique ne nécessite aucune installation en local et est diffusée directement à tous les utilisateurs à chaque nouveau déploiement. Pour des raisons de robustesse et de sécurisation, l application sera déployée sur plusieurs serveurs répartis sur plusieurs sites. Un développement tirant profit des nouvelles techniques de programmation telles que le WebSocket est souhaitable ; L application téléphonique est de type «stand alone» (versus un mode intégré au LRM et/ou au SIG). Le type «stand alone» permet de limiter l adhérence entre le fonctionnement du LRM/SIG et celui de la téléphonie, il diminue ainsi les cas de pannes potentielles ; L application téléphonique dispose d un écran entier en zone d affichage. Les agents disposent a minima de trois écrans : un pour la gestion de l application téléphonique, un pour LRM, un pour le SIG ou autres systèmes à la décision. Il est envisagé un quatrième écran, permettant d avoir le SIG affiché en permanence ; Classification : Public 66 / 113

67 Un couplage «faible» avec le LRM et le SIG, bidirectionnel par échange de message est souhaitée. L intégration peut-être «server side» ou «client side» : o Soit l application téléphonique diffuse des événements (prise d appel, raccroché, ) aux applications clientes (LRM, SIG). L application cliente est libre d agir ou non suivant le type d informations véhiculées ; o Soit l application téléphonique expose une API lui permettant d être pilotée par une application cliente (composer un numéro, raccrocher, mise à jour de données attachées à l appel, changement d état, ) ; Une capacité à tenir la charge : l application téléphonique doit être capable d absorber les pics de charges sur un seul datacenter sans dégradation de la qualité de service ; Forte disponibilité Demande d informations CTI-PRES-1 Présentation du service de Couplage Téléphonie Informatique Pour répondre à nos besoins, pouvez-vous présenter les éléments structurants/différenciants de votre service CTI notamment : Architecture de la solution : produit éditeur/développement spécifique, localisation des composants, résilience ; Éditeur de la solution, technologies utilisées, langages, protocoles et standard supportés ; Dimensionnement : nombre maximum d appels simultanés, nombre d agents maximum (conseiller et superviseur). Votre solution est-elle capable d interagir avec des bandeaux externes? Quelles interfaces, APIs, utilisez-vous? CTI-PRES-2 CTI-PRES-3 CTI-INTE-1 Préciser les éventuelles contraintes et limitations, liées notamment à des actions faites depuis le poste téléphonique. Par exemple, désynchronisation du bandeau et du téléphone si le décroché/raccroché (ou changement d état ) est fait depuis le téléphone ou un softphone. La solution permet-elle nativement une personnalisation avancée de l interface à plusieurs échelons : globale, CRRA et agent? Préciser. Intégration avec la téléphonie Quelles sont les contraintes d interconnexion du service de Couplage Téléphonie Informatique avec le service de téléphonie? Préciser les architectures utilisées (connecteur spécifique, protocole/langage) et les fonctionnalités offertes pour chacune des interconnexions : pilotage de l état du téléphone, fonctionnalités téléphonique depuis le bandeau, statistiques sur l appel, statistique sur le centre d appel, etc. Préciser les normes et interfaces supportées (en particulier CSTA - ECMA-269, 6th Edition). Préciser la liste des constructeurs et opérateurs ToIP avec lesquels le service de Couplage Téléphonie Informatique est compatible et/ou certifié (préciser). CTI-INTE-2 CTI-INTE-3 Préciser les prérequis techniques et économiques en termes de licence. Quelles sont les contraintes et limitations pour le service de Couplage Téléphonie Informatique dans un environnement SIP? Préciser les impacts éventuels au niveau de l architecture. Dans l hypothèse où vos solutions couvrent les fonctionnalités IPBX et CTI, pouvezvous nous indiquer les avantages et inconvénients de recourir à une solution intégrée plutôt qu à deux solutions dissociées? Classification : Public 67 / 113

68 CTI-INTE-3 CTI-INTE-4 CTI-INTE-5 CTI-INTE-6 CTI-INTE-7 CTI-INTE-8 CTI-INTE-9 CTI-SPRV-1 CTI-SPRV-1 Intégration avec applications tierces Préciser les modalités d interfaçage avec le LRM (en client léger) pour la création automatique d un DRM sur traitement d un appel : Lien d intégration client side, server side ; Protocole de communication ; Prérequis technique. Préciser les modalités d interfaçage avec le SIG (en client léger) pour l affichage de la localisation de l appelant : Lien d intégration client side, server side ; Protocole de communication ; Prérequis technique. Préciser les modalités d interfaçage avec l enregistreur pour piloter l enregistrement : Lien d intégration client side, server side ; Connecteur ; Protocole de communication ; Prérequis technique. Préciser les bénéfices et limitations d une intégration client side et d une intégration server side. Préciser les modalités d interfaçage avec des annuaires du marché : Lien d intégration client side, server side ; Connecteur ; Protocole de communication ; Prérequis technique. Interconnexion avec le service ACD Quelles sont les contraintes d interconnexion du service CTI avec le service de distribution d appels? Pouvez-vous distinguer les cas d un ACD associé à un IBPX, de celui d un ACD associé à une solution ACD logicielle? Quelle est l architecture nécessaire (interconnexion directe ou via un connecteur, langages de dialogue )? Préciser la liste des éditeurs ACD avec lesquels le service CTI est compatible. Préciser le cas échéant les contraintes et limitations à la transmission des éléments de contexte de l appel du service ACD au service CTI. Supervision activité du CRRA Précisez votre capacité à proposer à chaque agent une vue synthétique de : L état des positions du centre d appels (du CRRA d où il opère) ; L état des salles d attentes propres au CRRA. Dans le cadre d un processus de supervision globale : Pouvez-vous préciser les indicateurs que votre solution est capable de remonter? Pouvez-vous préciser d autres indicateurs qu il vous semble pertinents de remonter? Classification : Public 68 / 113

69 CTI-CAPA-1 CTI-CAPA-2 CTI-CAPA-3 Salles d attente et gestion d appel Quelles sont les possibilités d interaction offertes à l agent (via l IHM) sur les appels des salles d attentes? Sélection et prise de l appel ; Modification de priorité ; Déplacement vers une autre salle d attente ; Autre possibilité (à préciser). Préciser votre capacité et les prérequis à l implémentation d une fonction de gestion d une «blacklist» et «graylist» pour les appelants malveillants/fax/etc. (dépriorisation, renvoi permanent ou temporaire vers SVI)? Préciser votre capacité à implémenter une fonction de gestion d une «whitelist» pour les appelants «VIP» (priorisation)? CTI-INTX-1 IPv6 La solution que vous proposez est-elle compatible IPv6? En mode nominal ou dualstack? 4.3 Informations sur les composants connexes au système Enregistrement des conversations téléphoniques Besoins Cette partie décrit les besoins et les informations structurantes pour offrir un Service d enregistrement dans le cadre du projet de modernisation du SI-Samu. Dans le cadre des appels au Samu, la communication et tous les échanges réalisés (et donc l enregistrement sonore associé), sont considérés comme des éléments du dossier médical. Cela implique : Une traçabilité de l appel ; La possibilité de réécouter l appel immédiatement ; L archivage et la conservation afin de réécouter et réutiliser l appel à n importe quel moment. Chaque établissement de santé est tenu de constituer un dossier médical pour chaque patient hospitalisé, comme indiqué dans l article R du Code de la Santé Publique. Le service d enregistrement intervient dès que l appel est pris en charge par l opérateur de service. L intégralité de la communication doit être enregistrée, ce qui inclut naturellement tout le cycle de vie de l appel : Le passage dans le SVI ; La mise en garde de l appel ; L appel de consultation vers un tiers ; La conférence. Par extension, et au-delà des échanges téléphoniques, il est essentiel de pouvoir enregistrer toutes les communications échangées quels que soient les supports et/ou médias utilisés. Aussi le service d enregistrement doit pouvoir prendre en compte toutes les communications suivantes : La téléphonie entrante (incluant le SVI) ; Classification : Public 69 / 113

70 La téléphonie sortante ; La radio voix entrante ; La radio voix sortante ; Les communications internes ; Les autres canaux (vidéo par exemple). L enregistrement des échanges téléphoniques et radio sont des documents à joindre au dossier médical, à des fins de traitement opérationnels mais également si besoin à des fins juridiques. À ce titre, ils sont régis par les règles de conservation et de destruction identiques à celles d une archive publique. Les hypothèses à ce jour sont un délai de conservation sur les enregistreurs avant le stockage dans les archives légales de 30 jours, le délai de conservation en archivage étant de 10 ans. Il est nécessaire que l enregistrement réponde aux exigences suivantes : L enregistrement doit continuer de fonctionner dans tous les modes dégradés dont celui de l ultime secours (perte du site central) ; L intégralité de la communication doit être enregistrée ; L enregistrement doit être ré-écoutable immédiatement ; L enregistrement doit pouvoir être indexé dans le LRM afin de pouvoir remonter l ensemble des enregistrements lié à un dossier médical. À noter que les infrastructures «Radio» sont déployées en local sur chaque Samu et que la fonctionnalité d enregistrement des communications radio est déjà implémentée dans tous les Samu bénéficiant d un Gestionnaire de Voie Radio (une présentation des services radio est fournie en annexe 5.5 du présent document). Par ailleurs, du fait qu il est légalement interdit d enregistrer des appels personnels, seuls les appels passés dans le cadre des missions du SI-Samu seront enregistrés. De par les exigences et les contraintes juridiques, il est à priori nécessaire de mettre en place des équipements centraux d enregistrement, répartis sur les datacenters de l opérateur de service mais aussi des équipements locaux d enregistrement, répartis sur les sites locaux des CRRA. En mode nominal, le service est assuré aussi bien par les enregistreurs en local avec remontée des informations en central. En mode dégradé, il est nécessaire que les enregistrements soient toujours disponibles pour être écoutés en local. La solution doit être hautement disponible et la bascule primaire/backup de la solution ne doit pas perturber les enregistrements en cours. Il ne doit pas y avoir de perte d enregistrement des communications ni d impact sur les statistiques associées. Plusieurs cas de mode dégradé sont possibles : L un des deux datacenters hébergeant la solution d enregistrement est en dysfonctionnement total ou partiel ; Les deux datacenters hébergeant la solution d enregistrement sont en dysfonctionnement total ou partiel ; La solution d enregistrement en local est en dysfonctionnement total ou partiel ; Le CRRA n est plus accessible (partie voix) en TDM mais en IP via le réseau MPLS ; Le réseau IP-MPLS entre l opérateur de service et le CRRA local est en panne. L un des deux datacenters hébergeant la solution d enregistrement est en dysfonctionnement Classification : Public 70 / 113

71 Dans ce cas, la solution étant hautement disponible, une bascule doit se faire automatiquement sans impact sur l activité en cours. Les deux datacenters hébergeant la solution d enregistrement sont en dysfonctionnement Dans ce cas, c est la solution d enregistrement en local qui assure seule le service. La solution d enregistrement en local est en dysfonctionnement total ou partiel Dans ce cas, c est la solution d enregistrement en central qui assure seule le service. Le CRRA n est plus accessible en TDM mais en IP via le réseau MPLS Dans ce cas, la solution de d enregistrement doit pouvoir continuer à fonctionner normalement. Le réseau IP-MPLS entre l opérateur de service et le CRRA local est en panne Dans ce cas, c est la solution d enregistrement en local qui assure seule le service. La fourniture du service d enregistrement est encadrée par des exigences opérationnelles fortes : Une haute disponibilité du service en 24/7 ; La capacité à enregistrer la communication de bout en bout, en particulier avec tous les segments d appels que l on peut rencontrer lors de transfert d appel et/ou de mise en conférence ; Une souplesse dans la réécoute des enregistrements qui doit pouvoir se faire immédiatement par les agents du CRRA ; La capacité à tenir la charge : la solution mise en place doit être capable d absorber des pics d activité sans que le service soit interrompu ; Une résilience forte de la solution pour répondre à tout type d incident de fonctionnement et permettre la continuité du service ; Une capacité industrielle de la solution du service d enregistrement pour faciliter son déploiement et maitriser l évolutivité et la pérennité de la solution. L'orientation actuelle est de préférer un enregistrement dual/central (double enregistrement) à un risque de perte d enregistrement. Pour plus d information sur l intégration des réseaux radio, se référer à l annexe Demande d informations RCR-CTLS-1 Catalogue de services Pour répondre à nos besoins, pouvez-vous présenter les éléments structurants/différenciants de votre service d enregistrement, notamment : Gestion de la réécoute ; Gestion de l enregistrement en local et en central ; Intégration éventuelle avec gestion des autres médias (radio, desktop, vidéo,..) ; Stockage/archivage. RCR-PRES-1 Présentation de l enregistreur Pouvez-vous mettre en évidence les points forts de votre solution notamment sur les points suivants : Architecture de la solution : composants, résilience ; Éditeur de la solution (si solution tierce), technologies utilisées, langages, protocoles et standards supportés ; Dimensionnement : nombre maximum d appels simultanés Classification : Public 71 / 113

72 (enregistrement concurrent) ; Gestion de l enregistrement des appels en «parcage» (attente de mise en relation) et mise en attente (conservation de l appel dans la salle de l agent). RCR-CAPA-1 RCR-CAPA-2 Gestion de la capacité Quelles sont les limites de la solution en termes de positions, d interactions simultanées, de volume de stockage, de capacité de réécoute, etc...? Les Samu doivent faire face à des pics de charge dus à des crises. Il peut s'agir de crise à cinétique rapide (accident industriel type AZF) ou lente (épidémie de grippe). Pouvez-vous préciser votre capacité à provisionner X canaux supplémentaires et le délai associé (entrante et sortant) pour les rendre opérationnels : (Voir la taille des pics d appels, 5 K appels simultanés en nominal, 15K en pic) 100 canaux voix ou autres média (ex radio) ; 500 canaux voix ou autres média (ex radio) ; 1000 canaux voix ou autres média (ex radio). RCR-ADMN-1 Administration de la solution Pouvez-vous préciser si des outils d'administration fonctionnelle sont disponibles ainsi que la liste exhaustive des fonctionnalités couvertes. Quels outils d'imports ou de provisioning mettez-vous à disposition (exemple : ajout d'un nouveau CRRA)? L IHM d administration est-elle intégrable dans un portail web? Pouvez-vous préciser l outil correspondant? RCR-ADMN-2 Pouvez-vous préciser s il s agit d un client lourd ou léger? Fournissez-vous des API permettant une intégration informatique des interfaces d administration? Précisez. Pouvez-vous préciser le fonctionnement de la gestion des droits et des rôles? RCR-ADMN-3 Est-il possible de coupler les IHM de la solution à un annuaire LDAP afin de gérer les droits d'accès? Pouvez-vous préciser les contraintes et les incompatibilités éventuelles? RCR-FNCT-1 RCR-FNCT-2 RCR-FNCT-3 RCR-FNCT-4 Enregistrement Pouvez-vous préciser la capacité de la solution à enregistrer l intégralité de l appel incluant notamment le passage dans le SVI, les phases d attente? Pouvez-vous préciser la capacité de la solution à prendre en compte des métadonnées (par exemple le numéro de DRM) et à les restituer («enrichissement de l appel»)? Pouvez-vous préciser les limitations éventuelles de la solution (par exemple, le nombre de données métier)? Pouvez-vous préciser la capacité de filtrage des enregistrements, archivés ou non, et lister les filtres potentiels tels que, par exemple, les données métiers, la date? Pouvez-vous préciser la capacité de réconciliation des enregistrements locaux et centraux : Pour un même appel sur un seul CRRA? Pour un même appel sur plusieurs CRRA? Classification : Public 72 / 113

73 RCR-FNCT-5 RCR-FNCT-6 RCR-FNCT-7 RCR-FNCT-8 RCR-FNCT-9 RCR-FNCT- 10 RCR-FNCT- 11 Pour des appels liés à un même DRM? Pouvez-vous préciser si la solution a la capacité, en standard, d enregistrement : De la radio ; Des échanges de type communication par écrit en temps réel ; De la session du poste de travail ; De la visio ; Autres (à préciser le cas échéant). Pouvez préciser les mécanismes éventuels et les typologies d intégration sur les médias qui ne seraient pas couverts en standard? Pouvez-vous préciser la capacité de la solution à gérer différents types d enregistrements : T2 ; Poste physique ; Agent. Précisez l organe auquel l enregistreur doit être couplé. Pouvez-vous préciser la capacité de la solution à permettre la réécoute immédiate d une communication non terminée? L intégralité de la communication doit pouvoir être réécoutée. Y a-t-il une limitation en termes de nombre d enregistrements ré-écoutables immédiatement? Pouvez-vous préciser si la solution permet de télécharger un enregistrement ou une conversation sur le poste de l agent? (par conversation s entend l ensemble des enregistrements liés à un appel et/ou à un DRM) Quels sont : Les formats de compression possibles? Les taux d'échantillonnage / taux de compression? Pouvez-vous préciser si la solution permet d anonymiser la voix afin de la rendre méconnaissable, tout en restant compréhensible, et ceci à des fins d enseignement? Pouvez-vous préciser si la solution permet de retranscrire la voix en fichier texte : En temps réel? A postériori? Préciser si cette fonctionnalité est disponible en standard ou à l aide d une interconnexion avec un produit tiers. Pouvez-vous préciser si la solution permet la traduction instantanée des enregistrements d appels en langue étrangère? Le cas échéant, pouvez-vous préciser les langues gérées? RCR-STAR-1 RCR-STAR-2 RCR-STAR-3 Stockage Archivage Pouvez-vous préciser l espace de stockage nécessaire pour prendre en compte les volumétries du SI-Samu? Merci de présenter les hypothèses retenues pour le calcul. Pouvez-vous préciser l espace d archivage, en précisant les hypothèses retenues pour le calcul? Pouvez-vous préciser si les enregistrements sont compressés et l impact sur la qualité audio du message archivé? Pouvez-vous préciser si un outil d extraction des fichiers audio et des données relatives à une communication est fourni en standard? Pouvez-vous présenter l outil et les objets en sortie? RCR-STAR-4 Pouvez-vous présenter le système de purge? Classification : Public 73 / 113

74 RCR-STAR-5 Disposez-vous d interfaces de sauvegarde vers des systèmes tiers (NAS, autres)? Précisez. RCR-INTE-1 RCR-INTE-2 RCR-INTE-3 Intégration Pouvez-vous préciser la compatibilité de la solution d enregistrement avec : Les IPBX du marché? Le protocole SIP? Pouvez-vous préciser les limites et contraintes éventuelles? Précisez les modalités d enregistrement en fonction des liaisons. Pouvez-vous préciser les éventuelles licences tierces nécessaires au bon fonctionnement de la solution d enregistrement? Pouvez-vous préciser les capacités d intégration des fonctionnalités de pilotage et de réécoute des enregistrements? Une API pour les fonctions de réécoute/recherche/consultation est-elle disponible? Pouvez-vous préciser l environnement et les contraintes de développement? RCR-STAT-1 Pilotage et données historiques La solution propose-t-elle une IHM de pilotage permettant, quel que soit le média (même la radio) : D afficher des rapports statistiques temps réel? En client lourd ou léger? Existe-il une application Smartphone? D afficher des rapports standards? Des données statistiques unitaires? Agrégées? (préciser l agrégat le cas échéant) RCR-TECH-1 Prérequis Techniques Pouvez-vous nous fournir la matrice de compatibilité des IHM avec : Les systèmes d exploitation? Les navigateurs? RCR-TECH-2 Quels sont les types de bases de données compatibles avec la solution? RCR-TECH-3 RCR-TECH-4 RCR-TECH-5 Pouvez-vous nous fournir la matrice de compatibilité avec les systèmes d exploitation pour la partie serveur? La solution privilégiée est LINUX ; si cet OS n est pas supporté merci d en préciser la raison. La virtualisation est-elle supportée? Le cas échéant, sur quelle plateforme? Préciser les mécanismes concernés. Pouvez-vous préciser si la solution d enregistrement est compatible avec le fait qu en mode nominal l acheminement est effectué par le réseau TDM et en mode dégradé par le réseau IP MPLS? Pouvez-vous préciser les impacts éventuels? Indicateurs / SLA Pouvez-vous préciser le taux de disponibilité maximale de la solution? RCR-SVLA-1 Merci de préciser l élément ou les éléments les plus sensibles de la solution. RCR-SVLA-2 Quels sont les différents SLA sur lesquels vous pouvez-vous engager? Classification : Public 74 / 113

75 RCR-SPRV-1 RCR-SPRV-2 Supervision Pouvez-vous préciser les informations de supervision (alarmes, indicateurs) pouvant être remontées à un système d'hypervision des Samu et celles que vous préconisez particulièrement? Par quel outil et quelle interface? Quels sont les intégrations possibles, l objectif pour le SI-Samu étant d avoir une vue unifiée de son système? Dans le cadre d un processus de supervision globale : Pouvez-vous préciser les indicateurs que votre solution est capable de remonter? Pouvez-vous préciser d autres indicateurs qu il vous semble pertinents de remonter? RCR-RESL-1 RCR-RESL-2 Modes dégradés En cas de mode dégradé, pouvez-vous préciser les conséquences sur les enregistrements des communications? En cas de pandémie, le besoin peut être de fonctionner avec des agents dispersés (ex : télétravail) utilisant des téléphones banalisés (non reliés à la solution de téléphonie du SI-Samu). Pouvez-vous préciser vos offres pour faire face à de telles situations? Quel est le délai de déploiement de ces offres? RCR-INTX-1 IPv6 La solution que vous proposez est-elle compatible IPv6? En mode nominal ou dualstack? Affichage et diffuseurs des informations Les agents du SI-Samu disposent de plusieurs écrans de travail, et de manière générale à minima de 3 écrans : Un écran destiné au LRM. Le multifenêtrage éventuel (fenêtre de recherche) se fait sur le même écran de travail ; Un écran destiné au «bandeau» : le bandeau comprend la vision des salles d attentes, de l état des autres personnels, et plus généralement tout information utile liée à l interaction téléphonique (et en cible, multicanal) ; Un écran destiné à la vision géographique des DRM, de l'offre de soins, des moyens engagés pour un DRM ou à réaliser des actions géodécisionnelles ; Dans le cas d écrans supplémentaires (certains postes de travail possèdent 4 à 6 écrans), l ensemble des éléments supports nécessaires (ROR, recherche d information, intranet, etc.). Si cet écran n existe pas il est partagé avec la partie SIG. Dans le cadre du projet SI-Samu, et du fait de la particularité du métier des ARM, il est envisagé d utiliser l écran bandeau à des fins de diffusions d information (de niveau CRRA ou national, non personnelle) : Certaines informations de supervision sont déjà présentes dans le cadre du bandeau tel qu il est envisagé (état des salles, nombre d appels en attente dans le CRA, état des agents des groupes d appartenance et des personnels en escalade dans le processus) ; Classification : Public 75 / 113

76 De manière complémentaire est envisagée la diffusion des messages complémentaires : o Message informationnel (absence, évènement particulier, MOTD message of the day, etc ) de type local ; o Message urgent de type local (métier ou technique) ; o Message urgent de type national (crise sanitaire, ou évènementiel) ; État synthétique de situation : il s agit de l affichage sur l écran de la situation de supervision chiffrée, qui sera défini par CRRA ou au niveau national (taux de décroché, TMC, ou autre). Il s agit d informations opérationnelles (prise de décision) source de motivation au niveau des agents. L ASIP Santé envisage également le déport d écran et l adaptation de ces informations au support de visualisation : Il n est pas envisagé de déport d information sur des supports de type centre d appels classiques (bandeaux lumineux) ; Il est envisagé un déport d informations sur des supports fixes classiques (télévision), éventuellement couplées à d autres fonctions d informations (mashup) ; Il est envisagé le déport de ces informations sur des supports mobiles (tablette, smartphone). Le répondant est invité à décrire de manière sommaire : Sa capacité à fournir une solution répondant à ces besoins, ou sa capacité à s interfacer avec des solutions tierces ; Un ou des exemples de réalisations effectuées dans ce domaine (en propre ou par une société tierce de type intégrateur) Gestion multicanal Besoins Service multicanal Pour tenir compte des usages actuels et futurs (mobilité, téléassistance, télémédecine), l ASIP Santé souhaite intégrer au SI-Samu des outils de communication prenant en compte les différentes évolutions technologiques prévisibles dans la prochaine décennie. Le «Service multicanal» permet la mise en œuvre de fonctionnalités liées à la réception et à l émission de flux d interactions multicanaux et complète ainsi le service téléphonique a minima par les flux suivants : Les fax ; L ; La visiophonie ; Les demandes de rappels ; Le chat interne ; SMS ; La radio ; Une ou plusieurs applications smartphone à usage grand public et professionnel. La multicanalité repose sur le socle «CTI» afin d offrir un routage / distribution homogène étendu à ces nouveaux canaux. Le couplage CTI, destiné en premier lieu au traitement des appels téléphoniques, sera complété du couplage radio informatique, puis devra progressivement intégrer d autres médias d interaction permettant ainsi des nouveaux usages, comme par exemple la téléconsultation ou la télé-expertise et une meilleure efficacité de la coordination et la mobilisation des moyens d intervention. Classification : Public 76 / 113

77 Cas d usage et de fonctionnement D une manière générale, le traitement des flux multicanaux conserve la logique de distribution d un appel téléphonique. Les principaux usages et fonctionnements de multicanal envisagés sont illustrés et détaillés ci-après. L appel radio : les Samu utilisent la radio pour échanger avec certains de leurs partenaires et ce simultanément à un appel téléphonique (avec le patient et les pompiers sur les lieux). Le programme Antares s inscrit dans le cadre de ces échanges et permet aux SDIS et aux Samu de communiquer via un réseau radio numérique propriétaire crypté. À ce titre, les agents des CRRA sont équipés de postes radio en plus de l équipement téléphonique. Lors de la prise en charge volontaire d une communication radio, le statut de l agent passe automatiquement en indisponibilité afin de ne plus recevoir d autre sollicitation (téléphonique par exemple). Cette gestion du statut nécessite, en plus du couplage CTI, un couplage radio informatique rendu possible par l intermédiaire de Gestionnaire de Voie Radio. Ce couplage peut être réalisé au niveau des IPBX ou de l informatique ; Le Fax : le canal fax est principalement utilisé pour l échange de documents avec les professionnels de santé et avec les unités opérationnelles du Smur pour l émission des feuilles de route. Compte-tenu de la criticité de l émission de la feuille de route, une stratégie multicanale devra être envisagée. Des règles pourront être spécifiées en cas d alerte d un dysfonctionnement d un des canaux, ou encore d émission d information sur plusieurs canaux en parallèle avec des mécanismes d acquittement après plusieurs envois en parallèle, par exemple. L ASIP Santé souhaite également que le flux "Fax" intègre une stratégie de messagerie unifiée et soit donc traité dans le même workflow que les s ; l le canal est principalement utilisé pour l échange d information avec les professionnels de santé, comme par exemple pour la transmission d un ECG par le cardiologue d un patient. Ils ont possiblement vocation à venir enrichir ou être rattachés à un DRM et/ou un patient. Le routage / distribution doit pouvoir se faire suivant des critères issus du destinataire, de l objet du mail ou de l analyse sémantique du contenu ; Les demandes de rappels : dans certaines situations, le patient peut solliciter un rappel par le Samu, les rappels sont automatiquement proposés (mode prédictif ou «preview» selon le paramétrage) aux agents du CRRA. L agent reçoit le rappel avec la visualisation de l ensemble des informations de contexte : type de rappel, cause du rappel, heure du dernier appel du patient. Les rappels peuvent être également initiés via le SVI (surcharge, demande d information non urgente), par une application smartphone Samu ou automatiquement programmés dans le cadre des campagnes de suivi des régulations médicales (lorsqu une intervention a été déclenchée). Les logiques de demandes de rappel sont différentes suivant les organisations internes des différents Samu ; Le chat interne : le chat interne permet les échanges entre agents au sein du centre d'appels ou entre agents de CRRA différents. Ce canal vise à faciliter l entraide même si une communication est déjà en cours (par exemple lorsqu un ARM sollicite l expertise d un MR pour traiter son appel en cours) ; SMS : une solution de gestion des SMS peut être mise en place aussi bien sur des flux entrants que sortants pour permettre par exemple les échanges avec les effecteurs, voire les patients ; MMS : la gestion des MMS en entrant peut permettre à l appelant d envoyer une image du patient, ou de l environnement, afin de faciliter le diagnostic, voire la localisation ; Module d alerte : le SI-Samu intègre un annuaire de ses usagers (et en particulier des urgentistes) permettant une alerte ou une mobilisation rapide de ces personnels (engagement des équipes en situation normale, rappel de personnel en cas de plan Classification : Public 77 / 113

78 ORSEC «nombreuses victimes» par exemple). Cet outil est multicanal et interfacé avec le SI-Samu ; Application smartphone : une application de type «smartphone» est envisagée afin d être mise à disposition des patients et des professionnels de santé. Cette application s apparente à un moyen de communication multicanal avec le Samu. L usage «patient» permettra de solliciter le Samu en signifiant le degré de l urgence (permettant de prioriser l appel ou au contraire de l inscrire dans une filière de rappel), de transmettre sa géolocalisation exacte et des éléments non vocaux (entifiant National de Santé, documents, flux vidéo ou audio, etc.). L usage «professionnels de santé» a pour objet de faciliter les échanges entre professionnels de santé et médecins régulateurs, d accélérer l accès à la régulation médicale, de déclarer des informations administratives. Par ailleurs, le SI-Samu souhaite mettre en place un système d escalade : A minima multicanal, pour pouvoir adresser un message d alerte sur plusieurs canaux à la fois en fonction des acteurs engagés et des besoins propres, et de piloter le renvoi d une information critique si son premier envoi a échoué ou n a pas été acquitté sur un canal donné ; Voire cross canal, pour envisager le traitement du message sur plusieurs canaux et gérer les situations de mobilité (par exemple : je reçois l alerte par SMS et j acquitte ou j informe sur les actions à donner sur une application smartphone). Fonctionnalités attendues du service de multicanal Le routage intelligent des flux multicanaux au même titre que les appels téléphoniques. Si le demandeur est un patient et qu il figure dans le référentiel patient, l interaction est routée vers le CRRA rattaché à son lieu de résidence, quel que soit le média utilisé ; La visualisation graphique des interactions entrantes dans les salles d attentes. Les salles d attentes sont multicanales et contiennent indifféremment tous types d interactions classées selon leur priorité, avec un indicateur sur le media concerné ; L affichage des informations sur l interaction lors de la soumission à l agent ; Le pilotage graphique des interactions entrantes: sélection pour traitement d un /fax/visio, le transfert direct (appelé aussi transfert aveugle) /accompagné (appel du destinataire au préalable) / transfert supervisé (conférence à trois pour transfert de contexte), le changement d état, la mise en attente, la mise en conférence, etc. La priorisation du flux suivant le degré d urgence lorsque l analyse est possible ; La distribution des flux multicanaux selon la compétence, la disponibilité de l agent, et les organisations en place ; La gestion des flux radiophoniques ; L historisation des interactions multicanales ; La détection de la langue et la traduction simultanée en langue étrangère ; L émission d appels sortants en mode prévisualisation ou prédictif ; Les échanges entre agents au sein du CRRA ou entre CRRA ; La capacité de communication avec des applications clientes : LRM pour la création du DRM et SIG lorsque les informations de géolocalisation sont disponibles ; L enregistrement et la réécoute : enregistrement des appels sortants, des appels radio et la réécoute de ces enregistrements. Pour répondre aux besoins, l interface graphique de l application multicanale devra être adaptable selon le profil utilisateur (ARM, MR, autres personnels de santé) et son CRRA d appartenance. Principes structurants Pour délivrer le service multicanal, les principes suivants sont considérés comme structurants dans la solution pressentie : Classification : Public 78 / 113

79 En termes d IHM, le service multicanal en reprend les principes déjà énoncés (client léger, stand alone, couplage lâche, scalabilité, disponibilité) ; Le media blending : l agent doit être en capacité de traiter simultanément plusieurs interactions dont un appel téléphonique et une communication radio, un ou plusieurs s ; Dans le cas des communications sortantes critiques, le système doit permettre la mise œuvre de scénarii d escalade sur un autre média, voire plusieurs, en cas d échec de la transmission initiale (ex : impression feuille de route). Pour plus d information sur l intégration des réseaux radio, se référer à l annexe Demande d informations MCN-CTLS-1 Catalogue de services Pour répondre à nos besoins, pouvez-vous présenter les éléments structurants/différenciants de vos services contribuant au multicanal notamment : Type de média pris en charge et intégrés dans une même solution ; Affichage des informations de l interaction ; entification et authentification ; Media blending, multi-interaction ; Statistiques personnelles ; Supervision de l activité du centre d appels ; Fonctionnalité de messagerie instantanée. MCN-PRES-1 MCN-PRES-2 Présentation du service de traitement multicanal Pouvez-vous présenter les caractéristiques et fonctionnalités du traitement d Méthode de classification ; L éditeur (si outil ou moteur tiers intégré dans la solution, précisez). La solution permet-elle nativement une personnalisation avancée de l interface à plusieurs échelons : globale, CRRA et agent? MCN-FNCT-1 Fonctionnalité Dans le cadre de son activité, un ARM a des tâches à réaliser après le traitement de la communication. Par exemple, il doit rappeler un ES sous 4h pour valider le bon accueil du patient. Pouvez-vous préciser si la solution a la capacité de générer des tâches de type back office ou demande de rappel planifiée x heures après la gestion d une interaction? Le cas échéant, en présenter le fonctionnement. La solution est-elle capable d annuler la tâche si celle-ci a été effectuée avant la date/heure prévue, y compris par un agent tiers? Pouvez-vous présenter la fonctionnalité de Media blending? MCN-FNCT-2 MCN-FNCT-3 À quel niveau est effectué le paramétrage/configuration : au niveau de l agent, d un groupe d agents, à un autre niveau? Pouvez-vous préciser? Peut-on appliquer un calendrier (par exemple, un agent traite de l et de la voix le matin, et l après-midi il ne traite que de la voix)? Pouvez-vous préciser comment est réalisée l adjonction et l activation de nouveaux média (API, méthode d intégration)? Classification : Public 79 / 113

80 MCN-INTE-1 Intégration avec la radio (ANTARES) Avez-vous déjà réalisé une intégration avec de la radiophonie? Le cas échéant pouvez-vous préciser les architectures utilisées (connecteur, composant spécifique, protocole/langage) et les fonctionnalités offertes : fonctionnalités à partir du poste radio, fonctionnalités depuis le bandeau Pouvez-vous fournir la liste des constructeurs et éditeurs radio avec lesquels le service de Couplage Téléphonie Informatique est compatible et/ou certifié? Pouvez-vous préciser les prérequis en termes de licence? MCN-INTE-2 Intégration avec des applications tierces Pouvez-vous préciser les modalités d interfaçage avec le SIG (en client léger) pour l affichage de la localisation de l appelant? Lien d intégration client side, server side ; Protocole de communication ; Prérequis technique. MCN-INTE-3 MCN-INTE-4 Pouvez-vous préciser les modalités d interfaçage avec l enregistreur pour piloter l enregistrement? Lien d intégration client side, server side ; Connecteur ; Protocole de communication ; Prérequis technique ; Prérequis en termes de licences. Pouvez-vous préciser les bénéfices et limitations d une intégration client side et d une intégration server side? MCN-SPRV-1 MCN-SPRV-2 MCN-SPRV-3 MCN-STAT-1 Supervision Pouvez-vous préciser votre capacité à proposer une solution permettant à un hyperviseur (au niveau CRRA ou national) de visualiser les usages de canaux? Pouvez-vous préciser les informations de supervision (alarmes, indicateurs) pouvant être remontées à un système d'hypervision du Samu? Par quel outil et quelle interface? Quels sont les intégrations possibles, sachant que l objectif pour le SI-Samu est d avoir une vue unifiée? Dans le cadre d un processus de supervision globale : Pouvez-vous préciser les indicateurs que votre solution est capable de remonter? Pouvez-vous préciser d autres indicateurs qu il vous semble pertinents de remonter? Pilotage et données historiques Pouvez-vous préciser votre capacité à proposer à l agent l affichage : Des statistiques «multicanal» individuelles? Des statistiques «multicanal» du centre d appels (CRRA)? Des statistiques individuelles par canal? Des statistiques par canal du centre d appels (CRRA)? De son historique personnel de la journée? Classification : Public 80 / 113

81 De l historique de dernières interactions traitées par le CRRA? MCN-CAPA-1 MCN-CAPA-2 Salles d attente et gestion des interactions Pouvez-vous préciser la capacité de la solution proposée à gérer une file d attente unique mariant des interactions «multicanal» et à permettre une gestion de picking de l interaction par un collaborateur donné dans cette même file d attente? Pouvez-vous préciser votre capacité et les prérequis à l implémentation d une fonction de gestion d une «blacklist» et «graylist» pour les interactions malveillantes/fax/etc. (dé-priorisation) mais appliquée aux différents canaux? Prérequis Techniques MCN-TECH-1 Quels sont les types de bases de données compatibles avec la solution? MCN-TECH-2 Pouvez-vous nous fournir la matrice de compatibilité avec les systèmes d exploitation pour la partie serveur? La solution privilégiée est LINUX ; si cet OS n est pas supporté merci d en préciser la raison? MCN-TECH-3 La virtualisation est-elle supportée? Le cas échéant, sur quelle plateforme? Préciser les mécanismes concernés Autres fonctionnalités potentielles Le temps estimé pour la mise en place et le déploiement du SI-Samu est de plusieurs années. De fait l ASIP Santé souhaite connaître les prochaines évolutions et usages potentiels qui sont d ores et déjà envisageables. Par exemple, la révolution du smartphone, depuis 2007, a modifié les usages rendant «normal» l usage du téléphone en mode multimédia, apportant sur le même appareil l utilisation de la photo et de la vidéo, principalement en mode asynchrone (prise de photo et envoi). L arrivée de la 4G, et bientôt de la 5G (prévue en 2020) permettront des échanges synchrones d informations multimédia (débit et pénétration dans les bâtiments). La réconciliation de l image et de l appel sera de fait un plus pour le SI-Samu (voir paragraphe Gestion multicanal). De la même manière, l usage de la reconnaissance vocale pour banaliser la demande et la qualification devient usitée et peut être d utilité pour le SI-Samu, usage rendu grand public notamment par le système Siri d Apple. À l inverse, alors que la technologie est mature, l usage des SVVI ou IVVR n a pas d application potentielle pour le SI-Samu. Le répondant est invité à donner une vision de l évolution de ses produits : Dans le domaine de l accueil vocal ; Dans les usages complémentaires liés à la téléphonie IP ; Dans le domaine de la convergence voix-data ; Dans les domaines du stockage de volume d informations importants (enregistrement) et de leur pérennisation ; Dans le domaine de l usage des informations volumineuses (Big Data) ; Ou tout autre domaine permettant de contribuer à l amélioration de la gestion des appels d urgence ou de la coordination des moyens d urgence. Classification : Public 81 / 113

82 4.4 Informations liées à l exploitation de la solution Statistiques d appels Dans le cadre du SI-Samu, afin d améliorer à la fois la qualité de prise en charge des appels et permettre une organisation optimale, l ASIP Santé a des attentes fortes relatives à l exploitation des statistiques. Les statistiques auront plusieurs sources de provenances : L opérateur de service, afin d avoir des statistiques fiables de décrochés/prédécrochés et d aboutement ; L IPBX, afin de connaitre l état des téléphones, les durées d appels, et autres données utiles à la compréhension des cheminements d appels ; L ACD/CTI, qui sera dans un premier temps le référentiel d analyse ; Les autres organes (SVI, enregistreurs, etc.) permettant l enrichissement de l analyse. Trois points particuliers sont portés à l attention des répondants : L unification des tickets (tickets uniques enrichis) du fait des sources hétérogènes, besoin spécifique décrit ci-après (voir chapitre Gestion des tickets d appels/communication et interaction) ; L enrichissement des tickets par les données métiers du LRM. Ce point n est pas traité dans le cadre de cette demande d information, faisant appel à une chaîne externe à la chaîne de traitement téléphonique ; La conservation des tickets et indicateurs dans la durée, afin de pouvoir analyser de manière rétroactive les évolutions et améliorations constatées depuis la mise en place du SI-Samu. De fait, les outils de reporting (à froid), permettant l analyse, seront ceux délivrés directement par les fournisseurs de solutions logicielles et d équipements. Trois éléments sont importants pour l ASIP Santé : La capacité à restituer de manière simple les informations/indicateurs issus des appels, sans soucis d intégration d autres outils d analyse ; La richesse des informations fournies en standard par les outils d analyse ; La corrélation des données entre les différents éléments de la chaîne de traitement des appels (voir également Gestion des tickets d appels/communication et interaction). Le répondant est invité à décrire de manière sommaire : Les interfaces graphiques et logiciels fournis en standard à des fins d observation, d analyse, et de compréhension ; La capacité de la solution fournie à s intégrer en standard avec d autres solutions du marché (utilisation de modèles de représentation préexistants) ; La capacité d export des données et les formats associés, à des fins d analyse par des produits tiers. Par ailleurs le répondant est invité à fournir toute précision qu il juge utile quant à l analyse des statistiques d appels dans le contexte du SI-Samu Supervision des appels À des fins de bonne compréhension des attentes du SI-Samu, le terme supervision étant très large, il sera distingué deux types de supervisions : La supervision technique, qui correspond à une vue de l état du système global en terme de fonctionnement nominal (fonctionnement des processus, état des systèmes Classification : Public 82 / 113

83 supportant les processus, état des équipements). Ce point ne fait pas partie expressément de cette demande d information ; La supervision ou les mécanismes de supervision métier, détaillés ci-après. Dans le cadre du SI-Samu sont attendus quatre niveaux de vues : Au niveau de l agent. L agent a une vue globale de l état des salles d attentes du CRRA auquel il appartient, et de l état des agents du CRRA. Il dispose de fonctions traditionnellement utilisées par le superviseur : o Picking d appel : prise d un appel dans l une des salles d attentes à laquelle il est abonné (chaque agent dispose également de sa propre salle d attente) ; o Dépôt d un appel dans une salle d attente ; o Déplacement d appels entre salles d attente ; Au niveau du CRRA. L attente à ce niveau correspond aux fonctions classiques de supervision (vue de l état des salles, vue d indicateurs avec visuel et alertes, capacité à déplacer des appels, interception d appels, écoute avec «chuchotement», etc.). Il est à noter que le rôle de superviseur d un CRRA peut être mutualisé entre plusieurs CRRA à certains instants de la «journée» (en particulier pour la gestion des horaires de nuit, gestion des absences ou du fait de la simple taille du CRRA concerné) ; Au niveau régional. Pour certains numéros d appels, non 15, mais gérés par les Samu, il pourra être intéressant de disposer d une supervision spécifique liée aux salles d attentes de ces numéros. Dans ce cas il s agira de vues d états statiques (agrégat sur fréquence définie) et dynamiques (temps réels tels que risques de saturation, alertes sur taux de raccroché), sans fonctions d administration, celles-ci étant de la responsabilité des CRRA. Ces indicateurs seront des indicateurs classiques de centre d appels (par exemple le TMC ou temps moyens de communication, EWT ou Estimated Waiting Time, etc..) ; Au niveau national (désigné par hypervision). L ASIP Santé souhaite disposer d une vue générale de l état du SI-Samu vu comme un centre d appels virtuel. En plus des fonctions précitées sont attendues des représentations graphiques (cartes de France, avec drill-down potentiel, vue des entraides notamment). Un modèle envisagé est l activation de fonctions d administration du système (au sens métier) depuis la vue de l hyperviseur, voire du superviseur : activation des scénarios d entraide, élargissement, activation d arborescence SVI. Le couplage pourra être fort (solution intégrée) ou faible (actuellement favorisé, activation de la fenêtre d administration avec passage de contexte). Pour répondre à ces besoins, le répondant est invité à décrire de manière sommaire : Sa capacité à répondre sur sa solution en standard aux besoins exprimés ci-avant ; Sa capacité à répondre à l aide de produits tiers, à l aide d une offre sur étagère, aux besoins exprimés ci-avant, en précisant les parties couvertes et les logiciels concernés ; Sa capacité à fournir des interfaces permettant de remplir le besoin exprimé (le cas échéant, donner une description générale des interfaces fournies). Par ailleurs, le répondant est invité à fournir toute précision qu il juge utile quant à la supervision des appels dans le contexte du SI-Samu Gestion des indicateurs de service L ASIP Santé souhaite pouvoir bénéficier des indicateurs de services traditionnels dans les centres d appels virtuels (vue à plusieurs niveaux, par regroupement géographique, organisationnel ou métier, par numéro appelé). Ces indicateurs peuvent être : Classification : Public 83 / 113

84 Des indicateurs agrégés de composant de service (par exemple durée moyenne des appels en attente). L ASIP Santé attend de la solution qu un certain nombre de ces indicateurs, classiques et état de l art dans le domaine des centres d appels, soient fournis en standard par l équipement ou la solution, ou à minima par des solutions tierces associées. Le SI-Samu devra bénéficier de ces indicateurs en fonction des critères énoncés ci-avant ; Des indicateurs «métier» (par exemple corrélation entre motif d appels et durée de traitement moyenne de l appel). L ASIP Santé envisage de mettre en place des indicateurs complémentaires à ceux fournis en standard par la solution du fait de la spécificité des besoins du SI-Samu. L ASIP Santé envisage de mettre en place des «points de comptage», à savoir des points de mesure associés à un contexte (exemples : nombre de passage journalier dans une branche du SVI pour les story board définis, nombre d appels moyens en rappel associés à des motifs d appels). Pour répondre à ces besoins, le répondant est invité à décrire de manière sommaire : La liste des indicateurs fournis en standard et pouvant correspondre aux besoins exprimés ci-avant ; Les interfaces et/ou méthodes permettant la mise en place des indicateurs «métier», tel qu envisagé précédemment ; L influence éventuelle de la mise en place de ces points de mesure sur les performances de la solution logicielle ou de l équipement. Par ailleurs, le répondant est invité à fournir toute précision qu il juge utile quant à la mise en place de points de mesure dans le contexte du SI-Samu Contraintes d exploitation Gestion des environnements La mise en place du SI-Samu est complexe du fait de deux facteurs principaux : La haute disponibilité du système et la mise en place de mécanisme de résilience. Ce point sera abordé dans le paragraphe suivant (voir chapitre Configuration type de production) ; La capacité d évolution demandée à la solution, afin de prendre en compte à la fois l évolution des besoins, les spécificités de chaque Samu lors des déploiements, et l évolution des technologies. Du fait de la deuxième contrainte, l ASIP Santé souhaite mettre en place une structure d intégration continue, tant sur le plan organisationnel que sur le plan des plates-formes qui supportent le processus d intégration. Le terme de plate-forme désignera tout équipement et/ou logiciel concourant à l objectif visé ; dans ce cadre, l ASIP Santé souhaite disposer : D une plate-forme de développement, permettant à la fois le développement et le paramétrage des solutions logicielles (et/ou matérielles issues d équipementiers) ; D une plate-forme de test, à vocation de réalisation des tests de qualification (ensemble de tests unitaires sur un objet), de tests d intégration (ensemble de tests relatifs à plusieurs objets) et de tests de vérification (plan de tests d intégration, incluant la VNR ou Vérification de Non Régression) ; D une plate-forme de benchmark, permettant les tests de performance, incluant la robustesse ; cette plate-forme pourra éventuellement être utilisée pour les tests de migration logicielle majeure (progiciel, base de données, équipement, système), du fait d une utilisation non-permanente ; D une plate-forme de pré-production, à l identique de la production, à des fins de mise en production («change management»), de reproduction d incident («incident management») et de mise en place de correctif («patch management») ; Classification : Public 84 / 113

85 La présente demande d informations a pour objectif de connaître et de quantifier les contraintes potentielles des équipements et solutions logicielles du point de vue du répondant afin que ses équipements et logiciels soient mis en œuvre selon l état de l art. Le répondant est invité à décrire de manière sommaire : Ses préconisations, de par son expérience et les contraintes liées à ses solutions, quant à la constitution de ces plates-formes / environnements et leur maintien en condition ; À des fins de coûts, notamment pour les plates-formes de tests (unitaires) et de développement, sa capacité à virtualiser sa solution ou à simuler ces environnements ; Sa capacité à fournir des outils complémentaires facilitant la mise en place des plates-formes (gestions de configurations et de restoring), leur utilisation (analyse de logs ou traces), ou leur usage (injecteurs), en propre ou dans le cadre de partenariat (dans ce cas préciser le nom des outils concernés). Les questions relatives à la tarification associée à ces environnements sont traitées au paragraphe Tarification. Par ailleurs, le répondant est invité à fournir toute précision qu il juge utile quant à la mise en place des environnements préparatoires à la production dans le contexte du SI-Samu Configuration type de production La stratégie de production du SI-Samu est la suivante : L accueil vocal sera acheté en mode service à base de serveurs vocaux VXML, afin de garantir la réversibilité ; Un IPBX (au sens logique et physique du terme) sera hébergé dans chacun des datacenters de l opérateur/hébergeur ; Il est envisagé de dupliquer les gateways dans les centres Samu ; L ensemble des autres composants de la chaine primaire (ACD, CTI, enregistreur, etc..) seront redondés au sein de chaque datacenter et dupliqués entre datacenters. Le besoin de l ASIP Santé est de qualifier de manière plus précise l architecture et de quantifier les besoins en hébergement et pour l environnement de production des solutions issues des fournisseurs de solutions ou d équipements, avant l émission des appels d offres, et de soumettre une expression de besoin, en corrélation avec les architectures de production supportées par les solutions et équipements. Le questionnement se pose notamment autour des problématiques suivantes : Capacité de la solution à être virtualisée en production, tout en conservant performance et disponibilité ; Capacité de la solution à être mise en place sur un cloud privé d hébergeur ; Capacité à accepter des solutions de réplication de données (géoclustering, contraintes pour les réplications, etc.) ; Capacité à augmenter de manière rapide, de manière ponctuelle ou permanente, la capacité (scalability). De manière plus générale, le questionnement porte sur l architecture de la solution, notamment sur l identification d une part des éléments devant nécessairement être hébergés sur une machine physique et d autre part des éléments logiques. Le fournisseur de solutions ou d équipements est invité à répondre à ces problématiques : En précisant, à chaque fois qu une solution est possible, les contraintes associées, tant sur le plan technique que sur les impacts générés ; Classification : Public 85 / 113

86 En étayant la réponse, à chaque fois que possible, par un exemple de référence client ayant mis en place ce type d architecture ; En fournissant une description, sous forme de schéma, d un exemple d architecture de production correspondant à la problématique exposée ci-dessus. Les questions relatives à la tarification associée à cette configuration de production sont traitées au paragraphe Tarification. Par ailleurs, le répondant est invité à fournir toute précision qu il juge utile quant à la mise en place et au maintien des environnements de production dans le contexte du SI-Samu. 4.5 Informations transverses Références similaires Références similaires REFS-1 De combien de références similaires et actives disposez-vous? Pouvez-vous en en présenter quelques-unes couvrant selon l étendue de vos produits le plus large spectre de fonctionnalités décrites ci-dessous? Précisez en cochant les cases ci-dessous les thématiques couvertes par les références présentées: Référence 1 : Serveurs vocaux interactifs Fonctions de Téléphonie Intégrations des fonctions IPBX dans un domaine intégrateur Fonctions ACD locale ou centrale Conférences ou communications multi-lignes Service de couplage Téléphonie-Informatique Enregistrement des conversations Affichage et diffuseurs d informations Service de Workforce Management Statistiques d appels Supervision des appels Gestion des tickets d appels/communication et interaction Qualité de Service Gestion du multicanal Référence 2 : Serveurs vocaux interactifs Fonctions de Téléphonie Intégrations des fonctions IPBX dans un domaine intégrateur Fonctions ACD locale ou centrale Conférences ou communications multi-lignes Service de couplage Téléphonie-Informatique Enregistrement des conversations Affichage et diffuseurs d informations Service de Workforce Management Statistiques d appels Supervision des appels Gestion des tickets d appels/communication et interaction Qualité de Service Gestion du multicanal Gestion des tickets d appels/communication et interaction Besoins La solution recherchée est un système de téléphonie sur IP centralisé et à haute disponibilité. Elle est couplée entre autres à : Un système de gestion de centre d appels assurant le routage intelligent, la distribution des appels et le couplage CTI avec le SI-Samu ; Classification : Public 86 / 113

87 Des services d enregistrement et de SVI. Dans le cadre de ces communications, à des fins de statistiques, mais également à des fins de marquage d enregistrements (date, heure, durée), il est nécessaire d unifier les tickets issus d équipements et solutions différents. Ce point est important car il permet d avoir des statistiques fiables remontées vers et par les centres d appels, de mieux appréhender des phénomènes conjoncturels (analyse à froid), et également d injecter les statistiques recueillies dans des modèles de simulation. Le suivi du trafic téléphonique unifié et consolidé sert trois usages principaux : Suivi d un appel de «bout en bout» o Suivi de la qualité de service fournie ; o Suivi de l activité dans les CRRA ; Réconciliation des tickets de toutes les interactions liées à un même dossier de régulation médicale. Cette notion correspond à l ensemble des appels associés à un dossier de régulation médicale ; Référencement des enregistrements des appels à valeur probante pour les appels au 15. Le service de ticket unifié doit couvrir et répondre aux besoins suivants : La possibilité de reconstituer un appel de bout en bout avec un identifiant unique à partir des tickets émis par les différentes briques de la solution : o En mode nominal ; o En mode dégradé ; L enrichissement du ticket : la capacité à attacher un dossier de régulation médicale l ensemble des appels téléphoniques ainsi que les communications radio en y associant des données liées à l appel (qualification, rappel, entraide, ). Le service de ticket doit être intégrable à la solution SI via la fourniture des connecteurs permettant au SI-Samu d exploiter les tickets du système de téléphonie. À titre d illustration, la réconciliation des informations envisagée par le service de ticket unifié doit couvrir le scénario d appel type suivant : Appel TDM au 15 entrant sur le datacenter central ; Traitement par le Call Manager ; Prise en charge par la solution routage/distribution/cti incluant la recherche d un DRM existant ; Passage éventuel par le SVI (et des serveurs de reconnaissance vocale) ; Après identification d un agent, génération d un appel sortant (en TDM ou via WAN) vers l agent situé dans un CRRA ; Réception par la gateway locale de l appel ; Décroché de l appel par l agent avec création automatique du DRM si c est un nouveau patient ; Transfert d appel : l appel peut ensuite faire l objet de transfert local au CRRA ou non (entraide sur compétence spécialisée) ; Enregistrement des appels (en central et/ou en local). Par ailleurs, un appel entrant produit en général des appels sortants ainsi que des communications radio (Antares), des fax ou impressions, voire des s. On souhaite pouvoir corréler ces différents appels à un même DRM. Les tickets liés à la mise en conférence des appels sont traités avec les conférences (voir chapitre dédié Conférence ou communications multi-lignes) : Suivi d un appel (identifiants de l appel avant/pendant une conférence) ; Réconciliation des appels appartenant à une même conférence. Classification : Public 87 / 113

88 Demande d informations TUN-STRD-1 TUN-STRD-2 TUN-STRD-3 TUN-STRD-4 TUN-STRD-5 TUN-STRD-6 Génération de tickets d appels Ticket d appel dans la solution de téléphonie Préciser les composants de la solution qui génèrent des tickets et les principaux champs générés : Call managers ; Gateway ; ACD ; SVI ; Enregistreur local et/ou central ; Application routage/distribution/cti (par serveur au besoin). Pour le scénario type, préciser les tickets générés au fur et à mesure de la progression de l appel, et les champs significatifs du ticket : entifiant de l appel ; Appelant ; Appelé ; Liaison ; Sens (sortant/entrant) ; Durée ; Agent ; Salle d attente ; Statut de terminaison inefficace, abandonné, etc. ; Autres (à préciser). Préciser les sous-ensembles de composants qui partagent la même référence d appel dans la solution proposée? Préciser comment une référence commune peut être partagée entre les sousensembles de la solution utilisant chacun sa référence propre. Préciser les mécanismes permettant de partager/transmettre une référence commune d appel pour disposer d une vue de bout en bout d un appel? Par échange de signalisation? Via le lien CTI? Stockage dans un champ du ticket d appel? Exemple de liens à illustrer dans la réponse : Entre la solution IPBX et l application routage/distribution/cti ; IPBX avec des éléments périphériques tels que les enregistreurs le SVI ; Autres. Préciser comment peut être modifiée (si besoin) la logique par défaut d association (règles, développements)? Aboutement d appels entre le datacenter et le CRRA : Préciser comment une consolidation entre l appel entrant en central et l appel abouté est réalisée? Cas d un appel sortant TDM : appel TDM entrant enregistré sur la gateway et appel entrant enregistré sur le datacenter? Cas d un appel sortant via le WAN? Classification : Public 88 / 113

89 TUN-STRD-7 TUN-STRD-8 Transferts d appel : Dans le cas de transfert d appel, pouvez-vous préciser l aptitude de la solution proposée au : Maintien d un identifiant unique d appel lors d un transfert d appel? Maintien de l appelant d origine (A) dans le ticket (A appelle-> B transfert vers C destinataire)? Cas de l appel attaché/détaché dans une conférence Y a-t-il un impact sur l identification des appels liés à une conférence? TUN-INTE-1 TUN-INTE-2 TUN-INTE-3 TUN-INTE-4 Intégration Préciser l architecture de stockage/exploitation des tickets. Préciser le niveau de consolidation pouvant être obtenu dans le cadre de l architecture SI-Samu pressentie (ex : ticket agrégé représentant la communication de bout en bout et masquant les multiples bases de tickets utilisées). Relativement aux outils de statistiques : Quels sont les outils de reporting standards mis à disposition? Quelles sont les statistiques disponibles? Y a-t-il des agrégats générés (relatifs au ticket d appel et au besoin décrit ci-avant)? Quels sont les outils de requêtage standards? Préciser les interfaces/outils d export mis à disposition permettant d explorer les tickets dans un outil BI? Export de fichier ; Formats de fichier : csv, etc. ; Web service ; Autre (à préciser). Dans l hypothèse où des développements sont nécessaires pour disposer d un ticket unique : ces développements peuvent-ils être conduits par des tiers (autre que le fournisseur et/ou intégrateur certifié)? Sur la base de quels prérequis? TUN-RESL-1 TUN-RESL-2 TUN-RESL-3 Mode dégradé Dans le cas d une perte du réseau WAN (sites téléphoniques isolés), quel est l impact sur : La production des informations de tickets décrite précédemment? La production et stockage local de tickets par les gateways? Y a-t-il une consolidation a posteriori après rétablissement du réseau? Dans le cas de la perte du datacenter actif et donc de la bascule sur le datacenter passif, préciser les contraintes et prérequis permettant de conserver la notion de ticket unifié. Préciser comment le dispositif permet d'enregistrer et signaler explicitement une rupture/un incident (de type perte d'information le cas échéant) dans l'enregistrement des tickets. Classification : Public 89 / 113

90 Traçabilité et Consolidation des interactions au niveau DRM Le Dossier de Régulation Médicale correspond au traitement d un patient par le Samu, pour un évènement donné. Sa durée de vie type est de quelques heures. À un DRM sont liés n appels successifs ou parallèles, entrants ou sortants et des communications radio voire des s. Les appels sont couplés (ou pas) à un DRM via l application CTI. Enregistrement des communications radio TUN-STRD-1 TUN-STRD-2 Contexte : un agent régulateur «prend» une communication radio ce qui modifie son état d occupation dans le système CTI (non disponible). Préciser comment il est possible d intégrer, dans les métadonnées de l enregistrement, la référence du DRM concerné par la communication radio prise en charge par l agent? Pouvez-vous préciser la capacité de la solution à retrouver/exporter des communications (log, enregistrement) à partir de la référence (DRM)? Qualité de service Besoins L objectif de la demande est de connaître les éléments, fournis en standard par les répondants, permettant un contrôle du fonctionnement des composants (disponibilité, efficacité, performance). Cette connaissance des composants de l architecture technique doit permettre d identifier les possibilités de supervision globale du système. Chaque répondant à la présente demande d information est invité à présenter ses engagements standards et à préciser les moyens mis en œuvre pour les respecter. Outre les engagements minimaux demandés ici, les répondants sont libres de proposer tout autre indicateur pertinent, à condition de respecter le formalisme demandé, c'est-à-dire décrire pour chaque indicateur : Sa définition (texte et formule de calcul) ; La valeur de l engagement ; Les limites éventuelles de l engagement. Engagements de qualité de service L ASIP Santé a besoin d une solution fiable et performante, ayant une haute résilience de fonctionnement et une forte résistance aux pannes. Des engagements sur la disponibilité et les performances du service sont donc demandés. Les activités du Samu Centre 15 étant en 24*7, ces engagements sont pris sans restriction d application horaire. Ainsi, la fonction de phonie des Samu ne peut tolérer une panne de plus de 5 minutes par an. La solution de téléphonie doit donc avoir une disponibilité 5-9. Toutefois la perte de disponibilité de certains services non critiques, comme par exemple le service de reporting seul, n est pas considérée comme une perte de disponibilité du service de téléphonie. De ce fait, le répondant sera invité à fournir tout indicateur, architecture et méthodologie garantissant à la fois la disponibilité et la résilience (voir chapitre La haute disponibilité). L ASIP Santé a également besoin d une réactivité forte de l opérateur économique titulaire du marché en cas d incident. Classification : Public 90 / 113

91 Dans ce cadre, l ASIP Santé souhaite avoir 4 niveaux d engagement de qualité de service : SLA Niveau 1 : correspond aux biens (composants) de sensibilité classée faible ; SLA Niveau 2 : correspond aux biens (composants) de sensibilité classée sensible ; SLA Niveau 3 : correspond aux biens (composants) de sensibilité classée stratégique ; SLA Niveau 4 : correspond aux biens (composants) de sensibilité classée maximale. SLA : Service Level Agreement ou Engagement de Qualité de Service Typologies des services versus niveaux d engagement de service Le tableau ci-dessous propose et décrit des grandes typologies de services par niveau d engagement de services. Cette liste (non exhaustive) et le découpage sont donnés à titre d illustration donnant une idée de l orientation de la volonté de l ASIP Santé et n ont aucune valeur contractuelle. Sensibilité classée «faible» : o Service de reporting ; o Service Workforce management ; o Service de synthèse vocale ; o etc. Sensibilité classée «sensible» : o Service ticket unifié ; o etc. Sensibilité classée «stratégique» : o Service routage et distribution appel ; o Service couplage téléphonique informatique ; o Service supervision ; o Serveur vocal interactif ; o Serveur d enregistreur ; o etc. Sensibilité classée «maximale» : o Service de téléphonie ; o Service de commutation ; o Gestion des fax ; o etc. Engagements de disponibilité Le service est ouvert et en service 24h sur 24, 7j sur 7 toute l année. Les opérations de maintenance ne doivent pas entrainer de perturbation du service perçu par les utilisateurs. Toute opération de maintenance devra faire au préalable l'objet d'une analyse d'impact sur la disponibilité théorique du système. Les engagements en termes de disponibilité (voir section «Engagement de Performance») de la solution porteront notamment (liste non exhaustive) sur les points suivants (par composant unitaire, hors redondance des datacenters) : Classification : Public 91 / 113

92 Appels Voix Faible Stratégique Maximale Demande d information Téléphonie et Centre d Appels Sensibilité Thème Désignation Disponibilité IPBX Disponibilité de l équipement central 99,99% Gateway Téléphonie Disponibilité de la téléphonie locale 99,99% Fax Disponibilité de la solution d enregistrement Disponibilité de la réception des feuilles de route Disponibilité des équipements d enregistrement 99,99% 99,97% Service vocal interactif Accès pour l appelant 99,97% ACD Solution ACD couplée à la brique CTI 99,97% Service de couplage téléphonie informatique Serveurs de bandeaux Brique CTI (interconnexion avec IPBX) Organe gérant les bandeaux des ARM (Agents) 99,97% 99,97% Supervision Supervision métier des appels 99,97% Sensible Gestion des tickets d appels Gestion des tickets unifiés et enrichis 99,90% Reporting Gestion des statistiques et des exports 99,80% Workforce Management Voir description des fonctions chapitre Workforce management 99,80% Synthèse Vocale Synthèse des messages de type asynchrone 99,80% Engagements de performance Les engagements de performance sont envisagés par partie de système. Chaque répondant est invité à apporter les commentaires qu il juge utiles dans son domaine d activité. Domaine Désignation Performance Taux de reconnaissance vocale en Keywords spotting 99,5% Taux de reconnaissance vocale en langage naturel 95,0% Qualité de la voix Délai de décroché d appel SVI, à 100% de taux d occupation des ports de communication À proposer <0,3 s Délai d établissement d un appel (mesuré depuis la demande de routage (fin de qualification) jusqu à la mise en relation en décroché automatique <0,8s Taux d aboutement d appels (mesuré par semaine, hors saturation 99,999% Classification : Public 92 / 113

93 Enregistrement Bandeaux (*) Demande d information Téléphonie et Centre d Appels d agent et hors raccroché volontaire appelant) Taux de charges des équipements (mémoire et capacité processeur) gérant le routage ou la distribution d appel, l enregistrement ou la supervision (par serveur, par période de 10 min mesurée, en capacité maximum théorique) <70% Temps d établissement de communication (appel sortant) <1s Temps de réponse du bandeau sur évènement téléphonique (hors latence réseau) <0,3s Temps de réponse sur message urgent (diffusion des messages sur l ensemble des bandeaux, base agents connectés) Temps de rafraîchissement des files d attente (nécessité d une vue cohérente pour le métier lié aux ARM, bases agents connectés) < 2s <1s Taux d enregistrement des appels 99,99% Temps d accès à un enregistrement (son) enregistré dans la minute <1s Temps d accès à un enregistrement (son) enregistré à moins d 1 <3s mois (*): Le bandeau téléphonique sera redéveloppé spécifiquement pour le SI-Samu sur la base d'api mises à disposition par le logiciel CTI Demande d informations Références similaires QOS-REFS-1 Avez-vous des références similaires et significatives offrant et mettant en œuvre des exigences de disponibilité telles qu envisagées par l ASIP Santé? Pouvez-vous décrire les principaux indicateurs utilisés, les éléments d architecture mis en œuvre ainsi que la méthodologie employée permettant de garantir la disponibilité et la résilience de la solution?? Engagements Les questions ci-dessous réfèrent aux paragraphes engagements de disponibilité et engagements de performance. Il est demandé aux répondants de répondre à chaque question dans un premier temps concernant les critères de disponibilité et dans un second temps concernant les critères de performance. QOS-ENGA-1 QOS-ENGA-2 Pour chaque objectif de disponibilité listé ci-dessus, préciser si : Vous souscrivez sans réserve à l atteinte de cet objectif ; Le niveau d engagement standard pour le critère défini ; Le niveau d engagement maximal envisageable avec votre solution. Pour atteindre le niveau d engagement de service proposé par le répondant, quelles sont les contraintes, préconisations et éléments d architecture de la solution (composant applicatifs/techniques) à mettre en œuvre? Quelles seraient les limitations et les restrictions au respect de ces engagements? Classification : Public 93 / 113

94 QOS-ENGA-3 QOS-ENGA-4 QOS-ENGA-5 Définition et formule de calcul de SLA Pour chaque objectif de disponibilité fixé, le répondant précise la formule ou la définition qui encadrent les engagements désignés dans la question QOS-DISP-1. Y a-t-il d autres indicateurs pertinents qui pourraient aménager ou compléter le dispositif de SLA envisagé? Préciser les objectifs poursuivis par ces indicateurs. Le répondant précise les modalités conseillées de réalisation des opérations de maintenance, dans un contexte de disponibilité 24/7, 365 jours par an Tarification Besoins L ASIP Santé souhaite connaitre le ou les modèles de tarification standards de chaque vendeur de solutions de centre d appels et de mesurer leur possibilité de souplesse et d adaptation au contexte du SI- Samu. Chaque répondant précise les différents modèles tarifaires qu il peut engager : Achat en mode services ou en mode licences (nommée, flottante, ou à l usage) ; Intégration au modèle de tarification de la scalabilité de la solution (évolutivité, capacité à absorber de manière temporaire ou permanente les quantités d appels simultanés), liée à la montée progressive des CRRA (étalée sur plusieurs années) au sein du SI-Samu et à la gestion de pics d appels pour des évènements de portée nationale. L ASIP Santé étudie également l opportunité d acquérir les licences de la solution de centre d appels en lieu et place d un modèle d achats de services soit dès le début du projet, soit en cours de contrat. Chaque répondant de solution présente la possibilité d un tel mode d achat sur tout ou partie du périmètre de services de centre d appels et les modalités de sa mise en œuvre. Classification : Public 94 / 113

95 Demande d informations TRF-TARF-1 Structure tarifaire Présenter la structure et les modalités tarifaires de l offre couvrant tout le périmètre de services de centre d appels demandés par l ASIP Santé, à savoir les services suivants : Service d acheminement ; Service d appels sortants ; Service d accueil vocal : o Min d appel, canaux voix ; o Prix d activation, usage ; o Maintenance ; o Préciser votre tarification pour l usage des fonctions de o reconnaissance vocale et TTS ; Décrire votre catalogue d unités d œuvre pour les prestations qui ne sont pas incluses dans le prix à l usage du SVI ; Service téléphonique ; Service de conférence ; Service d enregistrement : o Nb appels enregistrés, simultanés ; o Durée et volumétrie enregistrées ; o Type de média enregistré (voix, radio, ) ; o Par fonctionnalité offerte (enregistrement, réécoute, administration, ) ; o Maintenance ; o Autre modalités ou métriques tarifaires (à préciser) ; Service de distribution ; Service de statistique ; Service de supervision ; Service de téléphonie administrative ; Service d afficheurs muraux ; Service de multicanal ; Service de couplage téléphonique informatique : o Mode de tarification position fixe, flottante ; o Maintenance ; Service de ticket unifié. Préciser les métriques utilisées pour les différents composants (hardware, licences, maintenance, nouvelles version, adaptations spécifiques), les prérequis et les règles d usage sous-jacente. Quels éléments auront un fort impact sur le coût de la solution? Pouvez-vous engager un modèle de tarification unique portant sur l ensemble de votre réponse? TRF-TARF-2 Avez-vous un modèle de tarification englobant en standard la fourniture d un ensemble de services? Préciser les services couverts par un même modèle de tarification et les conditions de tarification associées. Préciser les métriques de tarification et les principes qui encadrent leur tarification. Classification : Public 95 / 113

96 TRF-TARF-3 TRF-TARF-4 TRF-TARF-5 Pouvez-vous détailler les métriques sur lesquelles se basent vos modèles de tarification, en précisant notamment les possibilités offertes suivantes: Position installée ; Position nommée ; Position simultanée ; Nb d appels simultanés ; Nb d appels ; Nb de minutes d appels ; Durée moyenne d appels ; Autres métriques, etc. Avez-vous des modèles de tarification à la licence nommée et flottante? Quel est leur fonctionnement? Y a-t-il des limitations ou des prérequis en termes de nombre de licences, de nombre d utilisateurs simultanés et de nombre d appels simultanés? TRF-TARF-7 Changement du mode d achat de services Proposez-vous des modèles d achat de services de Centre d appels : À l usage du service ET basé sur un modèle d acquisition de licences? Gestion de la «scalability» La «scalability» désigne la capacité à absorber de manière temporaire ou permanente une augmentation de trafic d appels Cette scalabilité nécessite une augmentation du nombre de licences d agents. TRF-TARF-8 Pouvez-vous préciser votre politique tarifaire, ses prérequis et modalités d application pour : Une augmentation temporaire (pour couvrir entre autres la gestion de pics de trafic)? Une augmentation permanente (pour couvrir en particulier la montée en puissance de déploiement de nouveaux CRRA)? Pourriez-vous en particulier détailler les aspects touchant à la gestion des serveurs vocaux et les besoins de licences pour les utilisateurs? TRF-TARF-9 Dégressivité de la tarification Pouvez-vous et sans engagement nous indiquer les mécanismes de dégressivité de tarification qu il vous arrive d appliquer. Par exemple en fonction de : La volumétrie des appels ; Le nombre de conseillers ; La durée du contrat ; Autre paramètre (à préciser). TRF-TARF-10 Révision et Indexation des prix Pouvez-vous et sans engagement nous indiquer les moyens que vous envisagez pour garantir la compétitivité des prix des services? Détailler en particulier les possibles modalités de dégressivité des prix selon un axe temporel ou conjoncturel : La procédure de révision des prix ; Les conditions de révision annuelle ; Les critères et taux d évolution ; Les conditions de sortie anticipée avant la fin de période initiale. Classification : Public 96 / 113

97 TRF-TARF-11 TRF-TARF-12 TRF-TARF-13 Déploiement de ressources complémentaires Préciser votre politique tarifaire concernant des ressources en stand-by (datacenter de backup) versus des ressources nominales? Disposez-vous d une politique tarifaire adaptée à une gestion de trafic de pointes (évènement ponctuel type AZF)? Préciser cette politique. Dans le cas d un déploiement successif des CRRA, pouvez-vous préciser s il est possible de n acheter les licences et la maintenance associée qu à la mise en production de chaque CRRA / groupe de CRRA? Quelle est votre politique quant à la mise à disposition de ressources et de capacités logicielles concernant des environnements de DEV, de RECETTE, de FORMATION et de PRE-PRODUCTION? TRF-MNTC-1 Maintenance Pouvez-vous préciser les principes tarifaires de la maintenance des services proposés en indiquant le prix de la maintenance annuelle en % du prix d acquisition et éventuellement sur des développements complémentaires réalisés? Détailler l étendue de la maintenance pour les modules logiciels (évolutive, corrective, etc.). Préciser la date d effet de la maintenance pour les éléments matériels et logiciels : à l issue de la réception définitive, avec le principe d une période de gratuité pour la garantie? TRF-CTLS-1 Prestations de projet et d expertise Pouvez-vous préciser les prestations projet que vous jugez importantes, voire indispensables, que vous devriez réaliser en tant que fournisseur de solutions ou que l intégrateur (ou l opérateur) de votre solution devrait mettre en place? 4.6 Organisation des fournisseurs de solutions Cette section doit permettre à l ASIP Santé d avoir une connaissance générale de l organisation du répondant. Présentation générale du répondant PRE-GENE-1 Préciser la localisation de votre société en France (adresse postale). PRE-GENE-2 Préciser l identité du point de contact de votre société dans le cadre du programme SI- Samu : nom, prénom, fonction, , numéro de téléphone. PRE-GENE-3 Préciser la date de création de votre société et de sa représentation en France. PRE-GENE-4 Préciser les activités de votre société en France (fournitures de solution, intégration, maintenance, consulting, ). Classification : Public 97 / 113

98 PRE-GENE-5 PRE-GENE-6 PRE-GENE-7 PRE-GENE-8 Quel est le chiffre d affaires de votre société : En France? En Europe? Dans le monde? Quelle est la répartition de ce chiffre d affaires entre les différentes activités de votre société (vente de licences / matériels, prestations, )? Quels sont les effectifs de votre société : En France? En Europe? Dans le monde? Votre société a-t-elle établi des partenariats avec des intégrateurs du marché? Le cas échéant pouvez-vous les lister? Organisation de la maintenance PRE-MNTC-1 PRE-MNTC-2 Présentation de l organisation de la maintenance Quels sont le soutien et les garanties apportés en cas d incident : A vos utilisateurs finaux (en l occurrence à l ASIP Santé dans le cadre du SI- Samu)? A vos partenaires / revendeurs (Value-Added Resellers)? Aux opérateurs / hébergeurs revendant vos solutions en mode service? Quels sont le soutien et les garanties apportés à vos utilisateurs finaux dans le cadre de la gestion des problèmes (en l occurrence à l ASIP Santé dans le cadre du SI- Samu)? PRE-MNTC-3 PRE-MNTC-4 Quels sont le soutien et les garanties apportés à vos partenaires / revendeurs (Value- Added Resellers) dans le cadre de la gestion des problèmes? Quels sont le soutien et les garanties apportés aux opérateurs / hébergeurs revendant vos solutions en mode service dans le cadre de la gestion des problèmes? PRE-MNTC-5 Quelle est votre politique de versionning dans le cadre de la gestion des problèmes : fréquence, obligation de montée de version, support, etc.? PRE-MNTC-6 PRE-MNTC-7 PRE-MNTC-8 PRE-MNTC-9 PRE-MNTC-10 Quelle est votre politique de gestion des patchs dans le cadre de la gestion des incidents : fréquence, obligation d installation, support, etc.? Disposez-vous d équipes en charge du support de vos produits : En France? En Europe? Dans le monde? Préciser la taille de vos équipes de support en France, en Europe et dans le monde. Un support à vos produits est-il disponible en français? Via quel canal et sur quelles plages horaires? Quelle est la langue par défaut utilisée pour vos communications relatives au support? Du fait de la durée de mise en place du SI-Samu, pouvez-vous fournir votre politique en termes de maintien de versions et de dépôt des éléments constituant les produits proposables, en cas de défaillance de la société? Classification : Public 98 / 113

99 4.6.2 Approvisionnement PRE-APPR-1 Approvisionnement En cas de nécessité de remplacement d un équipement défectueux, pouvez-vous détailler les délais d approvisionnement matériel et logiciel? Gestion des évolutions PRE-EVOL-1 Gestion des évolutions Quelle est la politique de montée de versions de vos éléments logiciels : Fréquence ; Modalités pratiques de montée de version ; Obligation contractuelle de montée de version. PRE-EVOL-2 La compatibilité ascendante de votre solution est-elle garantie contractuellement? Quelles sont les limites à cette garantie? Quels sont les risques de régression? PRE-EVOL-3 PRE-EVOL-4 PRE-EVOL-5 Quelles sont les possibilités / limites d une gestion d un parc hétérogène de versions de votre solution? Fournissez-vous un outillage particulier permettant de faciliter les montées de version? Quel est l impact constaté des montées de version au sein de votre client? Quelles sont les bonnes pratiques à mettre en œuvre? Quels sont les impacts en termes de disponibilité? Prise en compte des demandes spécifiques PRE-SPEC-1 PRE-SPEC-2 Gestion des demandes spécifiques Dans le cas de la mise en place par un intégrateur d une fonction non native au sein de votre produit : Avez-vous une politique de «progicialisation» permettant d intégrer cette fonction au sein de votre produit standard? Est-il possible d intégrer ces évolutions lors d une de vos futures montées de version majeure? Le cas échéant, selon quelles modalités? Comment garantissez-vous la compatibilité ascendante sur l ensemble de vos API et vos interfaces? À défaut, comment documentez-vous les écarts entre les interfaces? Processus d escalade Processus d escalade PRE-ESCA-1 PRE-ESCA-2 En cas de difficulté contractuelle rencontrée avec un intégrateur de l un de vos produits, proposez-vous un dispositif d escalade ad hoc pour vos clients finaux? En cas de difficulté contractuelle rencontrée avec un intégrateur de l un de vos produits, disposez-vous d une politique client (et des moyens correspondants) à même de permettre une mise sous contrôle d un projet mené par un de vos clients finaux? Classification : Public 99 / 113

100 5 Annexes 5.1 Besoin métier Le schéma ci-dessous présente à titre illustratif et de manière macroscopique la cartographie fonctionnelle cible du futur SI-Samu. Cette synthèse est issue des nombreux travaux préparatoires conduits par les équipes de l ASIP Santé avec les représentants métier d un grand nombre de Samu. Classification : Public 100 / 113

101 5.2 Cinématique de l appel et architecture La cinématique proposée dans ce schéma est donc la suivante : Le Patient ou un effecteur appelle le 15 ou le 112. L opérateur de boucle locale fournit l appel à l opérateur de collecte, enrichis par les données de géolocalisation. L opérateur de collecte est en charge de globaliser les appels et de leur appliquer les règles de chaque PDAAU. L opérateur de collecter applique ensuite la stratégie de traitement unifiée en fonction de la charge globale des appels, L opérateur de service apporte des fonctionnalités avancées telles que : a. Prise en charge des fonctionnalités de pré-routage et de serveurs vocaux, via les serveurs frontaux SVI qui sont capables de jouer les scénarios fonctionnels d accueil vocal et de qualification de l appelant, paramétrés au niveau de l administration fonctionnelle par les Samu ; b. Hébergement des composants serveurs, en particulier ceux qui

102 doivent communiquer en voix sur IP avec les équipements opérateurs : i. Serveurs centraux d enregistrement des appels ; ii. Équipements de téléphonie de type IPBX ; iii. Hébergement des composants applicatifs CTI & LRM. L acheminement de l appel en nominal vers le site local est fait par des liens télécoms traditionnels de type T2. L acheminement de l appel en dégradé vers le site local est fait par IP MPLS. Acheminement en cas de saturation du CRRA-1 ou sur compétence spécialisée (entraide), Distribution vers le meilleur agent. 5.3 Cinématique de traitement du service d accueil vocal D une manière générale, le patient appelle le 15 ou le 112 alors qu un effecteur peut aussi composer un numéro entrant dédié. De ce fait un test sur le numéro appelé est effectué afin de permettre une première personnalisation de l accueil vocale. Dans un second temps, un SVI (Serveur Vocal Interactif) «muet» (qui ne joue pas de message et implique un blanc de quelques secondes pour tous les appelants) est activé et attend un code Pin. Le code Pin est fourni aux partenaires et est différent suivant le type partenaire (SDIS, Ambulances privées, SOS Médecin, Hôpital ). Si l appelant ne saisit pas de code Pin, il est alors orienté vers la file d attente dite «15». Le numéro de l appelant est testé dans un premier temps afin de savoir s il est connu du système (appel malveillant, patient remarquable, ). Une fois ces tests réalisés : si un agent est disponible alors l appel passe directement au «Routage» puis à la «Distribution» afin de mettre en relation l appelant et l agent ; sinon, l appel est alors mis en attente sur une application vocale SVI 15-Samu. Dès qu un agent est disponible l appel passe directement au «Routage» puis à la «Distribution» afin de mettre en relation l appelant et l agent. Si au contraire l appelant saisit un code Pin, il est alors orienté vers les files d attente dites «Partenaires / Professionnels» et un «SVI Professionnel». Le type d appelant sera différencié à l affichage en file d attente suivant le code Pin saisi. Classification : Public 102 / 113

103 5.4 Cinématique de traitement d un appel entrant La cinématique proposée dans ce schéma est donc la suivante : Lorsque l appelant émet un appel, la voix est acheminée sur l organe télécom où sont acheminés les appels. Cet appel est décroché et parqué sur l organe télécom le temps que les fonctions centre d appels trouvent le meilleur agent disponible Classification : Public 103 / 113

104 pour répondre à l appel ou appliquent les règles de gestion des appels Une fois l appel arrivé sur les infrastructures télécoms, le système CTI qualifie l appel et le type d appelant à l aide de requêtes en bases de données système et/ou SI via des Web Services. Cette partie de la qualification fait la jonction entre les métadonnées fournies par l opérateur télécom lors de la collecte (numéro de l appelant, département de provenance, ) et les informations contenues dans le SI-Samu. Cette étape permet, par exemple, d identifier un numéro de téléphone connu du SI-Samu (BDD Centre d appels) et de trouver les DRM récentes associés à ce numéro de téléphone. Le système peut aussi proposer à l appelant de saisir des informations numériques (par ex, les quatre derniers chiffres du DRM) ou de prononcer le motif de l appel. Une fois toutes les données de qualification récoltées, le système définit la priorité (immédiate et dynamique dans le temps) et les compétences nécessaires pour pouvoir répondre au mieux à la problématique de l appelant, suivant un ensemble de règles préétablies. Le système trouve l appel le plus urgent et recherche ensuite l agent disponible le plus à même de répondre à l appel. Si aucun n est disponible, l appel est alors mis en attente. Une fois les règles de routage de l appel implémentées, la distribution regarde si l appel peut être distribué automatiquement. Si un agent est disponible, alors nous passons directement à l étape 7, sinon si tous les agents sont indisponibles alors l appel est éventuellement routé sur un SVI selon la stratégie de routage qui lui est applicable (ce SVI nécessite des actions de l appelant), puis est mis en attente de la disponibilité d un agent. Dans notre cas, le SVI demande à l appelant de qualifier l urgence vitale de son appel et ainsi de définir sa priorité. Si un agent est ciblé (avec ou sans attente), le système envoie l information au poste de collecte afin de réserver l agent. Le système envoie la notification de l arrivée d un appel au poste de travail de l utilisateur via l application téléphonique CTI et le poste de collecte envoie l appel sur le poste téléphonique associé à ce poste de travail. L application téléphonique CTI envoie la notification de l arrivée d un nouvel appel au système de gestion de régulation médicale. Il envoie la notification au LRM qui crée un nouveau dossier de régulation médicale en cas de nouvelle demande, ou qui ouvre le ou les DRM probablement en rapport avec l appel en cas de suivi d une demande déjà initialisée. Remarque : Ce schéma est illustratif et représente le fonctionnement des appels «publics» faits aux Samu, constituant la majorité des appels. 5.5 Intégration des réseaux Radio Présentation du réseau ANTARES L'Infrastructure Nationale Partagée de Télécommunications (INPT) est organisée autour de milliers de sites-relais qui couvrent environ 95 % du territoire métropolitain français. L INPT est un réseau radio national pour les services de l état, notamment la police (TETRAPOL), la Classification : Public 104 / 113

105 gendarmerie (RUBIS), et tous les services de la protection civile. L INPT est découpée logiquement en plusieurs organisations indépendantes. Le réseau ANTARES (Adaptation Nationale des Transmissions Aux Risques Et Secours) s appuie sur l INPT. C est un réseau numérique crypté qui permet des communications sécurisées entre ces utilisateurs. ANTARES est découpée en réseau de base ayant une couverture départementale. Chaque terminal radio possède un numéro d identification sur le réseau appelé RFGI Les Services d Incendie et de Secours (SDIS), Les Services de Secours et des Urgences (Samu, Smur...), utilisent ce réseau national numérique sécurisé, en remplacement des réseaux analogiques historiques. ANTARES permet aux réseaux radio des SDIS et des Samu d'avoir : Une cohérence technologique pour tous les services d'urgences ; Une interopérabilité des réseaux de communication radioélectriques des services publics concourant aux missions de sécurité civile selon un ensemble de règles et normes techniques ; Une assurance de la continuité des communications en intervention en toutes circonstances (milieux souterrains, confinés, bâtiments...). Ces services offerts peuvent être découpés en trois catégories : - Communication phonie Appel de group ou talk group (identique à une fréquence sur les réseaux analogiques) ; Appel individuel (identique à un téléphone) ; Appel de détresse ; Appel direct (communication tactique) ; Appel RIP relais mobile (communication tactique relayée) ; Gestion des priorités ; Préemption ; - Réception de données via des messages cours Statut ; Géo localisation ; - Réception de données via des messages longs Rapports d intervention ; ECG ; Bilans médicaux Les gestionnaires de voies radio Un gestionnaire de voies radio ou GVR est à la fois : Un pont de conférence ; Une passerelle radio / IP ; Un équipement de traitement du signal. Cette solution permet de gérer les équipements radio et de communiquer à l aide de la radio numérique, analogique. Elle permet également de s interconnecter de façon plus ou moins intégrée avec la partie téléphonie. Classification : Public 105 / 113

106 Un même GVR peut s interfacer Directement avec un ou plusieurs équipements radio analogiques ; Directement avec un ou plusieurs équipements radio numériques comme Antares ; En IP via une passerelle radio IP ou un autre GVR. Chaque personne du Samu peut être abonnée à un ou plusieurs «flux radio». Un canal préférentiel peut être spécifié. L utilisateur peut alors être à l écoute des messages radios sur plusieurs canaux en les multiplexant, sur son canal préféré. Il peut être averti par son IHM qu une communication a été reçue sur l un des canaux autorisés sur son plan de veille ce qui est très utile dans le cas où il a baissé le volume sonore de sa réception. Pour devenir voie opérateur, une ressource du type voie analogique ou conférence, doit être dans le plan de veille. Une communication reçue sur un canal est notifiée comme un appel téléphonique dans une salle d attente. Il est possible d écouter le message en différé sur le poste opérateur. Cette prise de main sur cette communication est vue par le système de communication : Soit l agent communique avec le distant, il est vu alors comme indisponible dans la téléphonie ; Soit l agent quitte la voie opérateur sans en prendre une autre. Il doit être vu comme disponible par le centre d appels. Classification : Public 106 / 113

107 L écoute peut être effectuée dans un casque ou par haut-parleur. Généralement les voies radio du plan de veille sont multiplexées dans le haut-parleur, alors que la voie opérateur passe dans le casque. L accès au réseau Antares peut être effectué par une AG radio, par AG filaire (ou de façon extrêmement rare en IP si la préfecture a autorisé un déport du GVR en préfecture). Il existe plusieurs types de configuration entre les Samu et les SDIS La performance limitée du réseau pour le transfert de données ne permet pas d envisager des échanges importants en volumes, mais les fonctions à faible niveau de trafic peuvent être envisagées. Elles nécessitent la mise en place de liaisons vers les serveurs du SDIS et la mise en œuvre des applications correspondantes. Actuellement une liaison point à point filaire (type xdsls) ou FH (Faisceau Hertzien) est utilisée entre le Samu et le SDIS, elle doit permettre la communication applicative avec les serveurs AVL et d alerte. L utilisation d un VPN sur Internet est possible mais non souhaitable. Elle est très rarement utilisée car elle ne permet pas de garantir une qualité de service compatible avec la voix. Cette solution est toutefois utilisée entre le GVR du Samu de Besançon et ceux des SDIS (25, 39, 70) de la région. La fonction AVL installée au SDIS est implémentée sur un serveur dédié disposant généralement de deux interfaces IP : Une interface pour communiquer avec le CG situé à la préfecture ; Une interface associée au réseau informatique opérationnel du SDIS pour communiquer avec les applications clientes au SDIS et au Samu. Le serveur AVL communique avec les terminaux radio Antares des véhicules pour collecter les statuts, les informations de géolocalisation, et transmettre des messages courts. Les Classification : Public 107 / 113

108 agents peuvent aussi transmettre des messages libres aux véhicules et qui seront affichés sur le terminal radio associé à ce dernier. Le serveur Alerte est dédié aux messages longs. Les applications utilisatrices de ces données doivent venir les récupérer sur les serveurs AVL et Alerte du département concerné. L ensemble des matériels et logiciels doit être conforme à la norme AFNOR issue du GT 399. La norme NF399 a été conçue pour permettre l interopérabilité entre différents équipements. Elle est basée sur une architecture orientée services impliquant des échanges au niveau IP, SOAP, XML. Plusieurs interfaces ont été spécifiées, notamment les suivantes : R11 Connexion vers le serveur AVL (Statu et géolocalisation) ; R17 Enregistrement en IP vers enregistreur légal ; R18 Interopérabilité dans le cadre de la RGPP. Pilotage depuis le système d aide à la régulation ou de téléphonie avancée des ressources radio (synoptique des moyens ou cartographie) ; R19 Synchronisation avec bases de données système tiers. Lancer en priorité les projets d interopérabilité sur les besoins communs des acteurs (information géographique, vidéo, géolocalisation) ; R20 Relier les centres opérationnels ; R33 Interconnexion avec Systèmes de Gestion de la Phonie tiers. Les principaux fournisseurs de solutions GVR utilisées par les Samu sont Prescom, IMPI et SYSOCO. Classification : Public 108 / 113

109 Les installations mises en place sont dans 70% des cas des configurations Type 2, et 30% des cas des configurations de type 1 ou 1bis. Seule une configuration est de type 3, elle n existe qu à Marseille. Les différentes configurations sont présentées au sein des schémas infra Configuration des SDIS Généralement le SDIS se connecte à la préfecture où se trouve le commutateur général par une liaison multiplexée permettant d accéder à plusieurs AG filaires distantes et de fournir un lien IP pour que les serveurs AVL et Alerte puissent recevoir les messages du réseau Antares. Les routeurs effectuent les fonctions de filtrage des flux et de translation d adresse NAT nécessaires. 5.6 Glossaire Acronyme ACD AG AMU ANTARES AP API AR ARM AVL BDD BDSP Signification Automatic Call Distributor Access Gate Aide Médicale Urgente Adaptation Nationale de la Téléphonie Aux Risques Et Secours Ambulance Privée Application Programming Interface Ambulance de Réanimation Assistant de Régulation Médicale Automatic Vehicle Location Base De Données Base de Données de Sécurité Publique Public Security Database Classification : Public 109 / 113