Dossier Médico-Social Partagé, Nomade et Sécurisé Revue du projet DMSP T0+12 27 novembre 2007

1. Dossier Médico-Social Partagé, Nomade et Sécurisé Revue du projet DMSP T0+12 27 novembre 2007 Avec la participation de

2. Plan • Objectifs du projet • Analyse des besoins • Dimensions du problème • Solution DMSP • Secure Portable Token • Scénarios d’usage • Architecture fonctionnelle • Architecture • Eclairage sur quelques verrous technologiques • Démonstrations • Serveur central et interface Web • Secure Portable Token • SGBD et dossiers embarqués • Plan de travail

3. Plan • Objectifs du projet • Analyse des besoins • Dimensions du problème • Solution DMSP • Secure Portable Token • Scénarios d’usage • Architecture fonctionnelle • Architecture • Eclairage sur quelques verrous technologiques • Démonstrations • Serveur central et interface Web • Secure Portable Token • SGBD et dossiers embarqués • Plan de travail

4. DMSP : Dossier Médico-Social Partagé • Améliorer la coordination et la qualité des soins et des prestations sociales dans deux coordinations gérontologiques des Yvelines (ALDS et COGITEY) … • … par la mise en œuvre d’une plate-forme expérimentale de dossier médico-social partagé, accessibleau chevet du patient et fortement sécurisé • Expérimentation auprès d’une centaine de patients et professionnels médico-sociaux (PMS) volontaires • Réflexion sur l’adaptabilité à d’autres contextes • Populations en situation de précarité ou de handicap • Prestations à domicile

5. Point de départ de la réflexion • Dossier partagé du réseau Emile (ALDS) • Dossier médico-social papier (classeur vert) • Très bénéfique pour la coordination mais … • Absence totale de confidentialité au chevet du patient • tout le monde voit tout : entourage, auxilliaire de vie, infirmière … • Inconciliable avec des situations humainement complexes • Faible mobilité • souvent incomplet • peu utile pour une prise de décision à distance • Saisies multiples des données • Autant de fois que de systèmes d’information à alimenter • Pas de capitalisation avec d’autres initiatives

6. Solution naturelle : serveur Bases de Données • Intérêt de la centralisation des dossiers dans un serveur bases de données (systèmes EHR) • Propriétés essentielles : Complétude, Cohérence, Disponibilité, Durabilité, Sécurité des données • Nombreux programmes EHR nationaux (France, GB, Canada, Allemagne, Autriche, …) • Des résistances persistantes malgré l’intérêt admis des EHR • Public Attitudes Toward Privacy and EHR Programs [West05] • Sensitive health data may be leaked ......................................... 70% • Sharing of personal health data without patient’s knowledge .... 69% • The privacy risk outweigh the benefits ....................................... 48%

7. Limites de l’approche serveur traditionnelle • Sentiment de perte de contrôle sur ses propres données : • Difficulté d’expression du consentement du patient : • Sémantique complexe des données • Politique de contrôle d’accès par défaut • TableDroitsAcces_GIPDMP.pdf • Difficulté d’auditer les accès a posteriori • “Simple” de savoir qui a accédé au dossier, difficile d’auditer ce qu’il y a vu • Conservation mal bornée des données • Réminiscences des données détruites (droit à l’oubli ?) • Pas de garantie de sécurité hors serveur (terminal patient ou médecin) • Pas d’accès déconnecté aux données

8. Dimensions du problème • Expression du consentement : rendre au patient la possibilité d’établir un contrôle strict, compréhensible et observable sur la façon dont ses données sensibles sont échangées. • Conservation des données : rendre au patient la maîtrise de la durée de conservation de ses données, en distinguant les notions de conservation et de durabilité. • Continuité de la sécurité : garantir le même niveau de sécurité quel que soit l’endroit où les données sont hébergées (serveur ou terminal) et quelle que soit la façon dont elles sont manipulées (accès connecté ou non). • Accès déconnecté : permettre des accès déconnectés aux données tout en garantissant une cohérence à terme de ces données. • Applicable à de nombreux contextes de partage de données personnelles

9. Plan • Objectifs du projet • Analyse des besoins • Dimensions du problème • Solution DMSP • Secure Portable Token • Scénarios d’usage • Architecture fonctionnelle • Architecture • Eclairage sur quelques verrous technologiques • Démonstrations • Serveur central et interface Web • Secure Portable Token • SGBD et dossiers embarqués • Plan de travail

10. Elément de la solution : SGBD embarqué dans un Secure Portable Token e.g., 64 Ko e.g., 1 Mo FLASH NOR • Secure Portable Token (SPT) = combinaison de • la capacité sécuritaire d’une carte à puce • la capacité de stockage d’une clé USB • Le SPT permet • d’embarquer des données (de façon temporaire ou permanente) • d’agir comme un co-processeur sécurisé du terminal auquel il est connecté • SGBD + serveur Web embarqués permettent un accès sélectif et sécurisé aux données à partir de n’importe quel navigateur Web USB 2.0 Full Speed FLASH NAND RAM Crypto CPU BUS

11. Complémentarité à une approche serveur Paul (Doc.) Lucie (Inf.) • Répondre aux points de blocage précédents en redonnant au patient un contrôle « physique » sur son dossier (au même titre qu’un dossier papier) • Permettre un accès déconnecté au dossier Données classiques Règles d’accès classiques Données masquées Règles sur D. masquées Clé de chiffrement de Jean Mises à jour de Jean synchronisation Accès déconnecté Serveur BD Accès connecté Internet Lucie synchronisation Jean Jean

12. Statuts des données d’un dossier • Données régulières • Répliquées sur le serveur et le SPT, protégées par la même politique de contrôle d’accès • Données secrètes • Présentes uniquement sur le SPT, accessibles uniquement en présence du patient, durabilité à la charge du patient • Données secrètes durables • Données secrètes répliquées sur le serveur dans un format chiffré, déchiffrable exclusivement par le SPT, durabilité assurée par le serveur • Données restreintes • Echangeables entre un petit cercle de personnes de confiance (équipées d’un SPT) • répliquées sur le serveur dans un format chiffré, déchiffrable exclusivement par les SPT des membres de ce cercle

13. Enregistrement des professionnels médico-sociaux dans la coordination Doc • Le professionnel signe la charte de la coordination. • Le professionnel est ajouté sur le serveur de Santeos. • La coordination fournit un SPT personnalisé contenant son certificat. Doc Serveur Coordinations

14. Enregistrement du patient dans la coordination Jean • Le patient signe une charte de prise en charge • La coordination crée un dossier pour ce patient sur le serveur • La coordination fournit au patient un SPT personnalisé contenant • son certificat • un replica de son dossier • des données globales répliquées du serveur Jean Jean Serveur Coordinations

15. Première visite au chevet du patient Doc • Le patient raffine la matrice de droits par défaut avec l’aide d’un référent • Il signe une charte « informatique » exprimant son consentement • La matrice de droits fait partie intégrante du dossier du patient • Report sur le serveur central (cf. scénario suivant) Jean

16. Préparation d’une visite au chevet du patient Lucie • Le professionnel récupère les nouveaux éléments intégrés dans les dossiers de ses patients. • Ces données sont chargées automatiquement dans le SPT du professionnel (sans que ce dernier n’y ait accès). Synchro en cous Veuillez patienter  Zoe  Lili  Jean Chez Lucie (infirmière) Serveur

17. Interaction avec le dossier au chevet du patient Lucie Jean • Connexion des SPTs dans un terminal mobile • Authentifcation du professionnel (pin code) • Authentifcation du SPT du professionnel auprès du SPT du patient • Synchronisation des dossiers • Saisie de nouvelles données  Jean Synchro en cours Veuillez patienter Saisie de données Saisie de données  Jean

18. Retour de visite Lucie • À la prochaine connexion, le SPT du professionnel transmet automatiquement les nouveaux éléments saisis ou récupérés chez le patient • Ils sont intégrés dans les dossiers des patients sur le serveur.  Jean Synchro en cous Veuillez patienter  Lili  Zoe Chez Lucie (infirmière) Serveur

19. Interaction avec le dossier au cabinet d’un professionnel Doc Jean • Comme précédemment • La synchronisation avec le serveur central est immédiate puisque l’environnement est connecté. Synchro en cours Veuillez patienter Saisie de données Saisie de données  Jean  Jean

20. Echange de données restreintes dans uncercle de confiance k Donnée D k k DocPriv DocPub Jean synchro Doc • Jean veut partager une donnée D exclusivement avec son médecin référent Doc. • le SPT de Jean chiffre D avec une clé secrète k et stocke sur le serveur central • la version chiffrée de D, la clé k, elle-même chiffrée avec la clé publique de Doc. • Doc peut être amené à consulter D sans la présence du patient. • Le SPT de Doc récupère et déchiffre alors la clé k, ce qui lui permet ensuite de déchiffrer D. Donnée D Donnée D

21. Intégration d’une nouvelle donnée dans le dossier hors de la présence du patient k Donnée D Donnée D k k k k Donnée D DocPriv DocPub Jean Doc • La nouvelle donnée se réfère à une donnée déjà existante et hérite donc de son statut : régulière ou restreinte • donnée régulière  Intégrée sur le serveur central et reportée à la prochaine synchro. • donnée restreinte  elle est chiffré avec la clé secrète k ayant servie à chiffrée la donnée initiale. Comme précédemment, k est chiffrée avec la clé publique de Doc et stockée sur le serveur Donnée D Saisie de données synchro

22. Dimensions du problème • Expression du consentement : distinction entre données régulières, secrètes, restreintes. • Conservation des données : distinction entre données régulières et données secrètes durables. • Continuité de la sécurité : aucune donnée en clair en dehors des SPT (hors affichage) • Accès déconnecté : cohérence à terme • Applicable à de nombreux contextes de partage de données personnelles

23. Plan • Objectifs du projet • Analyse des besoins • Dimensions du problème • Solution DMSP • Secure Portable Token • Scénarios d’usage • Architecture fonctionnelle • Architecture • Eclairage sur quelques verrous technologiques • Démonstrations • Serveur central et interface Web • Secure Portable Token • SGBD et dossiers embarqués • Plan de travail

24. Architecture fonctionnelle Authentification Serveur d’identités Web Server Contrôle d’accès Web Server Evaluateur derequêtes Synchronisation Synchronisation SGBD commercial Modules crypto. Servlets Système d’exploitation Indexation / Stockage Servlets FLASH NAND Système d’exploitation Certificats TCP/IP USB Machine virtuelle Java OS multi - thread Browser WEB Système d’exploitation Clés publiques (kpub) Données hébergées sur le terminal de P kP Clés secrètes (k) kpub D. régulières kU D. secrètes durables kU D. secrètes kU D. restreintes k D. secrètes durables kU D. restreintes kU Deltas chiffrés kD FLASH NOR FLASH NOR Accès déconnecté Synchronisation Synchronisation Synchro. Internet Infrastructure FLASH NAND RAM Crypto CPU Accès mobile BUS Serveur Terminal SPT Certificat utilisateur Clé privée (kpriv) Clés secrètes (kU), (k) Clés pour deltas (kD ) Données D. régulières Logiciel

25. Quelques verrous technologiques (1) • Caractéristiques matérielles du Secure Portable Token • CPU 32 bits RISC cadencé à 50MhZ • Peu de RAM (48KB) • Mémoire de stockage NAND Flash • Grande capacité de stockage (à terme plusieurs GB) • Lecture/écriture de granule page (2KB) • Réécriture  effacement d’un bloc (64 pages) • très coûteux • nb d’effacement limité (105) • Écriture « out of place »  ramasse-miettes

26. Quelques verrous technologiques (2) • Requêtes sur de grands volumes de données avec peu de RAM • Accélérer les sélections et les jointures • Etat de l’art • Algorithmes de jointure classiques (e.g., Hash Join)  trop de RAM consommée • Index de jointure entraîne des tris  Consommation de RAM ou écriture • Solution proposée • Climbing Index (CI): index reliant tout tuple aux tuples le référençant dans un schéma arborescent. • Subtree Key Table (SKT): Index de jointure multitable. • La combinaison de Subtree Key Table et de Climbing Index permet d’exécuter des requêtes SPJ complexes avec très peu de RAM. • Articles SIGMOD’07 et VLDB’07

27. Quelques verrous technologiques (3) • Index spécifiques pour NAND-Flash • Combiner performance des recherches sur clé et dynamicité des index • Etat de l’art • Index classiques (arbres)  trop de réécritures • Index dédiés à la NAND-Flash  grande consommation de RAM  émiettement de la Flash • Solution PBFilter • Index = liste séquentielle d’éléments <clé, adresse> • Liste compressée par Bloom Filters, méthode de hachage probabiliste • Partitionnement vertical du résultat de la compression • Efficace jusqu’à des fichiers d’environ 1 million d’enregistrements, très faible consommation RAM, pas d’émiettement • Brevet INRIA-Gemalto

28. Plan • Objectifs du projet • Analyse des besoins • Dimensions du problème • Solution DMSP • Secure Portable Token • Scénarios d’usage • Architecture fonctionnelle • Architecture • Eclairage sur quelques verrous technologiques • Démonstrations • Serveur central et interface Web • Secure Portable Token • SGBD et dossiers embarqués • Plan de travail

29. Démonstrations • Serveur central • Contenu du dossier médico-social • Liste des intervenants • Interface Web d’accès et de mise à jour • Import de données • Secure Portable Token • Capacité de stockage et débit • Serveur Web embarqué • Serveur BD embarqué • Démonstration sur PC des fonctionnalités du serveur en interrogation et mise à jour • Illustration de l’uniformité d’utlisation (avec serveur central) • Illustration de la logique de développement d’une application

30. Plan • Objectifs du projet • Analyse des besoins • Dimensions du problème • Solution DMSP • Secure Portable Token • Scénarios d’usage • Architecture fonctionnelle • Architecture • Eclairage sur quelques verrous technologiques • Démonstrations • Serveur central et interface Web • Secure Portable Token • SGBD et dossiers embarqués • Plan de travail

31. Bilan à T0+12 • Due à T0+12 : plate-forme logicielle préliminaire • Une base de données centralisée de dossiers médico-sociaux accessible via une interface Web • Un protocole de communication sécurisé et un protocole de signature standards • Des outils d’import/export • Un dossier médico-social portable sur SPT sans contrôle d’accès ni synchronisation  léger retard dû à une incertitude de plate-forme • Travail de spécification • Contenu du dossier, cartographie des acteurs, description des scénarios d’usage, architecture fonctionnelle, 1er analyse de la gestion des droits • Autres éléments de valorisation • Colloques : PariSTIC (ANR), INRIA-Industrie, Protection de l’individu numérisé (CNRS), GerontExpo-HIT (Health Information Technologies), cartes2007 • Publications collectives: soumission journal international, article invité • Brevet européen INRIA-Gemalto • Projet ANR PlugDB

32. Plan de travail •  T0+18 • Spécifications détaillées de • Moteur SGBD embarqué • Méthodes de protection des données (droits d’accès, chiffrement des données, gestion des certificats, protocoles d’échange de clés) • Protocole de synchronisation et Import/export • OS et API du SPT • Portage total du SGBD embarqué sur émulateur matériel (et premiers test sur SPT ?) •  T0+24 • Développement du protocole de synchronisation et des outils d’export • Développement des méthodes de protection des données • Application Serveur V2 et APA ? • Plate-forme logicielle intermédiaire permettant un démarrage de l’expérimentation

33. Questions ?