Brevet FR3063160A1 — publié le 20180824

Système et procédé de traitement de données pour permettre l'accès sécurisé à un service hébergé dans un serveur distant depuis un équipement utilisateur mobile associé à un lecteur de carte La présente invention se rapporte au traitement de données pour permettre l'accès sécurisé à un service hébergé dans un serveur distant depuis un équipement utilisateur mobile associé à un lecteur de carte. Elle trouve une application générale dans le traitement de données confidentielles et plus particulièrement dans le traitement de données médico-administratives tel que la génération, la facturation et la télétransmission de feuilles de soins électroniques (FSE) en conformité avec les services proposés par la Caisse Nationale d'Assurance Maladie (CNAM) et l'Agence des Systèmes d'Information Partagés de santé (ASIP). On connait déjà des systèmes qui permettent à un professionnel de santé d'accéder à un service web de santé depuis un poste de travail utilisateur associé à un lecteur de carte. Dans ce genre de système la connexion entre le serveur distant et le poste de travail s'effectue à travers Internet selon un protocole d'échange de données sécurisé. Des composants logiciels spécifiques sont installés dans le poste de travail utilisateur afin de permettre au professionnel de santé d'accéder au lecteur de carte et de dialoguer de manière sécurisée avec le serveur distant. Le Groupement d'Intérêt Economique SESAM Vitale, appelé ci-après groupe GIE, fournit des composants logiciels permettant aux logiciels de télétransmission de feuilles FSE de communiquer avec les lecteurs de carte. Parmi ces composants logiciels, on trouve les fournitures SESAM Vitale (FSV) formant interface de programmation applicative (API) et dédiées spécifiquement à l'accès en lecture de la carte d'identification du 3063160 2 professionnel de santé (carte CPS) et de la carte d'identification du patient (carte Vitale). En pratique, le groupe GIE assure la diffusion des fournitures FSV auprès 5 des éditeurs de logiciels de télétransmission. De son côté, le Centre National de Dépôt et d'Agrément (CNDA) créé des cahiers de tests en rapport avec les fournitures FSV et le cahier des charges du groupe GIE. Le centre CNDA valide en outre les tests et donne enfin un agrément à l'éditeur de logiciels de télétransmission si les tests sont validés. Le 10 groupe GIE fait évoluer le cahier des charges par rapport aux différentes lois votées et si besoin met à jour les fournitures FSV. Le centre CNDA adapte les cahiers de tests pour proposer aux éditeurs de logiciels des différentiels de cahiers de tests pour ne pas repasser tous les tests. Entre les versions majeures du cahier des charges et des fournitures FSV, les 15 composants logiciels doivent en outre intégrer des additifs et des compléments, dont la diffusion auprès des professionnels de santé est relativement complexe, longue et coûteuse. Les fournitures FSV ont l'inconvénient d'être déployées et compilées 20 exclusivement pour l'architecture des microprocesseurs INTEL X86 car l'architecture X86 est la plus répandue dans le monde des postes de travail fixes et ordinateurs personnels PC. Toutefois les microprocesseurs des smartphones, tablettes tactiles ou autres équipements mobiles intelligents sont rarement en environnement X86 mais plutôt massivement 25 en environnement ARM/RISC. Il en résulte que les fournitures FSV sont aujourd'hui rarement installées dans les équipements mobiles intelligents alors que les professionnels de santé souhaitent justement être en mesure de télétransmettre des feuilles FSE lorsqu'ils sont en mobilité notamment en visite à domicile. 30 3063160 3 En outre, d'autres composants logiciels sont requis pour réaliser d'autres opérations sécurisées à l'aide des cartes CPS et/ou vitale. Il en est ainsi du logiciel CryptoLib, fourni par l'agence ASIP, et requis pour extraire un certificat de la carte de professionnel de santé CPS. Il en est aussi du 5 logiciel MICA, fourni par le groupe GIE pour générer une signature de la carte Vitale. Or, ces composants logiciels ont aussi l'inconvénient d'être déployés uniquement sous la forme compilée en environnement X86. Il en résulte que les composants logiciels CryptoLib et MICA sont aussi peu utilisés actuellement dans les smartphones/tablettes que les fournitures 10 FSV, ce qui complexifie encore davantage l'accès sécurisé à un service hébergé dans un serveur distant depuis un équipement utilisateur mobile associé à un lecteur de carte. La présente invention remédie justement à ces inconvénients. A cet effet, elle vise un système de traitement de données pour permettre l'accès sécurisé à un service de santé hébergé dans un serveur de service depuis un équipement utilisateur mobile associé à un lecteur de carte. Selon une définition générale de l'invention, l'équipement utilisateur comprend : - un dispositif à processeur à instructions RISC/ARM; - un module d'application cliente associé au service de santé et accessible 25 via un navigateur web; - un module formant serveur local associé à une couche de communication locale et configuré pour communiquer avec le module d'application cliente via un canal de communication locale établi entre le serveur local et le navigateur; 15 20 30 - un module de traitement de carte; 3063160 4 - au moins une interface de programmation applicative compilée en environnement X86 et configurée pour permettre au module de traitement de carte de communiquer avec le lecteur de carte; - une application logicielle formant adaptateur configurée pour appeler 5 l'interface de programmation applicative choisie; et le module d'application cliente comprend au moins un mode opératoire émulé en environnement X86 dans lequel : - le module d'application cliente émet une requête d'accès de carte via le navigateur; 10 - en réponse à la requête ainsi reçue à travers le canal de communication locale, le serveur local génère une commande d'accès correspondante; - en réponse à la commande ainsi reçue, l'application formant adaptateur lance l'interface de programmation applicative choisie pour permettre au module de traitement de carte de communiquer avec le lecteur de carte 15 correspondant et de transmettre en retour des données de carte dans un format prédéfini à l'application formant adaptateur qui les transmet ensuite au serveur local pour être enfin communiquées au module d'application cliente pour traitement. 20 Un tel système conforme à l'invention a l'avantage de pouvoir utiliser les interfaces de programmation applicatives du groupe GIE et de l'agence ASIP disponibles sous la forme compilée en environnement X86 pour un fonctionnement sur des smartphones et/ou tablettes tactiles à microprocesseur ARM/RISC. 25 De plus, un tel système a l'avantage d'être compatible avec tous les environnements et systèmes d'exploitation OS du marché, notamment WindowsTM, Android LINUXTM, Apple iOSTM, ce qui favorise l'usage d'un tel système avec des smartphones et tablettes tactiles du marché. 3063160 5 De plus, le système conforme à l'invention est configurable sur n'importe quel navigateur web, ce qui facilite encore davantage son utilisation et son adoption auprès des professionnels de santé. 5 En outre, la maintenance et la mise à jour des composants logiciels conformément aux cahiers des charges du groupe GIE sont rendues relativement faciles puisque le code à maintenir est centralisé au niveau du serveur distant. 10 La nouvelle version des fournitures FSV étant disponible et centralisée sur le serveur distant, la mise à jour des fournitures FSV au niveau de chaque équipement utilisateur est rendue également facile puisqu'il suffit de télécharger un fichier d'installation contenant tous les nouveaux éléments 15 et d'installer ledit fichier d'installation au niveau de chaque équipement utilisateur pour disposer de la mise à jour des fournitures FSV. Ainsi, les professionnels de santé disposent d'un accès aux différents services web de santé (services de facturation FSE, télé-services, 20 obtention de droits en ligne...) par le biais d'un équipement utilisateur mobile de type smartphone et/ou tablette tactile dont le mode opératoire n'est pas lié et/ou tributaire d'un processeur particulier, ni d'un système d'exploitation défini ni encore d'un navigateur web spécifique, ce qui facilite encore davantage l'adoption du système conforme à l'invention 25 auprès des professionnels de santé. Selon un mode de réalisation, le module d'application cliente comprend une interface graphique utilisateur du service de santé obtenue auprès dudit serveur distant via un canal de communication sécurisé entre le 30 navigateur et le serveur de service sur authentification du certificat du professionnel de santé par le serveur de service. 3063160 6 Ainsi à l'aide du navigateur, la requête d'accès est émise par l'interface graphique utilisateur du service de santé à destination du module formant serveur client local via la couche de communication locale tandis que les 5 données de carte ainsi obtenues auprès du lecteur de carte sont transmises en retour au navigateur dans un format prédéfini. En pratique, la commande d'accès de carte appartient au groupe formé par les commandes offertes par les fournitures FSV, MICA et CRYPTOLIB 10 à savoir une commande de lecture de carte de professionnel de santé, une commande de lecture de carte de patient, une commande d'assertion de carte de professionnel de santé, une commande d'assertion de carte de patient, une commande pour formater une facture, une commande pour créer une facture, une commande pour créer un lot de factures, une 15 commande pour convertir en un texte clair et lisible. Selon encore un autre mode de réalisation dans lequel la commande d'accès de carte est une commande de lecture de carte de patient et/ou une commande de lecture de carte de professionnel de santé, il est prévu 20 pour chaque lecteur de carte, de déterminer par le module de traitement de carte l'interface de programmation applicative correspondant au lecteur de carte; et pour chaque lecteur de carte ainsi déterminé, il est prévu d'accéder aux données de carte associées auxdites cartes de professionnel et/ou de patient; et de les transmettre en retour à 25 l'application logicielle formant adaptateur En pratique, l'interface de programmation applicative appartient au groupe formé par les fournitures SESAM Vitale, la libraire MICA, la librairie CRYPTOLIB. 3063160 7 Selon une autre caractéristique de l'invention, le mode opératoire comprend en outre les étapes suivantes : - télécharger les données ainsi obtenues au niveau du 5 module d'application cliente sur le serveur distant via le canal de communication sécurisé pour conversion en clair; et - obtenir des données lisibles en provenance du serveur distant et restituer les données lisibles sur l'interface utilisateur de service de santé. 10 Selon encore un autre mode de réalisation, lorsque la commande d'accès correspond à une commande d'assertion de carte de patient et/ou de carte de professionnel, le mode opératoire comprend en outre les étapes suivantes: 15 - déterminer par l'interface programmation applicative le lecteur de carte correspondant au lecteur de carte de patient et/ou au lecteur de carte de professionnel de santé; - générer, par le lecteur de carte ainsi déterminé une 20 signature pour la carte correspondante; - transmettre par le lecteur de carte, la signature ainsi générée à l'application logicielle formant adaptateur ; - pbtenir par le module formant serveur client local la signature ; et 25 - générer le certificat correspondant à la signature pour transmission au navigateur. Selon encore un autre mode de réalisation de l'invention, le mode opératoire comprend en outre les étapes suivantes : 3063160 8 - télécharger les données ainsi obtenues au niveau du module d'application cliente sur le serveur distant via le canal de communication sécurisé pour conversion en clair; et - stocker les données de cartes ainsi téléchargées au niveau du 5 serveur distant ; et - restituer les données à au moins un opérateur de service de santé. Par exemple, l'équipement utilisateur comprend un module émulateur configuré pour émuler en environnement X86. 10 Selon un autre mode de réalisation l'équipement utilisateur comprend une base de données locale cliente propre à stocker les données des cartes obtenues auprès des lecteurs de carte en absence de connexion avec le serveur distant. 15 Ainsi, hors connexion avec le serveur distant, hébergeant le service de santé, le professionnel de santé en mobilité peut enregistrer des transactions sécurisées dans la base de données locale de l'équipement utilisateur et ensuite les envoyer au serveur de service lorsqu'il est de 20 nouveau en connexion avec le serveur de service de santé. Selon encore un autre mode de réalisation, le système de traitement comprend en outre un smartphone équipé d'une première application propre à s'occuper de la communication avec le lecteur de carte et d'une 25 seconde application propre à s'occuper de la communication avec l'équipement utilisateur via une connexion appropriée, le smartphone jouant le rôle d'intermédiaire entre l'équipement utilisateur et le lecteur de carte. 3063160 9 Par exemple, le lecteur de carte est logé dans un étui rigide, en association avec l'équipement utilisateur ou le smartphone. Selon un autre aspect de l'invention, la présente invention a également 5 pour objet un procédé de traitement de données pour permettre l'accès sécurisé à un service de santé hébergé dans un serveur distant depuis un équipement utilisateur mobile associé à un lecteur de carte mise en oeuvre par le système de traitement conforme à l'invention. 10 Selon encore un autre aspect de l'invention, la présente invention a pour objet un programme produit d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par microprocesseur caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution du procédé conforme 15 à l'invention. D'autres caractéristiques et avantages de l'invention apparaîtront à la lumière de la description ci-après et des dessins dans lesquels : - la figure 1 est un schéma fonctionnel montrant un mode de 20 réalisation du système de traitement conforme à l'invention ; - les figures 2 et 3 sont respectivement le schéma fonctionnel et l'organigramme des données associés à un mode opératoire correspondant à lire une carte de professionnel de santé avec le système de traitement de la figure 1; 25 - les figures 4 et 5 sont respectivement le schéma fonctionnel et l'organigramme des données associés au mode opératoire correspondant à créer une assertion de carte vitale avec le système décrit en référence à la figure 1; - la figure 6 est l'organigramme des données associés au mode 30 opératoire correspondant à facturer une feuille de soin 3063160 10 électronique avec un système de traitement hors connexion internet ; et les figures 7 et 8 sont des schémas fonctionnels illustrant un autre mode de réalisation du système de traitement à l'aide d'un 5 ensemble tablette tactile et smartphone conforme à l'invention. En référence à la figure 1, le système de traitement conforme à l'invention comprend un lecteur de carte 2, un équipement utilisateur 4 et un serveur distant 6. Le lecteur de carte 2 est un matériel de lecture qui permet la lecture d'une 10 carte d'identification insérée dans le lecteur et la transmission des données stockées dans la carte. Dans un mode de réalisation, le matériel de lecture comprend un lecteur de carte 3 agréé par le groupe GIE. Le lecteur de carte 3 est bi-fentes pour l'insertion d'une carte CPS dans l'une des fentes et une carte Vitale 15 dans l'autre fente. Dans un autre mode de réalisation, le matériel de lecture comprend deux lecteurs PC/SC 5 (pour « Personal Computer/Smart Card ») au format de carte à puce standard que l'on peut trouver facilement sur le marché du lecteur de carte. Les lecteurs PC/SC 5 ont l'avantage de ne pas être chers 20 car ils n'embarquent pas d'intelligence à l'intérieur. Dans encore un autre mode de réalisation (figures 7 et 8) le matériel de lecture 2 comprend un arrangement formé de deux lecteurs PC/SC individualisés en 5-1 et 5-2 et reliés l'un et l'autre à un module formant hub 5-3. Le matériel de lecture 5-1 à 5-3 est par exemple logé dans une 25 couverture plate ou étui 102 rigide. On fait à nouveau référence à la figure 1. Le serveur distant 6 est un serveur applicatif Web. Par exemple, le serveur applicatif 6 héberge une application Web 7 (référencée 7-S côté serveur 6) délivrant un service de santé tel que le service de facturation 3063 160 11 FSE proposé par la Caisse Nationale d'Assurance Maladie (CNAM) et l'Agence des Systèmes d'Information Partagés de santé (ASIP). Un tel service de facturation est conforme aux réglementations du Cahier Des Charges du groupe GIE. En alternative le service de santé peut être un 5 service d'obtention de droits en ligne, un télé-service ou tout autre service en relation avec le traitement de données médico-administratives. Le serveur distant 6 comprend un module de communication 8 propre à échanger des données confidentielles avec l'équipement utilisateur 4 à travers un réseau de communication 11 (figure 2) de type Internet selon 10 un canal de communication sécurisé 10 de type SSL et/ou TLS. Le serveur distant 6 comprend une base de données 9 pour le stockage des données. L'application Web 7 est développée en C#, par exemple ASP Net MVC. La version référencée 7-C côté équipement utilisateur est téléchargée 15 dans chaque équipement utilisateur 4 et accessible depuis un navigateur web 15. L'équipement utilisateur 4 peut être un ordinateur, une tablette tactile (comme décrit en référence aux figures 1 à 6), un smartphone, une association tablette/smartphone (comme décrit en référence aux figures 7 20 et 8) ou tout matériel mobile apte à communiquer avec le serveur distant 6 via le canal de communication sécurisé 10. L'équipement utilisateur 4 comprend un dispositif de traitement à processeur ARM/RISC 12, fonctionnant sous un système d'exploitation mobile 13 du type « Apple iOSTM », ou « ANDROID LINUXTM ou encore 25 « Windows 10TM » compilé en instructions ARM avec émulateur x86 pour l'exécution d'applications standards 14 au format Android, IOS ou Windows 10TM. Parmi ces applications standards 14 on trouve le navigateur Web 15. Le navigateur web 15 est du type de celui utilisé sur les smartphone ou tablette tactile, c'est-à-dire «FirefoxTM», «Google 30 ChromeTM», «SafariTM», ou encore «Internet ExplorerTM » ou «chromeTM» 3063160 12 dans le cas d'un Windows 10 compilé en processeur ARM avec émulateur X86. La connexion entre le navigateur Web 15 et le serveur distant 6 respecte des règles de sécurité dictées par le cahier des charges du groupe GIE. 5 En pratique, tous les flux sortant sur internet 11 et entrant dans le navigateur 15 se trouvent dans un tuyau TLS SSL 10. La connexion sécurisée est créée entre le navigateur web 15 et le serveur distant 6 à l'aide du certificat du professionnel de santé. Un tuyau TLS/SSL 10 est ouvert entre le module de communication côté client (non représenté) et le 10 module de communication 8 côté serveur distant 6. Les données échangées sont ainsi sécurisées. C'est le serveur distant 6 qui créé la page HTML d'accueil de l'application web 7, par exemple à l'adresse www.cqmevitale.hellodoc.com (étape E1, figures 2 et 3). Ensuite le serveur distant 6 fait redescendre la page 15 d'accueil dans le tuyau 10 pour ensuite l'afficher à l'utilisateur sur la partie HTML 15-0 du navigateur 15 (étape E2 figures 2 et 3). On fait à nouveau référence à la figure 1. L'équipement utilisateur 4 comprend en outre un module 16 formant serveur local 17 associé à une couche de communication 18 de type 20 conforme au protocole websocket. Le module 16 est configuré pour communiquer avec le module d'application cliente 7-C via un canal de communication locale 39 établi entre le serveur local 17 et le navigateur 15. Avantageusement, le module 16 est une application externe au navigateur 25 web 15, ce qui permet au module 16 d'être utilisé avec n'importe quel navigateur WEB du marché. Le module 16 est de maintenance et de déploiement aisés puisqu'un simple fichier java au format JAR pour « Java archive » suffit à son déploiement sur l'équipement utilisateur 4. 3063160 13 Le module 16 est compatible avec tous les systèmes d'exploitation OS Windows TM , Apple MAC Os TM et Linux TM dans le monde X86. Il est aussi compatible avec IOSTM et ANDROID Tm avec la couche d'émulation X86 sur ARM. 5 Le module 16 est une application 16 en technologie JAVA, autonome et se lance dans une machine virtuelle JAVA qui embarque le serveur local client 17 sur lequel est ajoutée une couche de communication web socket 18 formant ainsi un client web socket. La couche supplémentaire web socket coté navigateur 15 et côté serveur 10 local 17 permet d'établir un tuyau de communication bidirectionnelle 39 entre le navigateur (client) et le serveur local 17. Cette couche de communication permet le transport des données. Le fait d'avoir un tuyau bidirectionnel 39 entre le navigateur 15 et le serveur local 17 permet de gérer les actions de l'utilisateur de manière 15 asynchrone. Par exemple comme on le décrira plus en détail ci-après en référence aux figures 2 et 3, le navigateur 15 envoi une requête d'accès carte (par exemple «LirecarteCPS ») au module 16. Le module 16 capte la requête, utilise les interfaces de programmation applicatives appropriées (par 20 exemple FSV) pour faire l'action sur le matériel de lecture 2. Pendant ce temps, le navigateur client 15 n'est pas bloqué, il peut faire d'autres choses. Lorsque le module 16 récupère la donnée du matériel de lecture 2 celle-ci est renvoyée sur le navigateur client 15. C'est au chargement de la page accueil.html sur l'interface graphique 25 utilisateur 15-0, que le client web socket 15-1 est créé en Javascript. La couche web socket 18 permet d'accéder aux librairies du groupe GIE et de l'agence ASIP telles que les fournitures SESAM Vitale FSV 19, Cryptolib 20 et Mica 21 via une passerelle logicielle formant adaptateur 26 3063160 14 (wrapper en anglo-saxon) telle que JNA pour « Java Native Access » que l'on décrira plus en détail ci- après. Par exemple, le serveur client local embarqué 17 est de type NETTY dont l'avantage est d'utiliser peu de ressource et de mémoire pour fonctionner. 5 Comme déjà décrit ci-avant, les librairies du groupe GIE et de l'agence ASIP sont compilées en environnement X86. Pour un fonctionnement sous un environnement ARM/RISC, il est prévu un émulateur 23 par exemple de type ExagearTM. L'émulateur 23 est une machine virtuelle qui implémente virtuellement un microprocesseur en environnement X86 10 référencé 24 afin d'exécuter des applications fonctionnant sous environnement X86. Dans le cas d'un système d'exploitation du type de Windows 10 compilé en instructions ARM avec émulateur x86, la fonction d'émulation x86 est nativement intégrée dans le système d'exploitation Windows 10TM 15 On sait que les interfaces de programmation applicatives API ne fonctionnement pas sous instructions ARM. Dans ce contexte, le groupe GIE fourni aux éditeurs de logiciels un Cahier Des Charges, appelé Dl pour Dispositif Intégré. Toutefois ce cahier des charges Dl est très contraignant de par son coût de développement, de par son coût de 20 maintenance, et de par son coût de validation. En effet une validation, avant la phase du centre CNDA, doit être validée en laboratoire pour vérifier que l'application développée est aussi étanche en termes de sécurité que les fournitures FSV. Ainsi grâce à l'invention, il est possible d'utiliser l'existant (par exemple les 25 fournitures FSV) en utilisant une couche d'émulation X86. Cela permet aussi d'être réactif en termes d'évolution du Cahier des charges du groupe GIE. 3063160 15 L'équipement utilisateur 4 est relié au matériel de lecture 2 via un module de traitement de cartes dont la structure diffère en fonction de la nature du lecteur de carte associé à l'équipement utilisateur 4. Dans le cas de lecteurs de carte 3 agréés par le groupe GIE, le module de 5 traitement de carte comprend un module Galss 27 relié au lecteur de carte 3 via une connexion 32 ou sans fil. Le module 27 est un logiciel supplémentaire installé sur l'équipement utilisateur 4 afin d'identifier et communiquer avec les lecteurs SESAM Vitale 3. Dans le cas de lecteurs de carte 5 de type PC/SC, le module de traitement 10 de carte comprend un module de gestion de type PCSCLITE 21 (pour IinuxTM ou Apple OSTM) ou un service de carte à puce (pour WindowsTM) via une connexion 33 sans fil ou filaire USB. En référence aux figures 2 et 3 on a représenté à titre d'exemple un schéma fonctionnel et l'organigramme de données associé à la lecture de 15 la carte CPS. Comme décrit ci-avant, c'est le serveur distant 6 qui créé la page HTML d'accueil de l'application web 7 (étape El) et fait redescendre la page d'accueil dans le tuyau 10 pour ensuite l'afficher à l'utilisateur sur la partie HTML 15-0 du navigateur 15 (étape E2). 20 Selon l'étape E3, le professionnel de santé clique sur le bouton « lire la carte professionnelle sur le menu déroulant de l'interface graphique utilisateur associé au service de santé. Cette action sur le navigateur 15 correspond à la requête LIRECPS. Selon l'étape E4, au chargement de la page acceuil.htm 15.0, un client 25 web socket 15-1 est créé en Javascript. Le client web socket 15-1 établit une connexion persistante 39 avec le serveur 17 via la couche de communication websocket 18. Selon l'étape E5, le serveur local 17 via la couche websocket 18 capte la requête LIRECPS. 3063160 16 Selon l'étape E6, le serveur local 17 appelle le module formant adaptateur 26 JNA en rapport avec la requête émise, ici la méthode JNA_LireCPS. Selon l'étape E7, le module 26 appelle la méthode 19 de l'API du GIE en rapport avec la méthode JNA_LireCPS, ici la méthode SSV_LireCartePs. 5 Selon l'étape E8, les fournitures SESAM Vitale 19 détectent le lecteur installé et utilise l'application API appropriée. Par exemple, l'API GALSS 27 est utilisée si l'on se trouve en présence d'un lecteur 3 agréé GIE SESAM vitale sinon l'API 21 est utilisée en présence de lecteurs 5 de type PC/SC. 10 Selon l'étape E9, l'API 21 correspondant aux lecteurs 5 de type PC/SC est choisie. La lecture est lancée sur le lecteur 5 où se trouve la carte CPS. Selon l'étape El 0, les données de la carte CPS sont lues. Selon l'étape El 1, l'API 21 de type PC/SC récupère les données lues sur la carte CPS et les transmet aux fournitures 19 FSV. 15 Selon l'étape E12, l'API 19 FSV récupère les données remontées par l'API PC/SC 21 et les transmet à l'API formant adaptateur 26 JNA. Selon l'étape E13, l'API formant adaptateur JNA 26 récupère les données remontées par l'API FSV 19 et les transmet à la couche de communication Web Socket 18. 20 Selon l'étape E14, la couche Web socket 18 renvoi une réponse au navigateur 15 via la connexion 39 avec les données de la carte CPS. Selon l'étape E15 le navigateur reçoit les données de la carte CPS au format hexadécimal. 25 Ensuite, le mode opératoire relatif à la lecture de la carte CPS peut comprendre un flux de données entre l'équipement utilisateur 4 et le serveur distant 6 selon les étapes suivantes. 3063160 17 Selon l'étape E16, les données sont envoyées selon la méthode «POST » sur le serveur WEB distant 6. En pratique, on utilise la librairie JQUERY Ajax dans le code javascript pour communiquer avec le serveur distant 6. On envoie les données en 5 format hexadécimal ou XML suivant l'API utilisée. Selon l'étape E17, les données passent dans le tuyau sécurisé 10 et arrivent au serveur WEB distant 6. Selon l'étape E18, les données sont décodées pour être traduites en texte clair. 10 Selon l'étape E19, la vue HTML avec les données de la carte CPS est créée au niveau du serveur distant 6 puis redescend dans le tuyau sécurisé 10 à destination du navigateur 15. Selon l'étape E20, les données de la carte CPS sont affichées à l'utilisateur via le navigateur 15. 15 Plusieurs méthodes des fournitures SESAM Vitale s'offrent à l'utilisateur. En premier lieu, l'API GIE SESAM Vitale (Fourniture SESAM Vitale) 19 permet de communiquer avec le matériel de lecture. La liste des points d'entrées les plus importants sont les suivants : LireCartePs : permet de lancer la lecture de la carte CPS ; 20 LireDroitsVitale : permet de lire la carte vitale du patient ; FormaterFacture permet de formater une facture ; SecuriserFacture permet de créer des factures désynchronisées (besoin de deux sécurisations) Cette méthode permet de faire la seconde sécurisation ; 25 FormaterLot permet de créer un lot de facture ; FormaterFichier permet de créer un lot de fichier ; 3063160 18 TraduireARLpermet de traduire en texte clair un retour ARL (retour du serveur assurance maladie). En prenant en compte les autres API de type CryptoLib 20 et MICA 22, deux méthodes supplémentaires sont possibles et sont les suivantes : 5 ObtenirAssertionCPS qui permet d'obtenir une assertion de carte CPS pour les téléservices Assurance maladie et- CreerAssertionVitale qui permet de créer une assertion de carte Vitale pour les téléservices Assurance maladie. On observe que l'équipement utilisateur peut avoir plusieurs 10 configurations notamment un lecteur SESAM Vitale, un lecteur PC/SC, deux lecteurs PC/SC, les deux ensembles, et d'autres combinaisons. La couche web socket en s'appuyant sur les API Mica et CryptoLib permet de détecter la configuration lecteur de l'équipement utilisateur. Pour fonctionner, les Fourniture SESAM Vitale 19 FSV (par exemple pour 15 la lire la carte CPS), ont besoin de connaitre le lecteur qui est configuré sur le poste de travail. Dans ce contexte la commande DetecterLecteursPoste permet de configurer automatiquement l'API FSV du GIE en cherchant la configuration lecteur sur l'équipement utilisateur. En référence aux figures 4 et 5 on a représenté à titre d'exemple un 20 schéma fonctionnel et l'organigramme de données associé à une assertion de carte Vitale. Le serveur distant 6 créé la page HTML d'accueil du service de santé (étape V1) et fait redescendre la page d'accueil dans le tuyau 10 pour ensuite l'afficher à l'utilisateur sur la partie HTML 15-0 du navigateur 15 25 (étape V2). Selon l'étape V3, le professionnel de santé clique sur le bouton « lire la carte vitale sur le menu déroulant du portail/interface utilisateur 15-0 associé au service de santé. Cette action sur le navigateur 15 correspond à la requête CREERASSERTIONVITALE 3063160 19 Comme vu précédemment, une connexion web socket persistante 39 est établie entre le client web socket 15-1 et le serveur local 17. Selon l'étape V4, la commande est envoyée au client Web socket 15-1 en JavaScript. La requête CREERASSERTIONVITALE est émise vers le 5 module 16. Selon l'étape V5, le serveur local 17 via la couche de communication web socket 18 capte la requête CREERASSERTIONVITALE. Selon l'étape V6, le module 16 appelle l'application logicielle formant adaptateur 26 JNA en rapport avec la requête émise, en l'occurrence ici la 10 méthode JNA_CreerAssertionVitale. Selon l'étape V7, le module 16 appelle la méthode de l'API MICA 22 en rapport avec la méthode JNA_CreerAssertionVitale(...), ici la méthode MICA_SignatureCarteVitale. Selon l'étape V8, l'application 22 MICA détecte le lecteur installé et utilise 15 l'API appropriée. L'API GALSS 27 est utilisée si l'on se trouve en présence d'un lecteur 3 sinon API 21 en cas de lecteur 5 de type PC/SC. Selon l'étape V9, l'API PC/SC est choisie. La génération d'une signature vitale est lancée sur le lecteur 5 où se trouve la carte Vitale. Selon l'étape V10, la signature de la carte vitale est créée. 20 Selo l'étape V11, l'API 21 PC/SC récupère la signature de la carte Vitale et la transmet à l'API 22 MICA. Selon l'étape V12, l'API MICA 22 récupère la signature Vitale par l'API 21 PC/SC et la transmet à l'API 26 JNA. Selon l'étape V13, l'API JNA 26 récupère la signature Vitale remontée par 25 l'API MICA 22 et la transmet à la couche de communication Web Socket 18. 3063160 20 Selon l'étape V14, le code fourni par le GIE pour générer l'assertion Vitale avec la signature est remonté via la couche 18 pour être renvoyé par la couche 18 en format xml sur le serveur client local 17. Selon l'étape V15, le navigateur 15 reçoit l'assertion de la carte Vitale au 5 format xml en provenance du serveur local 17. Selon l'étape V16, les données sont envoyées selon la méthode «POST » sur le serveur WEB 6 au format XML Selon l'étape V17 les données passent dans le tuyau sécurisé 10 et arrivent au serveur WEB 6. 10 Selon l'étape V18, l'assertion Vitale est récupérée en XML et sauvegardée pour l'utilisateur courant. Selon l'étape V19, l'assertion Vitale est disponible sur le serveur distant 6 pour utiliser les télé-services L"assertion Vitale est disponible pour toutes les requêtes web services du 15 serveur de l'assurance maladie. L'assertion garantit que la carte Vitale est présente dans le lecteur. Par exemple cette assertion expire au bout de 20 minutes. Par exemple avec l'assertion Vitale, une requête télé-service ADRI peut être envoyée. En retour on obtient les données du patient avec les droits 20 les plus à jour au niveau du serveur de l'assurance maladie. En référence à la figure 6, on a représenté à titre d'exemple un organigramme de données associé à une facturation avec un mode hors connexion avec le serveur distant, c'est-à-dire sans connexion internet. Selon l'étape S1, la connexion internet n'étant pas disponible, l'application 25 web cliente 7-C va utiliser les API 19, 20,21,22 et 26 qui sont disponibles sur le serveur client local 17 suite à une précédente connexion internet.. On se trouve dans un environnement X86 grâce à l'émulation. Une base de données locale (non représentée) se trouve sur le client 17. Une 3063160 21 synchronisation est effectuée avec la base de données distante 9 lorsque la connexion internet revient. Selon l'étape S2, l'utilisateur, par exemple le professionnel de santé, accède à l'application cliente 7-C. Elle s'est lancée automatiquement lors 5 de la perte de connexion internet. Un service capte les évènements de pertes de connexion. Dès que la connexion est perdue, le service bascule sur l'application cliente locale 7C. Dès que la connexion internet revient le service relance l'application sur le serveur distant 6 et effectue une synchronisation pour envoyer les 10 données créées en local sur le serveur distant 6. Selon l'étape S3, le professionnel de santé donne l'ordre dans le navigateur 15 de formater une facture. Selon l'étape S4, le navigateur 15 envoie l'ordre «FormaterFacture» à l'API concernée 19, 21 ou 22. Comme décrit précédemment l'API est 15 différente suivant l'ordre envoyé. Pour formater une facture il faut utiliser l'API FSV 19. L'API FSV 19 communique avec les lecteurs 3 ou 5 pour vérifier que les cartes CPS et Vitale sont présentes et que la donnée hexadécimale de la facture correspond aux cartes insérées dans les lecteurs 3 ou 5. 20 Lorsque les deux cartes CPS et Vitale sont présentes dans les lecteurs, la facture est validée. L'API FSV 19 sécurise la facture puis remonte le nouveau flux hexadécimal encodé au format B2 vers l'application JNA 26 qui sert de passerelle comme décrit précédemment. Le format B2 est un format définit par les caisses d'assurance maladie. 25 Cet encodage est normé. Selon l'étape S5, la donnée est stockée localement sur le serveur client 17 le temps que la connexion internet soit retrouvée et que la synchronisation soit effectuée. L'application JNA 26 retourne ensuite le nouveau flux hexadécimal vers le serveur local 17. 3063160 22 Selon l'étape S6, le nouveau flux hexadécimal de la facture est stocké dans la base de données locale cliente. Selon l'étape S7, lorsque la connexion internet revient, l'application cliente 7-C retourne la donnée sur le serveur distant 6 par synchronisation. La 5 connexion entre le client local 7-C et le serveur distant 6 est sécurisé dans le tuyau TLS SSL 10. Cette connexion est garantie à l'aide du certificat de la carte professionnel de santé Selon l'étape S8, le nouveau flux hexadécimal de la facture est stocké dans la base de données 9 du serveur distant 6. 10 En référence aux figures 7 et 8, on a représenté un mode de réalisation dans lequel l'équipement utilisateur comprend une tablette tactile 4 telle que celle décrite en référence aux figures 1 à 6 et un smartphone 100 par exemple de type 'PHONE Tm ou Android Tm. Ce mode de réalisation peut s'appliquer à toutes les configurations et systèmes d'exploitation de 15 processeur ARM/RISC c'est-à-dire Apple IOS Tm et ANDROID Tm ou encore Windows 10TM à instructions ARM avec émulateur x86. En pratique l'architecture comprend deux applications dont l'une 146 s'occupe de la communication avec le matériel de lecture 2 et dont l'autre 144 s'occupe de la communication sans fil (Bluetooth Tm ou Wifi) ou filaire 20 (dans le cas d'une connexion avec un PC de bureau Windows TM ou MAC OS Tm) avec l'équipement utilisateur client 4 via une communication 139. Le smartphone 100 dispose d'une connectivité cellulaire (4G ou équivalent). Le smartphone partage sa connexion avec d'autres appareils 4 de type tablette ou ordinateur PC. Le partage de connexion 139 peut 25 être par exemple du Bluetooth (profil PAN) ou du wifi. Le partage de connexion 139 permet d'établir un réseau local (LAN) et internet (WAN) entre l'appareil 4 et le smartphone 100. Les deux applications 144 et 146 communiquent entre elles via un socket TCP 150. En pratique, l'application 144 est équipée d'une couche cliente 3063160 23 socket TCP 140-C configurée pour communiquer avec le serveur socket TCP 140-S de l'application 146. Par exemple, le téléphone IPhoneTM avec IOS et processeur ARM est logé avec le matériel de lecture 2 (ici deux lecteurs 5-1 et 5-2 connectés 5 au téléphone via un hub 5-3 et une connexion 33) dans une couverture rigide formant étui 102, de préférence extra-plat. Le téléphone 100 embarque le serveur web socket 17 et la couche web socket 18 dans l'application 144 tandis que les fournitures FSV 19, les API 20, 21, 22, 27 ainsi que l'application formant adaptateur 26 décrites ci- 10 avant en référence aux figures 1 à 6 sont embarquées dans l'application 146. Les couches d'émulation 23 et 24 sont également embarquées dans l'application 146 pour émuler un environnement X86 comme décrit ci-avant. Le téléphone 100 est apte à attendre des connexions clientes émanant de 15 n'importe quel équipement utilisateur 4 formant client (MicrosoftTM, MAC OSTM, IOS Tm, AndroidTM, LinuxTM, Windows10TM) qui se connecte (Bluetooth, wifi, filaire) avec le téléphone 100 et qui souhaite accéder au matériel de lecture 2. La configuration de connexion entre le téléphone 100 et l'équipement 4 se fait à partir d'une application 142 embarquée 20 dans l'application 144 du téléphone 100. Le téléphone 100 est ici utilisé comme un intermédiaire (proxy) entre l'équipement utilisateur 4 et le matériel de lecture 2.. L'avantage de cette configuration est l'indépendance du matériel utilisé. Par exemple, lorsque le professionnel de santé dispose de deux tablettes (par exemple une tablette IPadTM et 25 une tablette SurfaceTM) et qu'il souhaite pouvoir lire des cartes CPS et Vitale sans utiliser un matériel de lecture 2 sur chaque tablette, il utilise alors une configuration dans laquelle il loge son téléphone 100 dans l'étui 102 équipé du matériel de lecture 2 et chaque tablette 4 vient se connecter l'une après l'autre au téléphone 100 via la connexion 139. 3063160 24 Il est à remarquer en outre que la connexion sécurisée 10 entre le serveur distant 6 et l'équipement utilisateur 4 s'effectue via le téléphone 100. En effet, le certificat (lors de son extraction de la carte CPS) est extrait sur le téléphone 100 car les lecteurs 3 ou 5 se retrouvent rattachés au téléphone 5 100. Une application 222 sur la tablette 4 récupère le certificat CPS afin de l'ajouter au magasin de certificat 223 de la tablette 4. Avec le certificat CPS dans le magasin de certificat 223 de la tablette 4, le navigateur sur la tablette 4 est ainsi apte à se connecter au serveur distant 6 de manière sécurisée. En effet, en référence aux figures 1 à 6, le matériel de lecture 10 2 se trouve rattaché à la tablette 4 donc le certificat de la carte CPS pour sécuriser la connexion est extrait sur la tablette 4 où se trouve les lecteurs 2. Ce n'est plus le cas en référence aux figures 7 et 8 car on déporte les lecteurs 2 sur un autre appareil (smartphone 100). Pour pouvoir établir une connexion sécurisée, un navigateur 15 cherche dans le magasin de 15 certificat 223 de la machine 4 où il est lancé mais il ne le trouvera pas. Pour y remédier, une application native 222 est créée sur la tablette 4 où se trouve le navigateur 15. L'application 222 communique avec le serveur local 17 et la couche web socket 18 du smartphone 100 afin de récupérer le certificat CPS et l'ajouter dans le magasin de certificat 223 de la tablette 20 4. Lors de l'extraction de la carte CPS du matériel de lecture 2, une commande est envoyée à la tablette 4 via la couche web socket 18 et le canal bidirectionnel 139, afin de retirer le certificat CPS du magasin 223 et ainsi casser la connexion sécurisée 10 comme cela est exigé par le CDC 25 du GIE SESAM-Vitale. REVENDICATIONS1. Système de traitement de données pour permettre l'accès sécurisé à un service de santé (7-S) hébergé dans un serveur distant (6) depuis un équipement utilisateur mobile (4) associé à un lecteur de carte (2), caractérisé en ce que l'équipement utilisateur mobile (4) comprend : - un dispositif à processeur (12) à instructions RISC/ARM; - un module d'application cliente (7-C) associé au service de santé (7-S) et accessible via un navigateur web (15); - un module (16) formant serveur local (17) associé à une couche de communication (18) et configuré pour communiquer avec le module d'application cliente (7-C) via un canal de communication locale (39) établi entre le serveur local (17) et le navigateur (15) ; - un module de traitement de carte (21, 27); - au moins une interface de programmation applicative prédéterminée (19, 20, 22) compilée en environnement X86 et configurée pour permettre au module de traitement de carte (21, 27) de communiquer avec le lecteur de carte (2); - une application logicielle formant adaptateur (26) configurée pour appeler une interface de programmation applicative choisie (19, 20, 22); et en ce que le module d'application cliente (7-C) comprend au moins un mode opératoire émulé en environnement X86 (23, 24) dans lequel : - le module d'application cliente (7-C) émet une requête d'accès de carte (LireCPS, LirecarteVitale, ObtenirassertionCPS, Creerassertionvitale, FormaterFacture) via le navigateur (15); - en réponse à la requête ainsi reçue à travers le canal de communication locale (39), le serveur local (17) génère une commande d'accès 3063160 26 correspondante (SSV_IireCPS, SSV_lirecartevitale, MICA_signatureVitale, CRYPTOLIB_signatureCPS, SSV_FormaterFacture) ; - en réponse à la commande ainsi reçue, l'application formant adaptateur (26) lance l'interface de programmation applicative choisie (19, 20, 22) 5 pour permettre au module de traitement de carte (21, 27) de communiquer avec le lecteur de cartes correspondant (2, 3, 5) et de transmettre en retour des données de carte dans un format prédéfini à l'application formant adaptateur (26) qui les transmet ensuite au serveur local (17) pour être enfin communiquées au module d'application cliente (7-C) pour 10 traitement. 2. Système de traitement selon la revendication 1, caractérisé en ce que le navigateur web (15) comprend une interface graphique utilisateur (15-0), obtenue du serveur distant (6) via un canal de communication 15 distante et sécurisée (10) entre le navigateur (15) et le serveur distant (6) sur authentification du certificat du professionnel de santé par le serveur distant (6). 3. Système de traitement selon la revendication 2 dans lequel la 20 requête d'accès de carte (LireCPS, Lirecartevitale, Creerassertion vitale) est émise par l'interface graphique utilisateur (15-0) du service de santé à destination du module serveur client local (17) via la couche de communication locale (18) tandis que les données de carte ainsi obtenues selon le mode opératoire auprès du lecteur de carte sont transmises en 25 retour au navigateur (15) dans un format prédéfini. 4. Système de traitement selon l'une quelconque des précédentes revendications, dans lequel la commande d'accès appartient au groupe formé par une commande de lecture de carte de professionnel de santé 3063160 27 (SSV_LIRECPS), une commande de lecture de carte de patient (SSVLIREVITALE), une commande pour formater la facture (SSV_FormaterFacture); une commande d'assertion de carte de professionnel de santé (CRYPTOLIB_signatureCPS), une commande 5 d'assertion de carte de patient (MICA_signatureVitale). 5. Système de traitement selon la revendication 4 dans lequel la commande d'accès est une commande de lecture de carte de patient et/ou une commande de lecture ce carte de professionnel de santé et en 10 ce que pour chaque lecteur de carte (2, 3, 5), le module de traitement de carte (21, 27) détermine l'interface de programmation applicative (19,20,22) correspondant au lecteur de carte (2, 3, 5), et en ce que pour chaque lecteur de carte (2, 3, 5) ainsi déterminé, le module de traitement de carte (21, 27) accède aux données de carte associées auxdites cartes 15 de professionnel et/ou de patient; et les transmet en retour à l'application formant adaptateur (26). 6. Système selon l'une quelconque des précédentes revendications, caractérisé en ce que l'interface de programmation applicative appartient 20 au groupe formé par les fournitures SESAM Vitale (19), la libraire MICA (22), la librairie CryptoLib (20). 7 Système de traitement selon la revendication 2, caractérisé en ce que le mode opératoire comprend en outre les étapes suivantes : 25 - télécharger les données ainsi obtenues au niveau du module d'application cliente (7-C) sur le serveur distant (6) via le canal de communication distante et sécurisée (10) pour conversion en clair; et 3063160 28 - obtenir des données lisibles en provenance du serveur distant (6) et restituer les données lisibles sur l'interface utilisateur (15-0) du service de santé. 5 8. Système de traitement selon la revendication 6, caractérisé en ce que lorsque la commande d'accès correspond à une commande d'assertion de carte de patient et/ou de carte de professionnel, le mode opératoire comprend en outre les étapes suivantes: - déterminer par l'interface de programmation applicative 10 MICA (22) le lecteur de carte (2, 3, 5) correspondant au lecteur de carte de patient et/ou au lecteur de carte de professionnel de santé; - générer, par le lecteur de carte (2, 3, 5) ainsi déterminé une signature pour la carte correspondante; - transmettre par le lecteur de carte, la signature ainsi 15 générée à l'application formant adaptateur (26) et - obtenir par le module formant serveur local (17) via la couche de communication (18) la signature ainsi générée ; et - générer le certificat correspondant à la signature pour transmission au navigateur (15). 20 9. Système de traitement de données selon la revendication 8, caractérisé en ce que le mode opératoire comprend en outre les étapes suivantes : - télécharger les données ainsi obtenues au niveau du module d'application cliente (7-C) sur le serveur distant (6) via le canal de 25 communication distante et sécurisée (10) pour conversion en clair; et - stocker les données de cartes ainsi téléchargées au niveau du serveur distant (6,9), et - restituer les données à au moins un opérateur de service de santé. 3063160 29 10. Système selon la revendication 1, caractérisé en ce que l'équipement utilisateur (4) comprend en outre un module émulateur (23, 24) configuré pour émuler en environnement X86. 5 11. Système selon la revendication 1, caractérisé en ce que l'équipement utilisateur (4) comprend en outre une base de données locale cliente propre à stocker les données des cartes obtenues auprès des lecteurs de carte (2, 3, 5) en absence de connexion avec le serveur distant (6). 10 12. Système selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend en outre un smartphone (100) équipé d'une première application (146) propre à s'occuper de la communication avec le lecteur de carte (2) et d'une seconde application (144) propre à s'occuper de la communication avec l'équipement utilisateur (4) via une 15 connexion appropriée (139), le smartphone (100) jouant le rôle d'intermédiaire entre l'équipement utilisateur (4) et le lecteur de carte (2). 13. Système selon la revendication 12 dans lequel le lecteur de carte (2, 5-1, 5-2, 5-3) est logé dans un étui rigide (102), en association avec 20 l'équipement utilisateur (4) ou le smartphone (100). 14. Procédé de traitement de données pour permettre l'accès sécurisé à un service de santé hébergé dans un serveur distant (6) depuis un équipement utilisateur mobile (4) associé à un lecteur de carte (2, 3, 5) 25 mis en oeuvre par le système de traitement selon l'une des revendications 1 à 13. 15. Programme produit d'ordinateur téléchargeable depuis un réseau de communication (11) et/ou stocké sur un support lisible par ordinateur et/ou 30 exécutable par microprocesseur de type ARM/RISC (12) caractérisé en ce 3063160 qu'il comprend des instructions de code de programme pour l'exécution du procédé selon la revendication 14.