FR3063160A1 - Systeme et procede de traitement de donnees pour permettre l'acces securise a un service heberge dans un serveur distant depuis un equipement utilisateur mobile associe a un lecteur de carte. - Google Patents
Systeme et procede de traitement de donnees pour permettre l'acces securise a un service heberge dans un serveur distant depuis un equipement utilisateur mobile associe a un lecteur de carte. Download PDFInfo
- Publication number
- FR3063160A1 FR3063160A1 FR1770173A FR1770173A FR3063160A1 FR 3063160 A1 FR3063160 A1 FR 3063160A1 FR 1770173 A FR1770173 A FR 1770173A FR 1770173 A FR1770173 A FR 1770173A FR 3063160 A1 FR3063160 A1 FR 3063160A1
- Authority
- FR
- France
- Prior art keywords
- card
- module
- data
- user equipment
- application
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000012545 processing Methods 0.000 title claims abstract description 41
- 238000000034 method Methods 0.000 title claims description 18
- VJYFKVYYMZPMAB-UHFFFAOYSA-N ethoprophos Chemical compound CCCSP(=O)(OCC)SCCC VJYFKVYYMZPMAB-UHFFFAOYSA-N 0.000 title description 2
- 230000036541 health Effects 0.000 claims abstract description 45
- 230000006854 communication Effects 0.000 claims abstract description 41
- 238000004891 communication Methods 0.000 claims abstract description 41
- 230000004044 response Effects 0.000 claims abstract description 9
- 241000618809 Vitales Species 0.000 claims description 22
- 229910052618 mica group Inorganic materials 0.000 claims description 14
- 239000010445 mica Substances 0.000 claims description 12
- 230000005540 biological transmission Effects 0.000 claims description 6
- 238000006243 chemical reaction Methods 0.000 claims description 4
- 238000003672 processing method Methods 0.000 claims description 2
- 239000000463 material Substances 0.000 description 15
- 238000010586 diagram Methods 0.000 description 9
- 102000006822 Agouti Signaling Protein Human genes 0.000 description 6
- 108010072151 Agouti Signaling Protein Proteins 0.000 description 6
- 230000008901 benefit Effects 0.000 description 6
- 238000012360 testing method Methods 0.000 description 6
- 230000009471 action Effects 0.000 description 4
- 239000008186 active pharmaceutical agent Substances 0.000 description 4
- 230000002457 bidirectional effect Effects 0.000 description 2
- 238000009434 installation Methods 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 230000002085 persistent effect Effects 0.000 description 2
- 238000010200 validation analysis Methods 0.000 description 2
- VYZAMTAEIAYCRO-UHFFFAOYSA-N Chromium Chemical compound [Cr] VYZAMTAEIAYCRO-UHFFFAOYSA-N 0.000 description 1
- 239000000654 additive Substances 0.000 description 1
- 230000007175 bidirectional communication Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
- G06F21/35—User authentication involving the use of external additional devices, e.g. dongles or smart cards communicating wirelessly
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
- G06F9/45508—Runtime interpretation or emulation, e g. emulator loops, bytecode interpretation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
- G06F9/45529—Embedded in an application, e.g. JavaScript in a Web browser
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Hardware Design (AREA)
- Telephonic Communication Services (AREA)
- Mobile Radio Communication Systems (AREA)
- Information Transfer Between Computers (AREA)
Abstract
Le système de traitement de données permet 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). L'équipement utilisateur mobile (4) comprend un dispositif à processeur (12) à instructions RISC/ARM. Le module d'application cliente (7-C) comprend 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, Creerassertionvitale, FormaterFacture, ObtenirassertionCPS) 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 correspondante (SSV_lireCPS, 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) 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 traitement.
Description
063 160
70173 ® RÉPUBLIQUE FRANÇAISE
INSTITUT NATIONAL DE LA PROPRIÉTÉ INDUSTRIELLE © N° de publication :
(à n’utiliser que pour les commandes de reproduction)
©) N° d’enregistrement national
COURBEVOIE © Int Cl8 : G 06 F21/44 (2017.01)
DEMANDE DE BREVET D'INVENTION
A1
| ©) Date de dépôt : 22.02.17. (© Priorité : | © Demandeur(s) : IMAGINE EDITIONS— FR. |
| @ Inventeur(s) : MALKA HARRY et JUSTE AYMERIC. | |
| ©) Date de mise à la disposition du public de la demande : 24.08.18 Bulletin 18/34. | |
| ©) Liste des documents cités dans le rapport de recherche préliminaire : Se reporter à la fin du présent fascicule | |
| (© Références à d’autres documents nationaux apparentés : | ® Titulaire(s) : IMAGINE EDITIONS. |
| ©) Demande(s) d’extension : | (© Mandataire(s) : LIBERTA IP. |
SYSTEME ET PROCEDE DE TRAITEMENT DE DONNEES POUR PERMETTRE L'ACCES SECURISE A UN SERVICE HEBERGE DANS UN SERVEUR DISTANT DEPUIS UN EQUIPEMENT UTILISATEUR MOBILEâ ASSOCIE A UN LECTEUR DE CARTE.
FR 3 063 160 - A1
Le système de traitement de données permet 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).
L'équipement utilisateur mobile (4) comprend un dispositif à processeur (12) à instructions RISC/ARM. Le module d'application cliente (7-C) comprend 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, Creerassertionvitale, FormaterFacture, ObtenirassertionCPS) 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 correspondante (SSVJireCPS, SSVJirecartevitale, 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) 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 traitement.
27 20
m.
,8~-+
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 connaît 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 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 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 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 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 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 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.
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. II 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. II en est aussi du 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. II en résulte que les composants logiciels CryptoLib et MICA sont aussi peu utilisés actuellement dans les smartphones/tablettes que les fournitures 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 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;
- un module de traitement de carte;
- 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 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;
- 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 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.
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.
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 Windows™, Android LINUX™, Apple iOS™, ce qui favorise l’usage d’un tel système avec des smartphones et tablettes tactiles du marché.
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é.
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.
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 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, 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 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 navigateur et le serveur de service sur authentification du certificat du professionnel de santé par le serveur de service.
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 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 à 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 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 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 à 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.
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 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é.
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:
- 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 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
- 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 :
- 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 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.
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.
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 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 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.
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 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 œuvre par le système de traitement conforme à l’invention.
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 à 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 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 ;
- 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 opératoire correspondant à facturer une feuille de soin é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 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 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 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 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 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
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 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 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 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 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 iOS™ », ou « ANDROID LINUX™ ou encore « Windows 10™ » compilé en instructions ARM avec émulateur x86 pour l’exécution d’applications standards 14 au format Android, IOS ou Windows 10™. 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 «Firefox™», «Google Chrome™», «Safari™», ou encore «Internet Explorer™ » ou «chrome™» 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. 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 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.cgmevitale.hellodoc.com (étape E1, figures 2 et 3). Ensuite le serveur distant 6 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 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 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 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.
Le module 16 est compatible avec tous les systèmes d’exploitation OS Windows™, Apple MAC Os™ et Linux™ dans le monde X86. II est aussi compatible avec IOS™ et ANDROID™ avec la couche d’émulation X86 sur ARM.
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 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 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 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 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 (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.
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 Exagear™. L’émulateur 23 est une machine virtuelle qui implémente virtuellement un microprocesseur en environnement X86 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 10™.
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é DI pour Dispositif Intégré. Toutefois ce cahier des charges DI est très contraignant de par son coût de développement, de par son coût de 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 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.
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 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 de carte comprend un module de gestion de type PCSCLITE 21 (pour linux™ ou Apple OS™) ou un service de carte à puce (pour Windows™) 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 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 E1) 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).
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 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.
Selon l’étape E6, le serveur local 17 appelle le module formant adaptateur
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 ΙΆΡΙ du GIE en rapport avec la méthode JNA_LireCPS, ici la méthode SSV_LireCartePs.
Selon l’étape E8, les fournitures SESAM Vitale 19 détectent le lecteur installé et utilise l’application API appropriée. Par exemple, ΙΆΡΙ GALSS est utilisée si l’on se trouve en présence d’un lecteur 3 agréé GIE SESAM vitale sinon ΙΆΡΙ 21 est utilisée en présence de lecteurs 5 de type PC/SC.
Selon l’étape E9, ΙΆΡΙ 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 E10, les données de la carte CPS sont lues.
Selon l’étape E11, ΙΆΡΙ 21 de type PC/SC récupère les données lues sur la carte CPS et les transmet aux fournitures 19 FSV.
Selon l’étape E12, ΙΆΡΙ 19 FSV récupère les données remontées par ΙΆΡΙ PC/SC 21 et les transmet à ΙΆΡΙ formant adaptateur 26 JNA.
Selon l’étape E13, ΙΆΡΙ formant adaptateur JNA 26 récupère les données remontées par ΙΆΡΙ FSV 19 et les transmet à la couche de communication Web Socket 18.
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.
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.
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 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.
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.
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 ;
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 ;
FormaterLot permet de créer un lot de facture ;
FormaterFichier permet de créer un lot de fichier ;
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 :
ObtenirAssertionCPS qui permet d’obtenir une assertion de carte CPS pour les téléservices Assurance maladie etCreerAssertionVitale 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 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 la lire la carte CPS), ont besoin de connaître 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 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 (é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
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 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 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 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.
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 l’API MICA 22 et la transmet à la couche de communication Web Socket 18.
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 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.
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 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 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 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 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 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 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 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.
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. 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.
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 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.
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 IPHONE™ ou Android™. Ce mode de réalisation peut s’appliquer à toutes les configurations et systèmes d’exploitation de processeur ARM/RISC c’est-à-dire Apple IOS™ et ANDROID™ ou encore Windows 10™ à 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™ ou Wifi) ou filaire (dans le cas d’une connexion avec un PC de bureau Windows™ ou MAC OS™) 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 ê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 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 IPhone™ avec IOS et processeur ARM est logé avec le matériel de lecture 2 (ici deux lecteurs 5-1 et 5-2 connectés 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 ciavant 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 ciavant.
Le téléphone 100 est apte à attendre des connexions clientes émanant de n’importe quel équipement utilisateur 4 formant client (Microsoft™, MAC OS™, IOS™, Android™, Linux™, WindowslO™) 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 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 IPad™ et une tablette Surface™) 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.
II 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 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 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 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 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 du GIE SESAM-Vitale.
Claims (15)
- 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 correspondante (SSVJireCPS, SSVJirecartevitale, 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) 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 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 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 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 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é (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 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 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 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 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 :- 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- 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é.
- 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 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 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).
- 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 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é.
- 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.
- 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).
- 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 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 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) mis en œuvre 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 exécutable par microprocesseur de type ARM/RISC (12) caractérisé en ce qu’il comprend des instructions de code de programme pour l’exécution du procédé selon la revendication 14.1/832;332/8
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1770173A FR3063160B1 (fr) | 2017-02-22 | 2017-02-22 | Systeme et procede de traitement de donnees pour permettre l'acces securise a un service heberge dans un serveur distant depuis un equipement utilisateur mobile associe a un lecteur de carte. |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1770173 | 2017-02-22 | ||
| FR1770173A FR3063160B1 (fr) | 2017-02-22 | 2017-02-22 | Systeme et procede de traitement de donnees pour permettre l'acces securise a un service heberge dans un serveur distant depuis un equipement utilisateur mobile associe a un lecteur de carte. |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3063160A1 true FR3063160A1 (fr) | 2018-08-24 |
| FR3063160B1 FR3063160B1 (fr) | 2019-04-05 |
Family
ID=59297143
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1770173A Active FR3063160B1 (fr) | 2017-02-22 | 2017-02-22 | Systeme et procede de traitement de donnees pour permettre l'acces securise a un service heberge dans un serveur distant depuis un equipement utilisateur mobile associe a un lecteur de carte. |
Country Status (1)
| Country | Link |
|---|---|
| FR (1) | FR3063160B1 (fr) |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2974471A1 (fr) * | 2011-04-19 | 2012-10-26 | Sephira | Traitement de donnees pour permettre l'acces a un service heberge dans un serveur |
-
2017
- 2017-02-22 FR FR1770173A patent/FR3063160B1/fr active Active
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2974471A1 (fr) * | 2011-04-19 | 2012-10-26 | Sephira | Traitement de donnees pour permettre l'acces a un service heberge dans un serveur |
Non-Patent Citations (3)
| Title |
|---|
| ANONYMOUS: "Le < DSC-BT > de Sylyca, un lecteur PC/SC de cartes CPS et Vitale pour des applications sur smartphone et tablette", 24 November 2016 (2016-11-24), XP055413570, Retrieved from the Internet <URL:http://comparatif-logiciels-medicaux.fr/actualite/le-dsc-bt-de-sylyca-un-lecteur-pcsc-de-cartes-cps-et-vitale-pour-des-applications-sur-smartphone-et-tablette> [retrieved on 20171009] * |
| CORBIN DAVENPORT: "CrossOver for Android runs Windows programs on x86 Android tablets and Chromebooks", 25 August 2016 (2016-08-25), XP055413637, Retrieved from the Internet <URL:http://www.androidpolice.com/2016/08/25/crossover-android-runs-windows-programs-x86-android-tablets-chromebooks/> [retrieved on 20171009] * |
| WORDPRESS STUDIO: "ExaGear Strategies is an emulator for Android that enables running old-school PC strategies.", 3 December 2016 (2016-12-03), XP055413650, Retrieved from the Internet <URL:https://web.archive.org/web/20161203124950/https://eltechs.com/product/exagear-mobile/exagear-strategies/> [retrieved on 20171009] * |
Also Published As
| Publication number | Publication date |
|---|---|
| FR3063160B1 (fr) | 2019-04-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11036373B1 (en) | Mobile device transparent screen overlay | |
| EP3243178B1 (fr) | Procédé de traitement d'une transaction à partir d'un terminal de communication | |
| JP6756905B2 (ja) | Ｕｒｌベースの二次元コードに関連付けたサービスの管理 | |
| US10152579B2 (en) | Network information system with license registration and method of operation thereof | |
| CN101313552A (zh) | 提供便携的用户环境的分布式计算架构及相关方法 | |
| TW201545086A (zh) | 藉由近場通訊技術在行動裝置上安全移轉電子票證的系統及方法 | |
| EP3163487B1 (fr) | Procédé de sécurisation de traitement de données transactionnelles, terminal et programme d'ordinateur correspondant | |
| EP3132399B1 (fr) | Procédé de traitement de données transactionnelles, dispositif et programme correspondant | |
| US10805427B1 (en) | Backup and restore of customer devices | |
| EP3154284B1 (fr) | Procédé d'appairage dans un dispositif périphérique et dans un terminal de communication, dispositifs et programme correspondants | |
| FR3063160A1 (fr) | Systeme et procede de traitement de donnees pour permettre l'acces securise a un service heberge dans un serveur distant depuis un equipement utilisateur mobile associe a un lecteur de carte. | |
| EP3132404B1 (fr) | Module d'émulation d'au moins une carte de paiement, procédé, dispositif de paiement, produit programme d'ordinateur et medium de stockage correspondants | |
| EP4078922B1 (fr) | Procédé d'obtention d'une commande relative à un profil d'accès réseau d'un module de sécurité de type euicc | |
| EP3278542B1 (fr) | Système et procédé d'exécution d'une application dans un terminal muni d'une carte a puce | |
| WO2020254761A1 (fr) | Système d'applications de service pour terminaux de paiement | |
| EP3349161B1 (fr) | Procédé de traitement d'une transaction de paiement, borne de paiement et programme correspondant | |
| WO2020052753A1 (fr) | Système intermédiaire destiné à faciliter la communication entre des cartes à puce intelligentes virtuelles et une interface de carte à puce intelligente | |
| Lin et al. | Android Forensics | |
| EP2510671A1 (fr) | Procede de sauvegarde de donnees contenues dans un terminal communiquant portable | |
| WO2017133988A1 (fr) | Procede d'etablissement de communication securise entre un terminal de paiement et un dispositif d'encaissement | |
| EP3624417A1 (fr) | Communication sécurisée entre un module cam et un terminal mobile disposant d'une connexion au réseau internet | |
| Sabharwal et al. | Banking by the use of handheld devices & gadgets like Smart-phones, Tablets (Using Banking Applications & Widgets that are Based on Mobile Operating Systems like Android etc) | |
| EP2833262B1 (fr) | Procédé d'installation d'une application sur un élément sécurisé | |
| Shriwas et al. | Comparative Study of Cloud Computing and Mobile Cloud Computing | |
| WO2023170186A1 (fr) | Dispositif portable et autonome de sécurisation de transfert de données et procédé correspondant |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20180824 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |
|
| PLFP | Fee payment |
Year of fee payment: 5 |
|
| PLFP | Fee payment |
Year of fee payment: 6 |
|
| PLFP | Fee payment |
Year of fee payment: 7 |
|
| PLFP | Fee payment |
Year of fee payment: 8 |