Le cadre d'interopérabilité du DMP. Juillet 2007

Transcription

1 Le cadre d'interopérabilité du DMP Juillet 2007

2 Historique du document Le cadre d'interopérabilité du DMP définit globalement les spécifications des échanges avec les sous-systèmes «portail» et «hébergeur» composant le système DMP. Le cadre d'interopérabilité du DMP : a été publié en version initiale le 4 avril 2007 pour une phase de concertation les commentaires et questions reçus ont été traités un document de réponse aux questions a été publié au sein de l'espace de concertation la nouvelle version du document prend en compte les remarques et les commentaires reçus 2

3 Plan du cadre d'interopérabilité Partie 1 : Présentation du cadre d'interopérabilité définitions dimensionnement et spécifications d'interopérabilité du DMP Partie 2 : Interopérabilité architecture et exigences les intangibles de l'architecture une architecture composée d'un portail et d'hébergeurs un jeton d'habilitation et des données échangées au format IHE des web services et des données IHE des exigences générales en cible Volet «PS en exercice individuel» Volet «PS en établissement de santé» Volet «Messagerie» (à l'étude) Volet «Réseaux de santé et plate-forme d'intermédiation» (à l'étude) Partie 3 : Interopérabilité modes opératoires les étapes de la DMP compatibilité organisation de l'espace de concertation processus d'homologation / d'agrément éléments de calendrier 3

4 Partie 1 : Présentation du cadre d'interopérabilité définitions dimensionnement et spécifications d'interopérabilité du DMP Partie 2 : Interopérabilité architecture et exigences les intangibles de l'architecture une architecture composée d'un portail et d'hébergeurs un jeton d'habilitation et des données échangées au format IHE des web services et des données IHE des exigences générales en cible Volet «PS en exercice individuel» Volet «PS en établissement de santé» Volet «Messagerie» (à l'étude) Volet «Réseaux de santé et plate-forme d'intermédiation» (à l'étude) Partie 3 : Interopérabilité modes opératoires les étapes de la DMP compatibilité organisation de l'espace de concertation processus d'homologation / d'agrément éléments de calendrier 4

5 L'interopérabilité : «Capacité de systèmes hétérogènes à échanger leurs données, de sorte que celles émises par l'un puissent être reconnues et interprétées par les autres, utilisées et traitées» Professionnels de santé / Etablissements de santé Acteurs institutionnels (CNAM-TS, CNAV, Caisse des dépôts, GIP-CPS, GIE SV, Etat, etc.) DMP Hébergeurs Patients, bénéficiaires de l'assurance maladie 5

6 L'interopérabilité : c'est satisfaire à des besoins de communication et d'échange, dans un cadre réglementaire précis, en réutilisant au maximum les standards et normes existants et reconnus => c'est un choix de normes et de standards, et de leurs évolutions, recouvrant tous les domaines de l'interopérabilité. Normes et standards sur les échanges électroniques Web services, SOAP, Presto, IHE-XDS, etc. Normes et standards sur l Internet HTML, HTTP, ISO, PDF, JPEG, etc. Normes et standards sur le contenu des données de santé IHE, HL7 CDA, CEN EHRcom DICOM, etc. données d'index Contenus et sémantique contenus structurés Cadre réglementaire 6

7 Les dimensions de l'interopérabilité du DMP L'interopérabilité : pour avec : des contenus des protocoles les échanges métiers (données médicales) les échages techniques (données support aux échanges) les LPS des PS les SI des ES les navigateurs des patients les téléservices et SI des opérateurs sectoriels (CNAM-TS, CNAV/RNIAM, CPS/RPPS, etc.) 7

8 L'interopérabilité dans le DMP : les acteurs systèmes Annuaires Données Téléservices et SI de l'am CNAV RNIAM Réseaux /DCC / Dxx Télé-services Historique de remboursements GIP-CPS RPPS DP FSE INTEROPERABILITE 1<>1 INTEROPERABILITE de 1<>n voire m<>n DMP Portail DMP Hébergeurs agréés Hébergeur de référence DMP Authentification Échange de données Navigateur LGC LPS SIH Poste de consultation Patient (BAM) PS PE 8

9 L'interopérabilité dans le DMP Les spécifications d'interopérabilité pour le DMP ce sont : des spécifications de contenu, de format, de syntaxe... des spécifications de modalités d'échanges, de protocoles mais aussi : une répartition des rôles entre les acteurs de l'interopérabilité (fourniture de souches, de composants,...) un environnement de test une procédure d'agrément / certification / validation (à déterminer) qui atteste de l'interopérabilité des SIS avec le DMP une convention entre acteurs (responsabilités juridiques, procédures, niveau de service) et surtout : un planning une coordination entre acteurs de l'etat 9

10 L'interopérabilité dans le DMP Le cadre d'interopérabilité décrit dans le présent document est complété par : des conventions entre les acteurs (responsabilités juridiques, procédures, niveau de service) des spécifications : pour l'interaction avec le service de confiance : un Dossier de spécifications techniques (publié au sein de l'espace de concertation le 4/04/07) pour les échanges de données de santé : une Description du domaine d'activité DMP (en cours de rédaction) l'extension française d'ihe-xds (publiée le 4/04/07) un «Cadre d'homologation / d'agrément des LPS» (rédaction en cours, livraison prévue fin 07/2007) 10

11 Les interactions élémentaires avec les PS (1)&(2) : interactions spécifiées (3) : en cours de spécifications (4)&(4bis) : réflexion en cours 11

12 Les interactions élémentaires avec les PS - légende Système ou sous-système (portail, hébergeur, frontal, DP,...) Données Périmètre Interaction d'authentification Interaction d'échange de données médicales Interaction hors périmètre DMP PS A PS B PS C PS D & PS E Pharmacien d'officine (alimentation indirecte du DMP) PS en mode d'exercice individuel PS en mode d'exercice collectif PS en remise de documents en mode messagerie 12

13 Partie 1 : Présentation du cadre d'interopérabilité définitions dimensionnement et spécifications d'interopérabilité du DMP Partie 2 : Interopérabilité architecture et exigences les intangibles de l'architecture une architecture composée d'un portail et d'hébergeurs un jeton d'habilitation et des données échangées au format IHE des web services et des données IHE des exigences générales en cible Volet «PS en exercice individuel» Volet «PS en établissement de santé» Volet «Messagerie» (à l'étude) Volet «Réseaux de santé et plate-forme d'intermédiation» (à l'étude) Partie 3 : Interopérabilité modes opératoires les étapes de la DMP compatibilité organisation de l'espace de concertation processus d'homologation / d'agrément éléments de calendrier 13

14 L'architecture du système DMP Le système DMP est composé : d'un portail pour l'authentification des acteurs le contrôle des habilitations d'hébergeurs de données de santé (hébergeur de référence ou hébergeurs agréés) pour la manipulation de «documents ou de données de santé» (consultation, dépôt) Les interactions entre les composants du système DMP et les SI de Soins mettent en jeu une pluralité d'acteurs (éditeurs de SI de soins en particulier) => nécessité d'un cadre d'interopérabilité 14

15 La cinématique d'échange avec le système DMP La cinématique d'échange avec le système DMP comprend : 1 authentification de l'acteur et demande d'accès à un DMP auprès du Portail 2 fourniture par le Portail d'un jeton SAML d'accès au DMP 3 émission des requêtes d'accès au DMP (en consultation ou en alimentation) vers l'hébergeur concerné avec présentation du jeton SAML émis par le Portail 15

16 Interaction avec le portail accès patient DMP Portail DMP Hébergeur de référence DMP Téléservices AM Portail IMARS Navigateur redirect Poste de consultation Patient (BAM) SSL / TLS WebService Poste de travail PS CPS Deux modes distincts d'authentification en fonction de l'acteur (lié aux modalités d'accès via navigateur ou LPS) 16

17 Interaction avec le portail accès du PS DMP Portail DMP Hébergeur de référence DMP Téléservices AM Portail IMARS (1) requête (consultation, dépôt) (2) assertion SAML (3) requête Hébergeur & assertion SAML (4) échange de données de santé Navigateur Poste de consultation Patient (BAM) (1) (2) (3) WebService Poste de travail PS CPS Deux modes distincts d'authentification en fonction de l'acteur (lié aux modalités d'accès via navigateur ou LPS) (4) SSL / TLS Une double logique : authentification des acteurs (PS) (SAML V2.0) authentification mutuelle des systèmes (SIS ou PdT) 17

18 Interaction «échange de données de santé» (1/2) Les échanges de données de santé sont réalisés au format IHE-XDS en respectant strictement le modèle suivant : les requêtes "Registry Stored Query" utiliseront des transactions en mode "SOAP V1.1" les requêtes "Retrieve Document" utiliseront des transactions en mode "https get" les requêtes "Provide and Register Document Set" utiliseront des transactions en mode "SOAP with attachment sur SSL/TLS" En version 2 du DMP, les échanges de données de santé seront réalisés au format IHE-XDS dans sa version web services 18

19 Interaction «échange de données de santé» (2/2) Participation aux travaux du consortium IHE : Spécifications de la mise en oeuvre d'ihe-xds participation à la rédaction de l'extension française d'ihe-xds (encoding à utiliser, codification des méta-données porteuses d'identifiant) participation à la rédaction des spécification du domaine d'activité DMP (nomenclatures à utiliser, formats de documents utilisables dans le cadre du DMP, fonctions spécifiques telles que suppression et masquage) Evolution d'ihe-xds participation aux travaux sur l'utilisation de web-services (convergence avec PRESTO V2.0) Connectathon participation au connectathon 2007 en tant que monitor Travaux futurs envisagés participation aux spécifications de la mise en oeuvre d'ihe-atna participation aux spécifications de la mise en oeuvre d'ihe-xua Parallèlement, des travaux sont menés pour la prise en compte de données structurées. 19

20 Les exigence générales de la DMP compatibilité (en cible et transitoire) Les exigences générales de la DMP compatibilité : Le PS doit être identifié et authentifié (ses droits et habilitations doivent être contrôlés par le portail et donc les éléments correspondants transmis à celui-ci) : le PS est identifié par son identifiant ADELI (et ultérieurement RPPS), les modalités transitoires de l'identification des PS en environnement hospitalier sont décrites dans le Volet SIH du présent cadre d'intéropérabilité. les élements d'identification et d'authentification fournis par le PS proviennent essentiellement de données confinées dans sa carte CPS personnelle. L'authentification du PS peut être synchrone (même unité de temps) avec la requête portant sur les données médicales ou asynchrone. Dans ce dernier cas les éléments d'identification, d'authentification et la demande d'accès au DMP elle-même doivent être signés par la CPS du PS (mode messagerie par exemple). Les éléments d'identification / authentification du PS sont disjoints de la signature du document déposé (le PS alimentant le DMP n'est pas forcément l'auteur du document transmis). L'accord du patient en matière d'accès à son DMP est recueilli (en cible) via sa carte Vitale (consentement initial, refus d'accès à un PS,...). Des exceptions identifiées à cette règle existent à ce jour (urgences, centre 15, tous les cas où le PS peut ne pas voir le patient, oubli de carte Vitale et donc obligation d'un mode d'allégation par le PS). En mode transitoire ce consentement est déclaré (allégué) par le PS dûment authentifié (CPS) 20

21 Les exigence générales de la DMP compatibilité (en cible et transitoire) Les exigences générales de la DMP compatibilité (suite) : Les documents déposés par le PS, que ce soit en mode synchrone ou asynchrone, doivent être signés par la CPS de leur auteur (en cible). De manière transitoire un cachet est apposé par l'hébergeur. Cette solution assure l'intégrité du document mais non l'imputabilité des actions réalisées. Il est à noter que le PS alimentant le DMP n'est pas forcément l'auteur du document déposé. Les LPS doivent respecter les exigences d'authentification mutuelle [LPS / Portail / Hébergeur] (décrites dans les spécifications du service de confiance) afin d'éviter les usurpations d'identité et de rôle. Tous les échanges de données doivent être protégés en confidentialité. Les données de santé échangées doivent être conformes aux spécifications IHE (formats et méta-données) et aux profils mis en oeuvre conformément aux spécifications publiées par le GIP-DMP. Les échanges de données d'identification, d'authentification et d'habilitation doivent être effectués en mode Web_services conformément aux spécifications publiées par le GIP- DMP. Le LPS doit disposer d'un numéro d'homologation / agrément valide (contrôlable par le portail). 21

22 Limites de la DMP compatibilité La DMP compatibilité est évaluée à l'interface avec le DMP. Les systèmes soumis aux exigences de la DMP compatibilité sont donc : les LGC Les frontaux ou connecteurs de SIH, de réseau ou de messagerie La DMP compatibilité ne préjuge en rien de la conformité de ces systèmes aux textes applicables : le decret hébergeur pour les systèmes stockant des données personnelles le décret confidentialité le décret identifiant... 22

23 Partie 1 : Présentation du cadre d'interopérabilité définitions dimensionnement et spécifications d'interopérabilité du DMP Partie 2 : Interopérabilité architecture et exigences les intangibles de l'architecture une architecture composée d'un portail et d'hébergeurs un jeton d'habilitation et des données échangées au format IHE des web services et des données IHE des exigences générales en cible Volet «PS en exercice individuel» Volet «PS en établissement de santé» Volet «Messagerie» (à l'étude) Volet «Réseaux de santé et plate-forme d'intermédiation» (à l'étude) Partie 3 : Interopérabilité modes opératoires les étapes de la DMP compatibilité organisation de l'espace de concertation processus d'homologation / d'agrément éléments de calendrier 23

24 Le cadre d'interopérabilité du DMP Volet «PS en exercice individuel»

25 Synthèse des exigences de la DMP compatibilité en cible et de manière transitoire transitoire 25

26 Partie 1 : Présentation du cadre d'interopérabilité définitions dimensionnement et spécifications d'interopérabilité du DMP Partie 2 : Interopérabilité architecture et exigences les intangibles de l'architecture une architecture composée d'un portail et d'hébergeurs un jeton d'habilitation et des données échangées au format IHE des web services et des données IHE des exigences générales en cible Volet «PS en exercice individuel» Volet «PS en établissement de santé» Volet «Messagerie» (à l'étude) Volet «Réseaux de santé et plate-forme d'intermédiation» (à l'étude) Partie 3 : Interopérabilité modes opératoires les étapes de la DMP compatibilité organisation de l'espace de concertation processus d'homologation / d'agrément éléments de calendrier 26

27 Le cadre d'interopérabilité du DMP Volet «PS en établissement de santé»

28 DMP compatibilité exigences dans le contexte SIH La DMP - Compatibilité des SIH diffère principalement de la DMP Compatibilité des LGC pour les aspects suivants : La nature architecturale des SI hospitalier En environnement collectif, les postes "clients" du système DMP (accès en consultation / dépot) sont intégrés au sein d'un SI hospitalier (versus poste de travail "isolé" pour les LGC) Ce "positionnement" architectural, en fonction de ses caractéristiques propres, a un impact sur les interactions en mode "web services / Soap" avec les composants portail et hébergeur du DMP L'impossibilité d'adopter le mode d'identification et d'authentification nominal des PS : absence de généralisation de la carte CPS en exercice collectif (impact sur l'identification et l'authentification) absence de généralisation de l'identifiant national des PS : ADELI ou RPPS (impact sur l'identification) 28

29 Synthèse des exigences pour les SIH Synthèse des exigences de la DMP compatibilité : en cible et de manière transitoire points de difficulté pour les SIH 29

30 Architecture des SIH La nature architecturale des SI Hospitalier a un impact fort sur les modèles architecturaux de l'interconnection des "systèmes clients" avec le DMP. Cette nature architecturale des SI hospitalier doit donc faire l'objet d'une étude typologique détaillée (participation : GIP-DMP, DHOS,...) Cette étude devra tenir compte : des critères de taille d'établissement, du caractère public ou privé, d'éventuelles spécialités,... En première approche, les modèles limites suivants peuvent être identifiés : des SI très intégrés à base d'un PGI santé (ou d'un PGI par domaine : administratif, secteurs santé différents,...) des SI faiblement intégrés fondés sur une juxtaposition d'applications spécialisées ou sectorielles 30

31 Modèles possibles pour l'échange des SIH avec le DMP En environnement collectif, trois modèles peuvent être proposés pour l'interconnexion des «systèmes clients» avec le DMP Modèle 1 : dit «nominal» (rapprochement avec l'exercice individuel) Modèle 2 : «accès indifférencié» consultation / dépôt Modèle 3 : «accès différencié» consultation / dépôt 31

32 Modèle 1 : accès dit «nominal» du SIH au DMP Le SI Hospitalier déploie des postes dédiés pour l'accès au DMP Ciblage fonctionnel (urgences, services d'admission,...) Capacité du poste à utiliser la CPS pour authentification et éventuellement signature Conformité aux exigences nominales (web-services, IHE) Portail DMP Hébergeur Système DMP DMP Accès au DMP équivalent à l'accès d'un PS en exercice individuel Poste de travail PS SIH Poste de travail PS Services Poste de travail PS Poste de travail PS Poste de travail PS Poste de travail PS Poste de travail PS Hôpital 32

33 Modèle 1 : accès dit «nominal» du SIH au DMP Les concepts structurants : Portail DMP Hébergeur DMP Accès identique à celui d'un LGC fonctionnement indifférencié en consultation et en dépôt de données authentification mutuelle des systèmes (Hébergeur et poste de travail PS) Ce mécanisme complémentaire à l'authentification des acteurs permet d'éviter l'usurpation d'identité et de rôle (2) (3) (4) (1) SSL / TLS WebService Poste de travail PS (1) requête (consultation, dépôt) (2) assertion SAML (3) requête Hébergeur & assertion SAML (4) échange de données de santé CPS 33

34 Modèle 2 : accès dit «indifférencié» Le SI Hospitalier développe sa capacité à échanger avec le DMP adaptation du SIH la CPS n'est pas supportée répartition ou non de la connexion au DMP Portail DMP Hébergeur Système DMP DMP La responsabilité de l'identification, l'authentification et la traçabilité est reportée au niveau du SIH Poste de travail PS Frontal SIH SIH Poste de travail PS Services Poste de travail PS Poste de travail PS Poste de travail PS Poste de travail PS Hôpital 34

35 Modèle 2 : accès dit «indifférencié» Les concepts structurants : fonctionnement indifférencié en consultation et en dépôt de données authentification du connecteur SIH (au DMP) par son certificat serveur transfert de l'identité du PS, dans le SIH, au portail transfert de responsabilité de l'authentification du PS (et de la traçabilité associée) au responsable du SI hospitalier Portail DMP (1 bis) Web Services (2) (3) Connecteur SIH (1) Hébergeur (4) (4 bis) Certificat serveur DMP Poste de travail PS (1) requête (consultation, dépôt) (1bis) transmission requête au Portail (2) assertion SAML (3) requête Hébergeur & assertion SAML (4) réponse Hébergeur (4bis) transmission réponse Hébergeur 35

36 Modèle 2 : accès dit «indifférencié» Modalités d'identification et d'authentification : Identification de l'établissement ou d'un sous-ensemble de l'établissement (Identifiants FINESS ou SIREN / SIRET de l'insee) Authentification du SI collectif via son certificat d'établissement CDE (ou certificat serveur d'origine GIP-CPS obtenu via le CDE) Transfert de la responsabilité de l'identification et l'authentification du PS au SI collectif : Identification du PS dans le SI (si le certificat et l'identifiant FINESS ou SIREN / SIRET ne sont pas suffisants pour identifier de manière certaine un SI, l'identifiant du PS devra fournir / porter l'identifiant du SI) Il est de la responsabilité du responsable d'établissement de veiller à ce que l'identifiant fourni (certificat, identifiant FINESS, identifiant de PS) garantisse une identification non ambiguë du PS Engagement formel, par le responsable d'établissement, sur la sécurité de la délégation d'authentification des PS et la délégation de traçabilité La forme juridique (et l'acceptation par les responsables d'établissement) de ce transfert de responsabilité reste à définir 36

37 Modèle 3 : accès dit «différencié (consultation/dépôt) Le SI Hospitalier déploie des postes dédiés pour l'accès en consultation au DMP Ciblage fonctionnel (urgences, services d'admission,...) Capacité du poste à utiliser la CPS Le SI Hospitalier concentre l alimentation du DMP sur des systèmes ciblés Il n y a pas de hiérarchisation objective du risque entre les actions de consultation et de dépôt. Toutefois les risques peuvent être ressentis comme différents par des responsables d établissement Portail DMP consultation Poste de travail PS Frontal SIH Hébergeur SIH Poste de travail PS Système DMP DMP dépot Services Poste de travail PS Poste de travail PS Poste de travail PS Poste de travail PS Poste de travail PS Hôpital 37

38 Modèle 3 : accès dit «différencié (consultation/dépôt) Consultation de documents Dépôt de documents Portail DMP Hébergeur DMP Portail DMP Hébergeur DMP SIH (1) requête (consultation, dépôt) (2) assertion SAML (1) (3) requête Hébergeur & assertion SAML (4) échange de données de santé (2) (3) Poste de travail (4) Pré-suppose l'existence sur le marché d'un poste dédié à la consultation (LGC ou LPS réduit à sa fonction de consultation). Attention, il ne s'agit pas d'un accès en mode navigateur. (1 bis) Web Services (2) (3) Connecteur SIH (1) Poste de travail PS (4) (4 bis) Certificat serveur (1) requête (consultation, dépôt) (1bis) transmission requête au Portail (2) assertion SAML (3) requête Hébergeur & assertion SAML (4) réponse Hébergeur (4bis) transmission réponse Hébergeur 38

39 Les modes d'accès SIH Les modes d'accès transitoires des PS au DMP présentés ci-dessus : ne sont pas exclusifs ; ils peuvent être mixés, y compris à l'intérieur d'un même établissement, sont dépendants des plannings d'adoption des solutions CPS par les établissements, doivent être mis en perspective de futurs avis CNIL, ne tiennent pas compte de solutions techniques novatrices qui pourraient apparaitre voire donner lieu à des généralisations locales : dispositifs d'authentification CPS peu intrusifs pour les SI hosptitalier (calculette réalisant une authentification CPS sur un serveur externe), dispositifs d'émulation du mode sans contact pour les CPS existantes, dispositifs d'authentification forte des PS en dehors des solutions CPS (y compris cartes avec ou sans contacts peuplées de certificats qualifiés)... 39

40 Partie 1 : Présentation du cadre d'interopérabilité définitions dimensionnement et spécifications d'interopérabilité du DMP Partie 2 : Interopérabilité architecture et exigences les intangibles de l'architecture une architecture composée d'un portail et d'hébergeurs un jeton d'habilitation et des données échangées au format IHE des web services et des données IHE des exigences générales en cible Volet «PS en exercice individuel» Volet «PS en établissement de santé» Volet «Messagerie» (à l'étude) Volet «Réseaux de santé et plate-forme d'intermédiation» (à l'étude) Partie 3 : Interopérabilité modes opératoires les étapes de la DMP compatibilité organisation de l'espace de concertation processus d'homologation / d'agrément éléments de calendrier 40

41 Le cadre d'interopérabilité du DMP Volet «Messagerie»

42 DMP compatibilité exigences dans le contexte messagerie La DMP Compatibilité des plateformes de messagerie diffère principalement de la DMP Compatibilité des LGC pour l'aspect suivant : L'authentification des PS est asynchrone Les spécificités de la DMP compatibilité en mode messagerie sont donc les suivantes (en cible) : Les éléments d'identification (vecteur d'identification), d'authentification et la demande d'accès au DMP (et ses modalités) doivent être signés par la CPS du PS Dans le cas mode d'accès pour dépôt de document, le document doit bien sûr être signé par son auteur (pas de phase transitoire) et le document n'est pas confondu avec la demande de dépôt décrite ci-dessus. Il s'agit de deux pièces distinctes, chacune devant être signée électroniquement par son auteur. La demande de dépôt et la pièce à déposer peuvent avoir deux auteurs (et donc deux signataires) différents 42

43 DMP compatibilité exigences dans le contexte messagerie De manière transitoire, il peut être envisagé, dans certain cas, des modalités spécifiques pour la DMP compatibilité en mode messagerie quand celle-ci se limite au dépôt de document : Les éléments d'identification (vecteur d'identification), d'authentification et la demande d'accès au DMP (et ses modalités) sont transmis (au portail) non signés par la CPS du PS. A ces éléments est jointe la signature du document à déposer (et en aucun cas le document lui-même). Le portail vérifie, en sus de l'habilitation du PS réalisant la demande d'accès, la cohérence de son identité avec l'identité utilisée pour la signature (certificat de signature) ce qui interdit à un PS de déposer des documents dont il ne serait pas l'auteur. Toutes les modalités d'accès autres que le dépôt de document sont refusées. L'authentification et l'habilitation au portail peuvent se faire sur les bases ci-dessus du fait de la confiance dans la politique de sécurité du service de messagerie (modalités d'audit de la politique de sécurité à définir!). (pour mémoire il n'y a pas de spécificité dans l'interaction avec l'hébergeur le contrôle de la validité de signature de la pièce déposée est réalisée comme pour les autres types d'accès) Cette solution est en cours d'étude. Les éléments de réflexion sont les suivants : Le service de messagerie de confiance doit en particulier garantir, à travers sa politique de sécurité, que cette signature ne peut être interceptée (et donc rejouée) entre sa création et son transfert au connecteur de messagerie => les modalités d'audit du service sont en cours d'étude 43

44 Alimentation du DMP en mode messagerie Les concepts structurants : Mode de fonctionnement asynchrone : pas de garantie de temps d'alimentation et donc de disponibilité de l'information pour les autres PS!! Les échanges entre concentrateur et systèmes du DMP (portail, hébergeurs) se font en mode web-services le système concentrateur peut être ou non un composant du système DMP (voir planche suivante) DMP Portail DMP (2 demande de dépôt) (3) Hébergeur (4 document XDS) Concentrateur de messagerie (1) Internet (6) DMP (5) Poste de travail PS (1) : message contenant une demande de dépôt et document XDS tous deux séparément signés par une CPS (hors modalité transitoire) (2) : requête d'identification et d'habilitation au Portail (3) : assertion SAML (4) : assertion SAML & document en pièce jointe contrôle de la signature (5) : accusé de réception signé (6) : retour/acquittement 44

45 Alimentation du DMP en mode messagerie plusieurs cas à distinguer La mise en oeuvre d'un concentrateur dans le périmètre DMP Portail DMP Web Services Poste de travail PS B (2) DMP (3) Hébergeur (1) (4) Concentrateur de messagerie Internet messagerie (6) DMP Poste de travail PS A Le concentrateur mis en oeuvre au sein du périmètre DMP peut être mutualisé ou non Le développement d'un connecteur DMP au sein des Réseaux Portail DMP Connecteur messagerie Réseau Poste de travail PS A DMP (5) Web Services messagerie Hébergeur Poste de travail PS B DMP Certificat serveur (CPS) 45

46 Alimentation du DMP en mode messagerie Les questions encore en suspens : Les modalités / garanties de retour d'information au PS concernant le déroulement du dépôt de document (acquittement, motif de rejet,...) restent à spécifier (en fonction des modes d'architecture?) Le contrôle, au plus près du PS, du formalisme des données IHE peut-il être intégré dans les applications de messagerie? Modalités de contrôle de la signature (pour l'authentification par le portail ou pour le contrôle de la pièce par l'hébergeur)? Comment identifier / authentifier le connecteur émetteur s'il n'a pas de certificat CPS? Analyse comparative : 46

47 L'agrément des plateformes de messagerie L'homologation / l'agrément des plateformes de messagerie sera : evalué à l'interface avec le connecteur (de messagerie) délivré sur la base de référentiels prenant en compte : une politique de sécurité et l'engagement de son respect la conformité au référentiel technique (cadre d'interopérabilité) 47

48 Partie 1 : Présentation du cadre d'interopérabilité définitions dimensionnement et spécifications d'interopérabilité du DMP Partie 2 : Interopérabilité architecture et exigences les intangibles de l'architecture une architecture composée d'un portail et d'hébergeurs un jeton d'habilitation et des données échangées au format IHE des web services et des données IHE des exigences générales en cible Volet «PS en exercice individuel» Volet «PS en établissement de santé» Volet «Messagerie» (à l'étude) Volet «Réseaux de santé et plate-forme d'intermédiation» (à l'étude) Partie 3 : Interopérabilité modes opératoires les étapes de la DMP compatibilité organisation de l'espace de concertation processus d'homologation / d'agrément éléments de calendrier 48

49 Le cadre d'interopérabilité du DMP Volet «Réseau de santé et plate-forme d'intermédiation»

50 DMP compatibilité : cas des réseaux de santé La DMP Compatibilité des réseaux de santé et des plate-formes d'intermédiation reste à étudier. 50

51 Partie 1 : Présentation du cadre d'interopérabilité définitions dimensionnement et spécifications d'interopérabilité du DMP Partie 2 : Interopérabilité architecture et exigences les intangibles de l'architecture une architecture composée d'un portail et d'hébergeurs un jeton d'habilitation et des données échangées au format IHE des web services et des données IHE des exigences générales en cible Volet «PS en exercice individuel» Volet «PS en établissement de santé» Volet «Messagerie» (à l'étude) Volet «Réseaux de santé et plate-forme d'intermédiation» (à l'étude) Partie 3 : Interopérabilité modes opératoires les étapes de la DMP compatibilité organisation de l'espace de concertation processus d'homologation / d'agrément éléments de calendrier 51

52 Rappel - L'interopérabilité dans le DMP Les spécifications d'interopérabilité pour le DMP ce sont : des spécifications de contenu, de format, de syntaxe... des spécifications de modalités d'échanges, de protocoles mais aussi : une répartition des rôles entre les acteurs de l'interopérabilité (fourniture de souches, de composants,...) un environnement de test une procédure d'agrément / certification / validation (à déterminer) qui atteste de l'interopérabilité des SIS avec le DMP une convention entre acteurs (responsabilités juridiques, procédures, niveau de service) et surtout : un planning une coordination entre acteurs de l'etat 52

53 Les étapes de la DMP compatibilité (1/2) Pour chaque interaction avec un composant du sytème DMP, le cadre d'interopérabilité définit : des spécifications générales formats et syntaxes : liste des standards supportés (voir annexe) échanges des données : protocoles et profils de transport utilisés autres des spécifications détaillées modalités d'implémentation des standards & paramétrage des composants logiciels disponibilité ou mise à disposition prévue de composants logiciels (libres ou commerciaux) 53

54 Les étapes de la DMP compatibilité (2/2) Pour chaque interaction avec un composant du sytème DMP, le cadre d'interopérabilité définit (suite) : un environnement de test et support fourniture des spécifications de test par le GIP-DMP fourniture du processus et mise à disposition des environnements et des outils permettant à l éditeur de tester l'intéropérabilité de ses produits avec le DMP résultat global sous forme d un rapport de test validé par une structure tierce (CNDA, IRISA, ) un environnement d'intégration mise à disposition des environnements et des outils pour la réalisation des tests opérationnels d interopérabilité avec le DMP résultat global sous forme d un rapport de test validé par le responsable du soussystème (Hébergeur de référence, Caisse des Dépôts) une homologation / un agrément la trajectoire qui pourra mener d'une homologation (sur la base de résultats de tests) à une procédure d'agrément (démarche cible) est à l'étude 54

55 Partie 1 : Présentation du cadre d'interopérabilité définitions dimensionnement et spécifications d'interopérabilité du DMP Partie 2 : Interopérabilité architecture et exigences les intangibles de l'architecture une architecture composée d'un portail et d'hébergeurs un jeton d'habilitation et des données échangées au format IHE des web services et des données IHE des exigences générales en cible Volet «PS en exercice individuel» Volet «PS en établissement de santé» Volet «Messagerie» (à l'étude) Volet «Réseaux de santé et plate-forme d'intermédiation» (à l'étude) Partie 3 : Interopérabilité modes opératoires les étapes de la DMP compatibilité organisation de l'espace de concertation processus d'homologation / d'agrément éléments de calendrier 55

56 Organisation de l'espace de concertation (1/2) Création d'un espace de concertation sur le site web institutionnel du GIP DMP «Espace de concertation» Avec pour objectifs : la mise à disposition de ressources documentaires l'appel à commentaires (pour tout document publié, la période de concertation est fixée à 1 mois) Accessible : depuis la page d'accueil du site directement, à l'adresse option=com_content&task=view&id=41&itemid=46 56

57 Organisation de l'espace de concertation (2/2) Mode opératoire pour l'envoi de commentaires : Pour toute publication, les commentaires doivent être adressés pendant la période de concertation à l'adresse concertation@d-m-p.org L'objet du message doit préciser le nom du document commenté Exemple : Appel à commentaire Cadre d'interopérabilité pour les échanges avec le DMP Un document «Questions et réponses» sera publié pour chaque publication après traitement des premiers commentaires 57

58 Partie 1 : Présentation du cadre d'interopérabilité définitions dimensionnement et spécifications d'interopérabilité du DMP Partie 2 : Interopérabilité architecture et exigences les intangibles de l'architecture une architecture composée d'un portail et d'hébergeurs un jeton d'habilitation et des données échangées au format IHE des web services et des données IHE des exigences générales en cible Volet «PS en exercice individuel» Volet «PS en établissement de santé» Volet «Messagerie» (à l'étude) Volet «Réseaux de santé et plate-forme d'intermédiation» (à l'étude) Partie 3 : Interopérabilité modes opératoires les étapes de la DMP compatibilité organisation de l'espace de concertation processus d'homologation / d'agrément éléments de calendrier 58

59 Cadre législatif et réglementaire Rappel des textes applicables : Le décret Hébergeur du 4 janvier 2006 agrément pour l'hébergement de données de santé : «Toute personne physique ou morale souhaitant assurer l'hébergement de données de santé à caractère personnel mentionné à l'article L du CSP et bénéficier de l'agrément doit remplir les conditions suivantes : [...] définir et mettre en oeuvre une politique de confidentialité et de sécurité destinée notamment à assurer le respect des exigences de confidentialité et de secret prévues par les articles L et L , la protection contre les accès non autorisés ainsi que la pérennité des données et dont la prescription doit être jointe au dossier d'agrément dans les conditions fixées par l'article R » L'article 25 de la loi du 30 janvier 2007 : «la détention et le traitement sur des supports informatiques de données de santé à caractère personnel sont subordonnés à l'utilisation de systèmes d'information conformes aux prescriptions adoptées en application de l'article L et répondant à des conditions d'interopérabilité arrêtées par le ministre en charge de la santé» Le décrêt confidentialité du 15 mai 2007 : «Article R la conservation sur support informatique des informations médicales mentionnées aux trois premiers alinéas de l'article L par tout professionnel, tout établissement et tout réseau de santé ou tout autre organisme intervenant dans le système de santé est soumis au respect de référentiels définis par arrêté du ministre chargé de la santé pris après avis de la CNIL. Ces référentiels s'imposent également à la transmission des informations par voie électronique entre professionnels. Les référentiels déterminent les fonctions de sécurité nécessaires à la conservation ou à la transmission de ces informations médicales en cause et fixant le niveau de sécurité requis pour ces fonctions» 59

60 Procédures applicables en fonction du cadre légal Les procédures applicables en fonction des différents textes sont : Rappel des textes applicables en fonction de la nature du système : La procédure d'évaluation de la conformité au référentiel «Interopérabilité» couvre : la DMP compatibilité (=> homologation / agrément des logiciels) la conformité à des référentiels restant à établir 60

61 Vérification de la DMP compatibilité - stratégie La DMP compatibilité s évalue à l interface avec le DMP, elle ne prend pas en compte la globalité du LPS ou du SIH. L'homologation par le GIP-DMP (basée sur la validation de différentes phases de tests) des systèmes interagissant avec le DMP (LGC, SIH, connecteurs,...) permet de valider leur DMP compatibilité. Les fondamentaux de l'homologation des LPS : un kit de développement / test mis à disposition des éditeurs (téléchargeable par les éditeurs) un service en ligne «répondeur» (test en ligne) associé à un support technique aux développements par le CNDA une phase de tests encadrés au CNDA 61

62 Démarche d'homologation des LPS Le processus d'homologation consiste en la coordination et la validation des différents tests définis (travaux en cours). Pilotage de la DMP compatibilité Tests internes de l'éditeur Service en ligne «répondeur» Support aux développements Tests encadrés au CNDA 62

63 Partie 1 : Présentation du cadre d'interopérabilité définitions dimensionnement et spécifications d'interopérabilité du DMP Partie 2 : Interopérabilité architecture et exigences les intangibles de l'architecture une architecture composée d'un portail et d'hébergeurs un jeton d'habilitation et des données échangées au format IHE des web services et des données IHE des exigences générales en cible Volet «PS en exercice individuel» Volet «PS en établissement de santé» Volet «Messagerie» (à l'étude) Volet «Réseaux de santé et plate-forme d'intermédiation» (à l'étude) Partie 3 : Interopérabilité modes opératoires les étapes de la DMP compatibilité organisation de l'espace de concertation processus d'homologation / d'agrément éléments de calendrier 63

64 Eléments de calendrier interaction avec le portail Spécifications générales : mars 2007 par le GIP-DMP ( avec la Caisse des Dépôts) Format et syntaxe : SAML V2 (format d'assertion) Echanges des données : Web Services (WS-adressing, WS-security, ) Spécifications détaillées V1 : avril 2007 par le GIP-DMP ( avec la Caisse des Dépôts) Composants logiciels : du code exemple de l implémentation des Web Services sera mis à disposition par le GIP-DMP : en environnement Java août 2007 en environnement.net octobre 2007 Environnement de test et support : fin 2007 via le CNDA (à confirmer) Environnement d intégration : début 2008 via le CNDA fourniture des environnements (logiciels) par la Caisse des Dépôts (à confirmer) Homologation / Agrément : sur la base des résultats des tests réalisés au CNDA (travaux en cours) 64

65 Eléments de calendrier interaction avec l'hébergeur Spécifications générales : Cadre d'interopérabilité entre le DMP et les LPS fin mars 2007 par le GIP-DMP Spécifications détaillées V1 : la Description du domaine d'activité DMP par le GIP-DMP & l'extension française d'ihe-xds Format et syntaxe des données V1 et V2 : format IHE Echanges des données (au format IHE) : V1-DMP : IHE-XDS en appliquant strictement le modèle suivant : Les requêtes "Registry Stored Query" utiliseront des transactions en mode "SOAP V1.1". Les requêtes " Retrieve Document " utiliseront des transactions en mode "https get" Les requêtes " Provide and Register Document Set " utiliseront des transactions en mode "SOAP with attachment sur SSL/TLS" V2-DMP : IHE-XDS dans sa version web services (compatibilité PRESTO V2.0) 65

66 Eléments de calendrier interaction avec l'hébergeur Composants V1 : des composants logiciels sont disponibles auprès d éditeurs voir groupement IHE Environnement de test V1 et support : début 2008 via le CNDA Connectathon international géré par le consortium IHE Plate-forme permanente de test IHE fournie par l IRISA (à valider) début 2008 environnement de test fourni par le titulaire du marché hébergeur de référence (à confirmer) Environnement d intégration : début 2008 via le CNDA fourniture des environnements (logiciels) par l'hébergeur de référence (à confirmer) Homologation / Agrément : sur la base des résultats des tests réalisés au CNDA (travaux en cours) 66

67 Eléments de calendrier interaction avec l'hébergeur Ecart de spécifications générales V2 : uniquement profil de transport PRESTO V2 mi 2008 par le titulaire du marché hébergeur de référence Composants V2 : des composants logiciels PRESTO sont disponibles en environnement.net, C et java voir groupement Minefi/DGME/SDAE Environnement de test V2 et support : Connectathon international géré par le consortium IHE début 2009 Plate-forme permanente de test IHE fournie par l IRISA (à valider) + début 2009 environnement de test pour la composante transport PRESTO V2.0 fourni par la DGME + début 2009 environnement de test fourni par le titulaire du marché hébergeur de référence Environnement d intégration : mi 2009 par le titulaire du marché hébergeur de référence mais aussi par la DGME pour la composante transport PRESTO Agrément V2 : sur la base des résultats des différents tests et des tests opérationnels d intégration 67

68 Eléments de calendrier synthèse 68