projet dmsp – 27 novembre 2007 1 dossier médico-social partagé, nomade et sécurisé revue du...

Projet DMSP – 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


PlanObjectifs 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












Plan de travail


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é, accessible au 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


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


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%


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


Dimensions du problème

1. 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.

2. 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é.

3. 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).

4. 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












Plan de travail


BUSFLASH NAND

RAM

FLASH NOR

CPU Crypto

Elément de la solution : SGBD embarqué dans un Secure Portable Token

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

e.g., 64 Ko

e.g., 1 Mo


Complémentarité à une approche serveur

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

Paul(Doc.) Jean synchronisation

Internet

synchronisation

ServeurBD

Accès déconnecté

Accès connecté

Lucie

Jean

Données classiquesRègles d’accès classiquesDonnées masquéesRègles sur D. masquéesClé de chiffrement de JeanMises à jour de JeanLucie

(Inf.)


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


Enregistrement des professionnels médico-sociaux dans la coordination

• 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.

CoordinationsServeur

Doc

Doc


Enregistrement du patient dans la coordination

• 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

JeanJean

CoordinationsServeur


Jean

Doc

Première visite au chevet du patient

• 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)


Lucie

Zoe Lili Jean

Préparation d’une visite au chevet du patient

• 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).

Chez Lucie (infirmière)Serveur

Synchro en cousVeuillez patienter


Jean

Lucie

Interaction avec le dossier au chevet du patient

• 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

Jean

Synchro en cours

Veuillez patienter

Saisie de donnéesSaisie de données


Lucie

Zoe

Lili

Jean

Retour de visite

• À 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.

Chez Lucie (infirmière)Serveur

Synchro en cousVeuillez patienter


Jean

Doc

Interaction avec le dossier au cabinet d’un professionnel

• Comme précédemment• La synchronisation avec le serveur central est immédiate

puisque l’environnement est connecté.

Synchro en coursVeuillez patienter

Jean

Saisie de donnéesSaisie de données

Jean


JeanDonnée D

Echange de données restreintes dans uncercle de confiance

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.

kkDocDocPubPub

Donnée D

kkDocDocPrivPriv

Donnée D

synchro

kk

Doc


Donnée D

Jean

Donnée D

kkDonnée DDonnée D

kk

Intégration d’une nouvelle donnée dans le dossier hors de la présence du patient

• 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

kkDocDocPubPub

DocDocPrivPriv

synchro

kk

Doc

Saisie de données

kk


Dimensions du problème

1. Expression du consentement : distinction entre données régulières, secrètes, restreintes.

2. Conservation des données : distinction entre données régulières et données secrètes durables.

3. Continuité de la sécurité : aucune donnée en clair en dehors des SPT (hors affichage)

4. Accès déconnecté : cohérence à terme

Applicable à de nombreux contextes de partage de données personnelles












Plan de travail


Architecture fonctionnelle

Internet

Clé privée (kpriv)

Accès mobileBUSFLASH NAND

RAM

FLASH NOR

CPU Crypto

Synchro.

Accès déconnectéSynchronisation Synchronisation

Infr

astr

uct

ure

FLASH NOR

Do

nn

ées

D. régulières

D. secrètes durables kU

D. restreintes k

Certificats

Clés publiques (kpub)

Clés secrètes (k) kpub

Données hébergées sur le terminal de P kP

FLASH NAND

D. régulières

D. secrètes kU

D. secrètes durables kU

kU

D. restreintes kU

Deltas chiffrés kD

Browser WEB

Système d’exploitation

Serveur d’identités

SGBD commercial

Web

Ser

ve

r

Syn

ch

ron

isat

ion

Ser

vle

ts

Système d’exploitation

Lo

gic

iel

TerminalServeur SPT

Clés secrètes (kU), (k)

Clés pour deltas (kD )

Certificat utilisateur

Système d’exploitationMachine virtuelle

Java

Authentification

Contrôle d’accès

Evaluateur derequêtes

Modules crypto.

Indexation / Stockage

Web

Ser

ver

Syn

ch

ron

isat

ion

Ser

vle

ts

TCP/IPUSB

OS multi - thread


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



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



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












Plan de travail


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












Plan de travail


Bilan à T0+12

Due à T0+12 : plate-forme logicielle préliminaire1. Une base de données centralisée de dossiers médico-sociaux accessible via

une interface Web2. Un protocole de communication sécurisé et un protocole de signature standards3. Des outils d’import/export 4. 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


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


Questions ?

projet dmsp – 27 novembre 2007 1 dossier médico-social partagé, nomade et sécurisé revue du...

Documents