ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

Save this PDF as:
 WORD  PNG  TXT  JPG

Dimension: px
Commencer à balayer dès la page:

Download "ASIP Santé DSFT des interfaces DMP des LPS V 1.0.3 24/06/2014 1 / 250"

Transcription

1 ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

2 Référence du document : Classification : DSFT des interfaces DMP des LPS_v1.0.3.docx Non sensible public Historique du document Version Date Commentaires V /09/2010 Version initiale. Compléments sur : V /11/2010 V /11/2010 V /02/2014 V /06/2014 Durée des sessions TLS ; Certificats serveurs utilisés par le système d information DMP ; Gestion des accès par CPE ; Accès Web-PS contextuels (TD0.9) ; Mise à jour des codes d erreurs. Mise à jour des références au cadre d interopérabilité des systèmes d information de santé partagés (CI-SIS) en version Ajout d une annexe technique pour faciliter la mise en œuvre du profil IHE DSG. Version mineure (sans impact pour les LPS déjà homologués) Nouvelle mise en forme du DSFT pour en faciliter la lecture et faire ressortir les exigences d homologation et les recommandations. Renommage de la TD 4.5 en TD 0.5 et intégration de cette TD 0.5 dans l Accès sécurisé au DMP. Intégration d une partie de la FAQ dans le DSFT et quelques corrections mineures. Version mineure (sans impact pour les LPS déjà homologués) Correction d erreur rédactionnelles et de renvois ou liens non opérationnels. Ajout d information sur les «CDA autoprésentables». Ajout de la référence au guide de bonnes pratiques d utilisation des CRL. Ajout d une recommandation (REC_1.X-1230) pour intégrer une valeur de la nomenclature des qualités des représentants légaux en provenance du DMP qui n est pas encore connue du LPS. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

3 Sommaire Sommaire Sommaire 1 Introduction Objet du document Guide de lecture Gestion des versions Contexte Le DMP Les LPS Les différents types de LPS Le LPS au cœur des Systèmes d Information de Santé Les fonctions DMP du LPS L accès sécurisé au DMP La création et la gestion administrative du DMP L alimentation du DMP La consultation du DMP Processus d homologation à la DMP Compatibilité Présentation du processus d homologation Constitution du dossier de candidature Développements et tests préparatoires à l homologation Homologation En savoir plus sur la DMP Compatibilité Les environnements techniques Les environnements d homologation Les environnements de formation et de production Transactions et profils DMP pour les LPS Description des transactions DMP Mode d authentification Authentification indirecte Authentification directe Utilisateurs et droits associés Professionnels de santé Les acteurs non PS Choix de profils à implémenter dans un LPS Principes généraux L implémentation des profils DMP dans les LPS Homologation des profils implémentés Exigences préalables à la DMP Compatibilité Standards, normes, référentiels Le cadre d interopérabilité des SIS Le profil IHE XDS.b Identification du patient par son INS Identification des professionnels de santé Identification des structures de santé Autres normes et standards Paramétrage du LPS OID racine unique par instance du LPS Gestion des évolutions des Web Services Nomenclatures et référentiels Cadre d exercice, Secteur d activité, Profession / Spécialité Configuration poste de travail / serveur ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

4 Sommaire Connexion internet Accès Web-PS Lecteur de cartes (matériel) Dispositifs de lecture des cartes Vitale (logiciel) Dispositifs pour l authentification des utilisateurs Synchronisation du temps Impression Exemples d intégration du DMP dans les LPS Exemple DMP minimal : intégration de l AW-PS contextuel Exemple d un LPS en authentification directe (cas typique du LGC) Exemple avec calcul de l INS dans le LPS Exemple sans calcul de l INS dans le LPS Exemple d un LPS en authentification indirecte (cas typique du SIH) Exemple de type SIH «intégré» Exemple de type SIH «réparti» IHE PAM-fr et DMP Cas des «Connecteurs / EAI» Cas des logiciels en mode SaaS Exemple de l AW-PS non intégré au LPS Accès sécurisé au DMP Exigences générales de sécurité Connexion au DMP Vérification du certificat serveur du SI DMP Vérification du numéro d homologation du LPS TD0.1 - Authentification sur le DMP Authentification directe par CPS, CPE, CPF Authentification indirecte Le VIHF Règles de gestion des droits dans le DMP Autorisations et droits d accès à un DMP Droits fonctionnels par mode d authentification et par profil utilisateur Matrice d habilitation TD0.2 - Test d existence d un DMP et vérification de l autorisation Prérequis Cinématique Transaction TD0.3 - Mise à jour de l autorisation d accès Prérequis Cinématique Transaction TD0.4 - Liste des DMP autorisés Prérequis Cinématique Transaction TD0.5 - Recherche sans INS de patients dans le DMP Prérequis Cinématique Transaction TD0.9 - Accès Web-PS Contextuel Principes généraux Synthèse avec les transactions LPS Accès aux différentes fonctions ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

5 Sommaire 8 Création et gestion administrative du DMP Les différents états d un DMP TD1.1 Création d un DMP Prérequis Cinématique Transaction TD1.2 - Réactivation d un DMP Prérequis Cinématique Transaction TD1.3 Mise à jour des données administratives Prérequis Cinématique Consultation des données administratives et de gestion Modification des données administratives et de gestion TD1.4 Fermeture du DMP Prérequis Cinématique Transaction TD1.5 Accès Internet du Patient Prérequis Cinématique Création du compte internet patient Ajout de canal OTP Activation du compte internet par le patient Déblocage du compte internet ou mise à jour des codes internet TD1.6 - Liste des PS autorisés / bloqués sur un DMP Prérequis Cinématique Transaction Spécifications techniques communes Documentation et références Structure commune des messages HL7 V PS (ou professionnel non PS) recueillant le consentement / auteur de l action sur le dossier Données patient Représentant légal du patient Alimentation du DMP TD2.1 - Alimentation du DMP en documents Prérequis Cinématique générale Saisie du document dans le LPS Génération du document CDA et des métadonnées XDS Signature du document (non obligatoire) Constitution et signature du lot de soumission Transaction : Envoi de la requête au DMP Remplacement d un document existant dans le DMP Consultation du DMP TD3.1 - Recherche de documents dans un DMP Prérequis Cinématique Transaction ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

6 Sommaire 10.2 TD3.2 - Consultation d un document du DMP Prérequis Cinématique Transaction TD3.3 Gestion des attributs d un document Prérequis Cinématique Transaction Annexes Documents externes Documents applicables Documents de référence Annexes externes Terminologie et acronymes WSDL des services Codes d erreurs Liste des codes d erreurs Erreurs spécifiques du processus d authentification («SOAP Fault») Erreurs fréquentes liées aux transactions XDS (TD2.1 / TD3.3 / TD3.1) Autres erreurs fréquentes Signature XAdES Principes généraux de XAdES Rappel des principes de la signature électronique Structure «XAdES W3C» Erreurs fréquentes lors de la mise en œuvre Aide à l implémentation du profil IHE DSG pour le DMP Structure d une soumission XDS.b Construction de la pièce jointe XAdES de signature du lot de soumission Requête d alimentation XDS.b commentée Code exemple Règles sur les dates de naissance lues en carte Vitale Règle AM_DLU : date de naissance «lunaire» Règle AM_BISSEX : détermination d'une année bissextile Règle AM_DNA_SIECLE : détermination du siècle d une date de naissance 247 ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

7 1 Introduction 1 Introduction 1.1 Objet du document L'objectif de ce dossier est de décrire en détail les interfaces externes du système d information du Dossier Médical Personnel (DMP), et permettre aux éditeurs de rendre les «Logiciels de Professionnel de Santé» (LPS) interopérables avec le système DMP et de les homologuer par la procédure de vérification mise en œuvre par l ASIP Santé (voir 3 «Processus d homologation à la DMP Compatibilité»). Outre ce chapitre 1 introductif, ce document est composé des chapitres suivants. Le chapitre 2 retrace le contexte du DMP en général et la place centrale du LPS au cœur de ce contexte. Le chapitre 3 présente la procédure de DMP Compatibilité. Le chapitre 4 présente les profils fonctionnels que l éditeur peut implémenter dans le cadre de la DMP Compatibilité. Le chapitre 5 liste les exigences préalables à la DMP Compatibilité : standards et normes à respecter, référentiels à utiliser, paramétrages du LPS, configuration du poste de travail, etc. Le chapitre 6 présente quelques exemples d intégration du DMP dans les LPS (liste non exhaustive). Le chapitre 7 décrit les règles de base et les transactions à utiliser pour l accès sécurisé au DMP. Le chapitre 8 décrit les transactions à utiliser pour la création et la gestion administrative du DMP (fermeture, réactivation, mise à jour des données administratives). Le chapitre 9 décrit les transactions permettant l alimentation d un DMP en documents. Le chapitre 10 décrit les transactions permettant la consultation d un DMP, la recherche, la consultation, l archivage ou la suppression d un document et la modification de certains attributs d un document (masquage au PS, visibilité au patient). Le chapitre 11 regroupe les annexes et en particulier : Le tableau de l annexe au 11.1 «Documents externes» qui récapitule les principaux documents applicables. Dans l ensemble du présent document, ils sont désignés par le code indiqué dans la colonne «Référence» de ce tableau. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

8 1 Introduction 1.2 Guide de lecture Ce document s adresse aux éditeurs qui souhaitent mettre en œuvre ou maintenir les interfaces de leur LPS avec le DMP. Profil du lecteur / chapitres à lire en priorité Selon son profil (décideur, directeur technique, chef de projet, développeur, architecte logiciel, consultant technique), le lecteur pourra se concentrer sur certains chapitres spécifiques : Profil Chapitres Décideurs 2, 3, 4 et 5 Directeurs techniques, Chefs de projets 2, 3, 4, 5 et 6 Développeurs, Architectes logiciels, Consultants techniques tous Exigence / Recommandation EXIGENCE E Une exigence est une règle de gestion (fonctionnelle ou technique) obligatoire que l éditeur doit implémenter et qui sera contrôlée lors du processus d homologation à la DMP Compatibilité. R RECOMMANDATION Une recommandation vise à aider l éditeur lors de la mise en œuvre ou la maintenance des interfaces avec le DMP. La mise en œuvre d une recommandation n est pas obligatoire pour la DMP Compatibilité. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

9 1 Introduction 1.3 Gestion des versions Le présent document est régulièrement mis à jour pour tenir compte des évolutions du DMP ou des évolutions réglementaires et fonctionnelles. Lien entre version des interfaces externes du DMP et version du DSFT : Version majeure Une nouvelle version majeure des interfaces est une version dans laquelle les interfaces existantes évoluent. A chaque version majeure des interfaces correspond une version majeure du DSFT : on passe par exemple de V1.x.x à V2.x.x. Plusieurs versions majeures des interfaces externes du DMP peuvent coexister en même temps (pendant un temps limité et fixé par l ASIP Santé), ceci afin de laisser suffisamment de temps aux éditeurs de LPS pour adapter leurs produits. Les LPS déjà homologués doivent repasser en homologation pour vérifier leur conformité à ces nouvelles interfaces. Version intermédiaire (ajout de nouvelles interfaces) De nouvelles interfaces (transaction + mode d authentification) peuvent être créées, sans pour autant modifier les interfaces existantes. On considère alors qu il s agit d une version intermédiaire des interfaces. A chaque version intermédiaire des interfaces correspond une version intermédiaire du DSFT : on passe par exemple de V1.0.x à V1.1.x. Seuls les LPS qui proposent ces nouvelles interfaces doivent passer en homologation pour vérifier leur conformité à ces nouvelles interfaces. Version mineure Une version mineure du DSFT est une version dans laquelle les interfaces existantes ne sont pas modifiées et dans laquelle il n y a pas de nouvelles interfaces. Le DSFT passe alors par exemple de V1.0.1 à V Les LPS déjà homologués ne doivent pas repasser en homologation. Tableau récapitulatif des types de version : Version des interfaces externes du DMP Version du DSFT DMP Type de version V1.0 V1.0.0 Mineure V1.0 V1.0.1 Mineure V1.0 V1.0.2 Mineure V1.0 V1.0.3 Mineure V1.1 V1.1.0 Intermédiaire V2.0 V2.0.0 Majeure ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

10 2 Contexte 2 Contexte 2.1 Le DMP Améliorer la coordination des soins Le DMP a été institué par la loi pour faciliter le partage d'informations entre professionnels de santé, éviter les actes redondants et agir contre les interactions médicamenteuses. Face aux défis majeurs que représentent notamment le vieillissement de la population et le développement des maladies chroniques, le Dossier Médical Personnel est un outil moderne et performant qui permet d'améliorer la coordination, la qualité et la continuité des soins pour tous grâce à la traçabilité de l'information (l'historique médical est nécessaire au médecin pour la prise en charge du patient), à une meilleure communication médecin/malade, et à la transmission des informations entre professionnels de santé. Fiabiliser le parcours de soins et les pratiques pluridisciplinaires Le DMP ne remplace pas le dossier du professionnel de santé. Il contient les informations importantes produites lors du parcours de soins du patient et conservées dans les dossiers des professionnels de santé. A ce titre, le DMP permet de fiabiliser le parcours de soins et les pratiques pluridisciplinaires. Il contribue également à soutenir la décision diagnostique et thérapeutique en garantissant une disponibilité des informations au moment utile et en favorisant une structuration de ces informations pour les rendre plus aisément exploitable. Deux modes d'accès au DMP En accès direct depuis le logiciel métier du professionnel de santé, à condition qu il soit «DMP-compatible» : c'est le mode le plus adapté pour le professionnel de santé car le DMP est intégré dans son logiciel habituel. Le présent document décrit les interfaces proposées par le service DMP que les éditeurs de LPS (Logiciels de Professionnels de Santé) doivent mettre en œuvre afin que leurs produits puissent accéder au DMP et devenir DMP-compatibles. Un processus d homologation a été mis en place par l ASIP Santé pour vérifier la DMP Compatibilité des LPS et est présenté dans ce document. En utilisant l Accès Web PS (Professionnel de Santé) accessible par Internet à tout professionnel de santé disposant d une carte CPS (sous certaines conditions de configuration du poste de travail). Note : Les éditeurs peuvent offrir à leurs utilisateurs un accès simplifié à l AW PS directement depuis le LPS en leur évitant de se réauthentifier. Ce mode qui permet d accéder directement soit au tableau de bord du PS soit au DMP d un patient est également décrit dans ce document. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

11 2 Contexte 2.2 Les LPS Les différents types de LPS Dans le présent document, le terme LPS (Logiciel de Professionnel de Santé) désigne tout système d'information utilisé par un professionnel de santé ou une structure de soins, pour l'assister dans la gestion de la prise en charge de ses patients. Outre les fonctions de gestion, de comptabilité, d agenda, etc. un LPS gère, reçoit, émet, stocke des données médicales de ses patients. Parmi les types de LPS couramment répandus aujourd'hui, on distingue : SIH : Systèmes d Information d établissements Hospitaliers, cliniques, PSPH, centres de santé, qui sont souvent eux-mêmes composés d'un éventail de logiciels d'origines diverses ; LGC : Logiciels de Gestion de Cabinet utilisés par les PS libéraux (médecins, dentistes, sages-femmes, infirmiers, etc.) et par leurs secrétariats ; GAM : la Gestion Administrative des Malades utilisée par les accueils d établissements de santé, pouvant faire partie du SIH ; SIR: Système d Information Radiologique (en établissement ou en libéral) ou PACS ; SGL : Système de gestion de laboratoire de biologie ou d'anatomie et de cytologie pathologiques (en établissement ou en libéral) ; EAI : Connecteur ou Enterprise Application Interface. Middleware d interconnexion de différentes applications pouvant jouer notamment le rôle de passerelle vers le DMP. Ce type de LPS est essentiellement déployé dans les structures de soins ; o Ce type particulier de LPS peut imposer de devoir déléguer au système consommateur (le LPS utilisé par le PS pour se connecter au DMP) des exigences du DSFT lors de l homologation à la DMP Compatibilité. Cette délégation devra se faire de manière contractuelle. TLM : Logiciels de Télémédecine (assistance ou surveillance médicale à distance, etc.) ; LDRM : Logiciels de Régulation Médicale (ex : SAMU-centre 15) ; LGO : Logiciels de Gestion d Officine utilisés par les PS en pharmacie ; BIN : Borne Interactive permettant au patient d accéder aux services du DMP : D autres types de LPS que ces types principaux peuvent également exister. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

12 2 Contexte Le LPS au cœur des Systèmes d Information de Santé Le DMP constitue une étape importante dans la mise en œuvre d une stratégie de déploiement des systèmes d information de santé en France. Le LPS est le premier SIS du Professionnel de Santé et il est évidemment l outil naturel d accès au DMP. L objectif de l ASIP Santé est donc de permettre une intégration aussi harmonieuse que possible entre le LPS et le DMP. Le DMP doit être une source de valeur ajoutée métier pour les éditeurs et les professionnels de santé qui travaillent avec leurs logiciels. Par ailleurs, dans un souci de continuité de la prise en charge, une interface d accès (de «substitution» pourrait-on dire) pour les PS via un navigateur permet de prendre en compte les situations particulières d usage ou les restrictions techniques (fonctions non implémentées dans le LPS par exemple). ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

13 2 Contexte 2.3 Les fonctions DMP du LPS Les principales fonctions DMP pouvant être implémentées dans le LPS sont : l accès sécurisé au DMP ; la création et la gestion administrative du DMP ; l alimentation du DMP ; la consultation du DMP ; L implémentation de ces fonctions DMP dans le LPS se traduit par l implémentation d un ensemble de transactions DMP (voir 4 Transactions et profils DMP pour le LPS). L interfaçage du LPS avec le DMP nécessite la mise en place de nouvelles IHM dans les LPS DMP-compatibles. Dans ce document, l ASIP Santé fournit aux éditeurs un certain nombre d éléments de vocabulaire et d ergonomie en cohérence avec l Accès Web PS du SI DMP. R REC_GEN-1010 Il est fortement recommandé d intégrer au sein du LPS les éléments de vocabulaire et d ergonomie fournis par l ASIP Santé. L ASIP Santé met également à la disposition une charte graphique à destination des éditeurs de logiciels DMP-compatibles [CHARTE-GRAPHIQUE_DMP-LPS] décrivant les éléments graphiques relatifs au DMP que les éditeurs peuvent intégrer dans leurs logiciels : logo indiquant que le logiciel est «DMP-compatible», boutons d actions pour accéder à l Accès Web PS du DMP, boutons d actions pour créer, consulter ou alimenter un DMP, bouton d état pour indiquer si le DMP est créé ou pas ou fermé, si le PS est autorisé ou pas. R REC_GEN-1020 Il est fortement recommandé d intégrer au sein du LPS les éléments de la charte graphique fournis par l ASIP Santé. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

14 2 Contexte L accès sécurisé au DMP Le partage de données médicales ne peut avoir lieu sans une confiance forte dans le SIS, rendue possible par la sécurité d accès et par l imputabilité des contenus déposés au sein des DMP. La sécurité est une ligne directrice de la conception du système d information DMP et se traduit par : une authentification forte des acteurs de santé, avec la gestion de certificats et de modes de connexion éprouvés ; une imputabilité des contenus, avec la gestion de signature électronique des lots de documents déposés dans le DMP ; le respect de la confidentialité des données de santé, accessibles en fonction de leurs caractéristiques à certains professionnels de santé autorisés par le patient titulaire du DMP ; la traçabilité de chaque action sur le DMP. L accès au DMP depuis le LPS Selon le niveau d implémentation des fonctions DMP dans son LPS, le PS peut accéder au DMP de son patient : par les fonctions spécifiques DMP intégrées dans son LPS : R REC_GEN-1030 Le niveau d intégration des transactions dans le LPS doit permettre au PS d accéder au DMP sans rupture ergonomique dans l utilisation de son LPS. Le LPS est le moyen d accès privilégié au DMP et est considéré par le DMP comme l interface principale ; par l accès Web-PS appelé depuis son LPS avec passage de contexte. Cela permet au PS d accéder à des fonctions non encore proposées en Web Services (accès aux traces par exemple) ou d accéder à des fonctions non encore implémentées dans son LPS. Le passage de contexte permet au PS d accéder directement soit à son tableau de bord DMP (avec la liste des DMP pour lesquels il est autorisé), soit au DMP d un patient. Note : Le PS peut également se connecter directement au DMP via l Accès Web PS (hors périmètre de ce document). L accès au DMP d un patient par un PS ne peut se faire qu avec l INS du patient. De plus, l accès n est possible qu avec l accord du patient, excepté dans les cas encadrés de l accès bris de glace et de l accès par les permanenciers auxiliaires de régulation médicale des centres de réception et de régulation des appels des SAMU-Centres 15. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

15 2 Contexte Comment récupérer l INS du patient dans le LPS? o par calcul direct à partir des informations lues dans la puce de la carte Vitale ; o o o dans le dossier du patient parce que l INS a été stocké lors d un calcul précédent depuis la carte Vitale ou récupéré depuis un système tiers comme un logiciel de GAM dans un Système d Information Hospitalier par exemple ; par la transaction DMP TD0.4 qui permet de récupérer la liste des DMP pour lesquels le PS dispose d une autorisation d accès. Une fois la liste récupérée, le PS peut enregistrer l INS de son patient. par la transaction DMP TD0.5 qui permet de faire une recherche sans INS du DMP d un patient à partir d autres traits d identité. Une fois le DMP trouvé, le PS peut enregistrer l INS du patient. Enfin, l accès à certaines fonctions est soumis à une combinaison de règles liées au profil de l utilisateur (PS / non PS), à son mode d authentification (directe / indirecte), à sa professions et spécialité (matrice d habilitation du CI-SIS) et à son rôle de l utilisateur (médecin traitant ou pas, centre 15, ). Ces règles sont détaillées au 7 «Accès sécurisé au DMP» La création et la gestion administrative du DMP R REC_GEN-1040 Il est souhaitable que la création et la gestion des données administratives du DMP soient autant que possible intégrées à la gestion des données administratives du LPS. La création et la gestion administrative du DMP regroupent les fonctionnalités suivantes : la création du DMP d un patient, après recueil de son consentement ; la mise à jour des données administratives du DMP d un patient et la création du compte d accès internet du patient la fermeture du DMP d un patient. la réactivation éventuelle d un DMP précédemment fermé, après recueil du consentement du patient ; la consultation de la liste des autorisations sur le DMP. Le compte d accès internet du patient : Pour accéder à son DMP via l accès Web patient, le patient a besoin d un compte d accès internet qui est initialisé par le PS de son choix, soit lors de la création de son DMP, soit ultérieurement. Il pourra ainsi consulter le contenu de son DMP et l enrichir éventuellement d éléments personnels qu il dépose dans un volet d expression qui lui est dédié. Ces documents d expression du patient sont naturellement partagés avec les PS autorisés à accéder au DMP. Il pourra également consulter la liste des traces, masquer tel ou tel document aux PS, gérer les autorisations d accès à son dossier et désigner ses «médecins traitants DMP». ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

16 2 Contexte L alimentation du DMP L alimentation du DMP permet au PS de déposer dans le DMP du patient les documents utiles à la coordination des soins. L objectif est de permettre, avec l accord du patient, un partage des documents du patient entre tous les professionnels de santé qui sont amenés à le prendre en charge. L alimentation du DMP se fait DMP par DMP avec un «lot de soumission» pouvant comprendre un ou plusieurs documents. R REC_GEN-1050 L intégration de la fonction d alimentation du DMP dans le LPS doit se faire avec le minimum d impact pour le PS sur ses habitudes d utilisation du LPS. R REC_GEN-1060 Les règles de déclenchement de l envoi des documents dans le DMP doivent être claires et paramétrables par le PS. Elles doivent s intégrer dans le processus de validation médicale des documents. REC_GEN-1070 R Le choix des documents utiles à la coordination des soins à envoyer dans le DMP est laissé à l appréciation des professionnels de santé. Il est cependant recommandé, pour les CR d examens biologiques, de n envoyer que les CR complets dans le DMP (les CR partiels peuvent être échangés entre professionnels de santé par Messagerie Sécurisée de Santé) La consultation du DMP La consultation du DMP d un patient comporte : la recherche de documents dans le DMP ; la consultation d un document sélectionné ; la gestion des attributs d un document qui permet au PS de : masquer / démasquer un document aux PS (à la demande du patient) rendre un document visible au patient (après la consultation d annonce par exemple) lorsque le document avait été publié avec un attribut «invisible du patient». supprimer un document : il existe toujours dans le DMP mais n est plus visible (suppression logique du document). Un document supprimé ne peut plus être publié. archiver / désarchiver un document : le PS archive un document obsolète qui n est plus utile à la coordination des soins. Il est toujours accessible lors d une recherche, mais uniquement si cette recherche est étendue aux documents archivés. La recherche d un DMP sans l INS : Cette fonction permet de rechercher un patient dans le SI DMP, sans son INS, à partir de traits d identité. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

17 3 Processus d homologation à la DMP Compatibilité 3 Processus d homologation à la DMP Compatibilité 3.1 Présentation du processus d homologation Le processus d homologation vise à s assurer de la conformité d un logiciel aux spécifications fonctionnelles et techniques des interfaces DMP afin de garantir l interopérabilité et la sécurité du service. L entrée dans le processus d homologation est ouverte à toute personne morale propriétaire d une solution logicielle destinée à conserver, échanger et/ou partager des données de santé à caractère personnel et qui a vocation à s interfacer avec le DMP. Le processus d homologation à la DMP Compatibilité est composé de 3 grandes étapes qui sont présentées ci-après. Une présentation détaillée et à jour du processus d homologation est disponible en annexe dans le document [DMP1-ANX-HOM] Constitution du dossier de candidature Signature du Contrat Editeur L éditeur doit envoyer à l ASIP Santé par courrier postal le Contrat Editeur en 2 exemplaires originaux signés et accompagnés d un exemplaire de l Annexe 1 renseignée et signée. Un exemplaire du contrat signé par le Directeur de l ASIP Santé est ensuite renvoyé à l éditeur. Le Contrat Editeur est disponible au téléchargement sur le site de l ASIP Santé : Afin d accélérer le traitement administratif l éditeur peut envoyer, en parallèle de l envoi papier, le Contrat Editeur signé accompagné de l Annexe 1 en version électronique (PDF par exemple) par courrier électronique à l adresse Inscription à la liste de diffusion de la DMP Compatibilité A réception du contrat signé, l éditeur est inscrit à la liste de diffusion de la DMP Compatibilité. Cela lui permet d être tenu informé des différentes informations relatives à la DMP Compatibilité. Cependant, tout éditeur peut demander à être inscrit sur cette liste de diffusion par simple demande à l adresse y compris s il n a pas encore signé de contrat. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

18 3 Processus d homologation à la DMP Compatibilité Développements et tests préparatoires à l homologation Développement et tests des transactions représentatives sur l environnement mutualisé L éditeur développe et teste un ensemble de transactions représentatives indispensables pour entrer dans le processus d homologation. Pour ces tests, l ASIP Santé met à disposition de l éditeur un environnement de test mutualisé (DV1) et un référentiel comportant les cas de test demandés. Les transactions représentatives sont les suivantes : TD0.1 et TD0.2 pour l accès au DMP, TD1.1 pour le profil de création, TD2.1 pour le profil d alimentation, TD3.1 et TD3.2 pour le profil de consultation. L éditeur envoie à l ASIP Santé les trames passantes pour validation. Cette validation permet de passer à la phase suivante Développement et tests de pré-homologation des transactions à homologuer sur l environnement dédié L éditeur développe et teste les transactions qu il souhaite présenter à l homologation. En fonction des profils et transactions que l éditeur souhaite présenter à l homologation, l ASIP Santé transmet à l éditeur la liste des tests de pré-homologation à passer. Pour ces tests de pré-homologation, l ASIP Santé met à disposition de l éditeur un environnement de test dédié (DVx) qui lui est exclusivement affecté. Cet environnement comporte un jeu de données de 20 DMP vides et de 5 DMP chargés avec des documents. L éditeur envoie à l ASIP Santé les trames passantes pour validation. En cas de besoin et sur demande de l éditeur, une assistance technique à l éditeur peut être fournie par l ASIP Santé. Cette assistance n est pas systématique et est soumise à un certain nombre de conditions, décrites dans le document [DMP1-ANX-HOM]. A l issue de cette phase, un point téléphonique est organisé entre l éditeur et l ASIP Santé pour préparer la session formelle d homologation. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

19 3 Processus d homologation à la DMP Compatibilité Homologation Les tests d homologation En fonction des profils et transactions que l éditeur souhaite présenter à l homologation, l ASIP Santé transmet à l éditeur la liste des tests d homologation à passer. L éditeur effectue les tests sur un environnement d homologation dédié (VA) qui lui est exclusivement affecté. L éditeur envoie à l ASIP Santé les résultats et les trames passantes pour validation et les réponses sur le respect des exigences non vérifiables par des tests. Les exigences du Dossier des Spécifications Fonctionnelles et Techniques des Interfaces DMP des LPS sont vérifiées : pour partie au travers de l analyse des résultats de l exécution de tests par le candidat, pour partie par l analyse des réponses fournies par l éditeur sur le respect des exigences non vérifiables par des tests. Le rapport d homologation soumis à l avis du Comité d homologation A l issue de la phase de tests d homologation, l ASIP Santé produit, sur le fondement des résultats des tests d homologation et des informations transmises par le candidat un rapport d homologation qui est présenté au Comité d homologation pour avis. Sur la base de l avis du Comité d homologation, le Directeur de l ASIP Santé peut prendre trois types de décisions : une homologation sans réserve ; une homologation avec réserve(s) ; un refus d homologation En savoir plus sur la DMP Compatibilité Les éditeurs peuvent consulter les FAQ de la DMP Compatibilité qui sont disponibles sur le site esante.gouv.fr : et régulièrement mises à jour. Les éditeurs peuvent aussi contacter l équipe en charge de la DMP Compatibilité à l ASIP Santé par mail à : ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

20 3 Processus d homologation à la DMP Compatibilité 3.2 Les environnements techniques Ce chapitre présente un résumé des différents environnements techniques DMP mis à disposition par l ASIP Santé et utilisés par les éditeurs lors du processus d homologation à la DMP Compatibilité Les environnements d homologation Environnement Phase Environnement de test mutualisé (DV1) Développement des transactions représentatives : TD0.1 et TD0.2 pour l accès au DMP, TD1.1 pour le profil de création, TD2.1 pour le profil d alimentation, TD3.1 et TD3.2 pour le profil de consultation. Tests des transactions représentatives et envoi à l ASIP Santé des trames passantes pour validation avant ouverture de l environnement de test dédié. Environnement de test dédié (DVx) Développement des transactions complémentaires. Tests de pré-homologation et envoi à l ASIP Santé des résultats pour validation. Environnement d homologation dédié (VA) Tests d homologation et envoi à l ASIP Santé des résultats pour validation. Environnement de test mutualisé pour transactions homologués (DVH) Tests de transactions homologués pour : reproduire des comportements observés en production suite à des retours d utilisateurs, conduire des tests d interopérabilité avec d autres éditeurs de LPS avec lesquels vous vous seriez entendu (éventuellement si vous le souhaitez). Le support de ces environnements est assuré par l équipe en charge de la DMP Compatibilité à l ASIP Santé par mail à : L accès à ces environnements se fait au moyen de cartes CPx et de certificats de test. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

21 3 Processus d homologation à la DMP Compatibilité Les environnements de formation et de production L éditeur peut donner accès aux environnements de formation via son LPS homologué à des fins de : Environnements de formation (il y en a 4) Formation d utilisateurs Test de raccordement au DMP depuis un environnement de test de ses clients (par exemple : réalisation de tests fonctionnels suite à l implémentation d une version DMP- Compatible dans un établissement). Il n y a pas besoin de déclaration préalable d adresses IP pour y accéder et le n d homologation fourni pour les tests peut y être utilisé (champ LPS_ID_HOMOLOGATION_DMP du VIHF). Seules des données de tests doivent être utilisées sur les environnements de formation. Pour plus d information voir : Environnement de production DMP de production (utilisation réelle) uniquement accessible par les logiciels homologués avec le n d homologation spécifique (champ LPS_ID_HOMOLOGATION_DMP du VIHF). Les cartes Vitale de tests et de démonstration ne doivent pas être utilisées sur l environnement DMP de production, exclusivement destiné au traitement de données réelles. Le support de ces environnements est assuré par DMP Info Service (24/24, 7/7) au (prix d un appel local) via le formulaire de contact L accès aux environnements de formation se fait au moyen de cartes CPx de test et de certificats de test uniquement. L accès à l environnement de production se fait au moyen de CPx et certificats de production uniquement. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

22 4 Transactions et profils DMP pour les LPS 4 Transactions et profils DMP pour les LPS 4.1 Description des transactions DMP Les transactions DMP peuvent fonctionnellement être liées entre elles et certaines d entre elles doivent être implémentées conjointement. Le tableau ci-dessous présente les transactions DMP qui peuvent être implémentées. Fig. 1 : Les transactions DMP ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

23 4 Transactions et profils DMP pour les LPS Description synthétique des transactions DMP Les spécifications détaillées des transactions sont décrites aux paragraphes 7 à 10 du présent document. Transactions DMP pour LPS ACCES SECURISE AU DMP Authentification sur le DMP TD0.1 TD0.2 TD0.3 TD0.4 TD0.5 TD0.9 Test d existence d un DMP et vérification de l autorisation d accès Mise à jour de l autorisation d accès Liste des dossiers autorisés Recherche sans INS de patients dans le SI DMP Accès web-ps contextuel Description synthétique Permet d authentifier l acteur de santé (PS ou STS) auprès du système DMP. Permet de vérifier qu un DMP existe, de récupérer le statut d un DMP et celui de l autorisation d accès de l acteur de santé sur ce DMP. Permet à l acteur de santé de se déclarer autorisé par le patient à accéder au DMP du patient ou au contraire se retirer de la liste des PS autorisés. Permet de récupérer la liste des DMP pour lesquels l acteur de santé dispose d une autorisation d accès (liste exhaustive des dossiers ou liste des dossiers pour lesquels une nouvelle autorisation a été donnée depuis une date donnée). Permet de chercher un ou des patients dans le SI DMP, sans son INS, à partir d autres traits d identité. Permet d ouvrir l Accès Web DMP dans un navigateur, avec passage contextuel d information (INS du patient, ). CREATION ET GESTION ADMINISTRATIVE DU DMP TD1.1 Création d un DMP Permet de créer le DMP d un patient. TD1.2 Réactivation d un DMP Permet de réactiver un DMP qui a été fermé. TD1.3 Données administratives d un Permet de consulter et mettre à jour les données DMP administratives d un DMP TD1.4 Fermeture d un DMP Permet de fermer un DMP. TD1.5 Accès internet du patient Permet d initialiser, mettre à jour ou débloquer le compte d accès internet d un patient. TD1.6 Liste des PS autorisés/bloqués Permet d obtenir, pour un DMP, la liste des PS autorisés sur un DMP à y accéder, la liste des PS bloqués, ou les 2. ALIMENTATION DU DMP Alimentation en documents d un DMP TD2.1 CONSULTATION DU DMP TD3.1 Recherche de documents dans un DMP TD3.2 Consultation d un document dans un DMP Gestion des attributs d un TD3.3 document Permet de déposer un (ou des) document(s) dans le DMP d un patient. Cette transaction gère aussi les mises à jour successives d un document avec le remplacement d un document par une nouvelle version. Permet de rechercher des documents dans l index des documents du DMP d un patient. Permet de récupérer et consulter un document (à partir de l identifiant du document récupéré par la TD3.1). Permet de gérer les attributs d un document : masquer/démasquer aux PS, rendre visible au patient, archiver/désarchiver et supprimer. Tableau 2 : Description des transactions La liste des URL de Web Services par transaction et fonction, noms de méthodes, WSDL est fournie en annexe 11.3 «WSDL des services». ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

24 4 Transactions et profils DMP pour les LPS 4.2 Mode d authentification Le mode d authentification a une forte influence sur les règles de gestion. Certaines fonctions sont accessibles ou pas selon le mode d authentification. Par exemple, la consultation de DMP n'est possible qu'en mode d'authentification directe. La liste détaillée des fonctions accessibles ou pas selon le mode d authentification est donnée dans le tableau du Comme spécifié dans [CI-TR-CLI-LRD], deux configurations d authentification du PS sur le DMP sont possibles pour un LPS : Authentification indirecte L utilisateur utilise un LPS hébergé au sein d'une structure de soins (STS) et c'est cette structure qui s'authentifie auprès du DMP au moyen d un certificat logiciel d authentification pour personne morale. Cependant, l accès au DMP nécessite que chaque utilisateur soit identifié nominativement : il est donc indispensable que le LPS soit en mesure de fournir au DMP l identifiant (éventuellement interne) des utilisateurs à l origine des transactions. Il faut donc que l utilisateur final s'authentifie localement au sein de la structure (STS) qui porte ainsi la responsabilité des échanges avec le DMP et de l identification de l utilisateur final Authentification directe L utilisateur utilise sa carte CPS (ou CPF et CPE pourvu qu elles soient rattachées à une structure) pour s authentifier directement auprès du DMP. Fig. 3 : Modes d authentification au DMP ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

25 4 Transactions et profils DMP pour les LPS 4.3 Utilisateurs et droits associés Il faut distinguer les professionnels de santé et les utilisateurs qui ne sont pas professionnels de santé car ils n ont pas les mêmes droits vis-à-vis du DMP. Certaines fonctions sont accessibles aux PS et pas accessibles aux utilisateurs non PS. De même, certaines fonctions sont accessibles à certaines catégories de PS et pas à d autres Professionnels de santé Parmi les professionnels de santé on distingue plusieurs catégories auxquelles sont associées des droits particuliers dans le DMP : D une manière générale, une fois authentifiés et s ils sont autorisés, les PS peuvent : o o créer et alimenter un DMP accéder aux traces fonctionnelles de leur propre activité Les conditions d accès en lecture aux documents contenus dans un DMP (sur lequel ils ont l autorisation d accès) dépendent des professions et spécialités des PS recueillies à partir de la carte CPS (ou CPF) du PS. Ces règles sont définies dans la matrice d habilitation du CI-SIS. Seuls les PS médecins (code profession CPS 10) et l auteur du document peuvent supprimer et archiver/désarchiver un document. Seuls les PS médecins (code profession CPS 10) peuvent, à la demande du patient, se déclarer «médecin traitant». Il peut y avoir plusieurs médecins traitants du DMP d un même patient. Il n'y a pas de synchronisation entre les SI DMP et les SI des organismes d'assurance maladie. Le patient doit donc toujours effectuer les démarches habituelles pour déclarer un médecin traitant auprès de l Assurance Maladie. les médecins traitants ont des droits étendus sur le DMP du patient car ils peuvent : o o o o o accéder à tous les documents masqués de ce dossier (et si nécessaire démasquer un document masqué), accéder à toutes les traces fonctionnelles du dossier (les siennes et celles des autres PS), gérer les autorisations d accès à un DMP, effectuer une demande de copie du DMP pour le compte de son titulaire, effectuer une demande de destruction de tout document ou de l ensemble du DMP pour le compte de son titulaire. les permanenciers auxiliaires de régulation médicale (PARM) des centres de réception et de régulation des appels des SAMU-Centres 15 sont autorisés à utiliser la fonctionnalité de recherche d un DMP sans l INS du patient (à partir d autres traits d identité) mais la consultation du DMP d un patient reste réservée au médecin régulateur authentifié par sa CPS. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

26 4 Transactions et profils DMP pour les LPS Les acteurs non PS Il s agit du personnel d accueil en STS (via la GAM) ou en cabinet qui peut créer le DMP d un patient. Dans la mesure où il peut créer un DMP, il lui est également possible de corriger les données administratives du patient. Lorsqu il est connecté en authentification indirecte (avec le certificat logiciel d authentification pour personne morale de sa STS), un acteur non PS peut alimenter le DMP. Qu il soit connecté en authentification directe avec une carte CPE ou en authentification indirecte avec le certificat logiciel d authentification pour personne morale de sa STS, l acteur non PS ne peut pas consulter les documents du DMP d un patient. Ces acteurs non PS sont uniquement autorisés à : la création de DMP, la création du compte d accès internet du patient et la mise à jour de données administratives, sous réserve que leur structure soit autorisée à accéder au DMP du patient. alimenter le DMP, s il est connecté en authentification indirecte (avec le certificat de la STS). ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

27 4 Transactions et profils DMP pour les LPS 4.4 Choix de profils à implémenter dans un LPS Principes généraux Chacun des 3 profils DMP (Création, Alimentation et Consultation) est constitué de transactions obligatoires et de transactions optionnelles (voir tableau 2 ci-dessous). Profils DMP Transactions DMP à implémenter CREATION ALIMENTATION CONSULTATION ACCES SECURISE AU DMP TD0.1 Authentification sur le DMP Obligatoire TD0.2 Test d existence d un DMP et vérification de l autorisation d accès Obligatoire (2) TD0.3 Mise à jour de l autorisation d accès Obligatoire (2) TD0.4 Liste des dossiers autorisés Optionnelle TD0.5 Recherche sans INS du DMP d un patient Optionnelle Optionnelle Optionnelle (2) TD0.9 Accès web-ps contextuel Optionnelle (1) Optionnelle (1) Obligatoire (1) (2) CREATION ET GESTION ADMINISTRATIVE DU DMP TD1.1 Création d un DMP Obligatoire TD1.2 Réactivation d un DMP Optionnelle TD1.3 Données administratives d un DMP Optionnelle TD1.4 Fermeture d un DMP Optionnelle (1) TD1.5 Accès internet du patient Obligatoire TD1.6 Liste des PS autorisés/bloqués sur un DMP Optionnelle (1) ALIMENTATION DU DMP TD2.1 Alimentation en documents d un DMP Obligatoire CONSULTATION DU DMP TD3.1 Recherche de documents dans un DMP Obligatoire (1) TD3.2 Consultation d un document dans un DMP Obligatoire (1) TD3.3 Gestion des attributs d un document Obligatoire (3) Optionnelle (1) (1) L utilisation de la CPS (ou CPF) est obligatoire. Les CPE sont exclues. (2) Sauf pour les LDRM pour lesquels la transaction TD0.5 est obligatoire et les transactions TD0.2, TD0.3, TD0.9 sont optionnelles. (3) Permet de dépublier un document envoyé par erreur Tableau 4 : Liste des transactions à implémenter par profil E EX_GEN-1110 L éditeur doit obligatoirement implémenter les transactions «Obligatoires» du profil «Accès sécurisé au DMP». ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

28 4 Transactions et profils DMP pour les LPS Ensuite, selon ses besoins, l éditeur sélectionne les profils qu il souhaite implémenter dans son LPS. E EX_GEN-1120 Pour chaque profil qu il souhaite implémenter, l éditeur doit obligatoirement implémenter les transactions «Obligatoires» du profil. Les transactions «Optionnelles» ne sont pas obligatoires et l éditeur peut décider de les implémenter ou pas. Exemple : Pour le profil «CREATION», l éditeur doit obligatoirement implémenter les transactions TD0.1, TD0.2, TD0.3, TD1.1 et TD1.5. En fonction de son besoin, il peut compléter son implémentation avec les transactions TD0.4, TD0.5, TD0.9, TD1.2, TD1.3, TD1.4 et TD1.6. En implémentant la transaction TD0.9 «Accès Web-PS Contextuel», l éditeur donne accès à ses utilisateurs, à partir de leur LPS, aux fonctionnalités du DMP couvertes par l AW PS. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

29 4 Transactions et profils DMP pour les LPS L implémentation des profils DMP dans les LPS L implémentation des profils DMP dans les LPS doit respecter les exigences définies dans le présent document. Elles seront contrôlées lors du processus d homologation à la DMP Compatibilité, doit suivre les règles de bonnes pratiques qui sont de la responsabilité de l éditeur, peut suivre (cela est laissé à l appréciation de l éditeur) les conseils et recommandations (par exemple ergonomiques) fournis par l ASIP Santé (dans ce document ou lors du processus d homologation à la DMP Compatibilité). Les éditeurs doivent porter une attention particulière aux données utilisées dans les transactions : L éditeur doit s assurer que le LPS dispose de l ensemble des données «requises» utilisées dans les transactions du LPS vers le DMP. Si ce n est pas le cas, il devra au préalable modifier le LPS pour intégrer les données manquantes. Pour rappel, les données exigées par le DMP sont cohérentes avec le cadre d interopérabilité et donc avec l ensemble des SIS nationaux ; L éditeur peut décider, pour le bénéfice de ses utilisateurs et si ce n était initialement pas le cas, d intégrer dans le LPS la gestion d une donnée transmise par une transaction du DMP. E E EX_GEN-1140 Le LPS doit gérer correctement les codes retours et codes d erreurs retournés par le SI DMP qui peuvent déterminer, dans certains cas, les actions possibles ou pas vis-à-vis du DMP. EX_GEN-1145 Les messages affichées doivent être spécifiques à chaque situation (code retour ou d erreur) et facilement compréhensibles des utilisateurs. EX_GEN-1150 E Dans le cas de transactions utilisées dans un mode asynchrone (pour l alimentation du DMP par exemple), l éditeur doit implémenter une fonctionnalité permettant de traiter les erreurs (par exemple, tableau de bord de reporting / gestion des erreurs) et si nécessaire prévoir des mesures organisationnelles pour traiter ces erreurs. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

30 4 Transactions et profils DMP pour les LPS 4.5 Homologation des profils implémentés Lors du processus d homologation, la DMP Compatibilité est vérifiée par profil (cf. 4.4) / mode d'authentification (cf. 4.2). L'homologation porte sur l'ensemble des transactions requises du profil et sur les transactions optionnelles que l éditeur a décidé d'intégrer. L éditeur peut intégrer les différents profils ou transactions à son rythme, en passant plusieurs homologations pour des profils / transactions / mode d authentification différents. A chaque nouvelle homologation la totalité des transactions fait l'objet de vérifications par l'asip Santé. La liste des transactions implémentées par le LPS et validées par le processus de DMP Compatibilité est rattachée au numéro d homologation fourni par l ASIP Santé. EX_GEN-1160 E E E E Comme indiqué dans le contrat éditeur, l éditeur s engage à mettre à la disposition de ses clients, selon les conditions commerciales fixées par ses soins, les logiciels de la famille de produits homologuée, dans un délai de deux mois calendaires à compter de la date de réception du courrier de décision favorable d homologation. EX_GEN-1170 Le logiciel DMP-Compatible doit impérativement proposer aux utilisateurs les transactions obligatoires des profils implémentés. EX_GEN-1180 L éditeur doit mettre en œuvre dans les LPS homologués un dispositif d affichage du ou des profils DMP homologués et de la date d homologation (menu de type «à propos» par exemple). EX_GEN-1190 L éditeur doit préciser dans la documentation de fonctionnement des LPS homologués les fonctions DMP intégrées, ainsi que celles qui ne le sont pas. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

31 5 Exigences préalables à la DMP Compatibilité 5 Exigences préalables à la DMP Compatibilité La mise en œuvre de la DMP Compatibilité d un LPS repose fortement sur : le respect des spécifications décrites dans le présent document : o Voir paragraphes 7 à 10 qui décrivent les transactions DMP le respect des standards et normes retenus o Ces standards et normes sont présentés dans le 5.1. l existence préalable de fonctionnalités ou conditions spécifiques au niveau du paramétrage du LPS (voir 5.2) ou de la configuration du poste de travail / serveur (voir 5.3). 5.1 Standards, normes, référentiels L annexe 11.1 «Documents externes» présente la liste des documents externes auxquels se référer. Cette liste permet de vérifier les versions des normes prises en compte dans le DMP. Les standards et normes à maitriser sont liés au cadre d interopérabilité des SIS (CI-SIS) ; au profil IHE XDS ; à la norme HL7 V3 (création de DMP, gestion du dossier) ; au profil IHE PDQ HL7 V3 (utilisé pour la mise en œuvre de la recherche de DMP sans INS, fonctionnalité actuellement prévue uniquement pour les centres de régulation). à l INS Le cadre d interopérabilité des SIS E EX_GEN-1210 Les interfaces DMP des LPS doivent être conformes à la version applicable du CI-SIS. Les spécifications des interfaces avec le DMP s appuient sur le cadre d interopérabilité des systèmes d information de santé de l ASIP Santé définissant les standards (techniques, sémantiques et de sécurité) à utiliser dans les échanges de données de santé dans le contexte français. Dans la suite du document, ce cadre d interopérabilité sera nommé «CI- SIS». La structuration standardisée des documents, spécifiée dans le CI-SIS va contribuer au développement de nouveaux usages et de nouvelles fonctionnalités par les éditeurs de LPS. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

32 5 Exigences préalables à la DMP Compatibilité Par rapport au CI-SIS, le projet DMP s inscrit dans le partage de contenus d informations de santé (documents médicaux persistants) ; le LPS est le système source (parfois aussi appelé système initiateur) et le DMP est le système cible. La version du CI-SIS à utiliser Le CI-SIS évolue indépendamment du SI DMP et donc du présent document. Les interfaces DMP définies dans ce document s appuient sur le CI-SIS v accessible sur (document zip «ANCIENNE VERSION DU CI-SIS 1.0.1»), même si une version postérieure est déjà en ligne sur le site esante.gouv.fr par ailleurs. Les références au CI-SIS dans le présent DSFT Des références au CI-SIS sont faites dans ce document. Elles sont de la forme [CI-XXXX] conformément aux références du tableau de l annexe 11.1 «Documents applicables». Les documents importants du CI-SIS Pour les lecteurs de «profil 1» (décideurs) ou de «profil 2» (directeurs techniques ou chefs de projets), il est vivement conseillé de lire le «document chapeau» du CI-SIS [CI_CHAP]. Le CI-SIS fait en effet référence à des standards et recommandations internationaux (XDS, HL7 ) que le lecteur devra maîtriser. Pour le lecteur de «profil 3» (développeur, consultant), la lecture des documents listés ciaprès permet également d acquérir les connaissances techniques minimales pour être en mesure de rendre un LPS interopérable avec le DMP (cette lecture pourra se faire après la lecture de la présente spécification) : [CI-TR-CLI-LRD] Couche Transport Volet Synchrone Client Lourd ; [CI-GESTPAT] Couche Service Volet Gestion de Dossier Patient Partagé ; [CI-PARTAGE] Couche Service Volet Partage de Documents de Santé ; [CI-STRU-ENTETE] Couche Contenu Volet Structuration Minimale. Les nomenclatures à utiliser Les nomenclatures sont décrites dans [CI-ANX-NOMENC-DOC] et [CI-JEUX-VALEURS]. Ces nomenclatures sont : les classes de documents (classcode XDS), les types de documents (typecode XDS) et le format de document (formatcode XDS) ; la profession/spécialité (authorspecialty XDS) qui peut être lue en carte CPS mais qui peut nécessiter un transcodage entre le code lu dans la CPS et le code décrit dans [CI- ANX-PS-STRU] ; le cadre d exercice (practicesettingcode XDS) qui peut être paramétré au niveau du LPS et le secteur d activité (ou modalité d exercice) (healthcarefacilitytypecode XDS) qui peut être lu en carte CPS mais qui peut nécessiter un transcodage entre le code lu dans la CPS et le code décrit dans [CI-ANX-PS-STRU] ; type d activité clinique (contenttypecode XDS) ; ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

33 5 Exigences préalables à la DMP Compatibilité Les tables de transcodage des spécialités et des secteurs d activité entre ADELI et RPPS sont dans [TRANS-ADELI-RPPS]. Les correspondances à respecter entre les valeurs Le CI-SIS impose certaines règles de correspondances entre les valeurs des nomenclatures. Correspondance entre Classe et Type de document La table de correspondance ASIP-SANTE_X04_<aaaammjj>.jv du [CI-JEUX-VALEURS] contient la liste des correspondances possibles entre la classe de documents et le type du document. Par exemple : Classe Type 10 Comptes rendus CR ou fiche de consultation ou de visite 10 Comptes rendus CR d imagerie médicale 11 - Synthèses SYNTH Synthèse Par contre, il n y a pas de table décrivant la correspondance précise entre le type de document et le format du document Le profil IHE XDS.b La gestion des documents du DMP et leurs métadonnées est implémentée par le profil IHE XDS.b, décrit dans le document [CI-PARTAGE]. Un complément pédagogique à ce document a également été produit par l ASIP Santé. Dans la version actuelle du DMP, les Classeurs (Folders) ne sont pas supportés. D un point de vue IHE, les acteurs rentrant en ligne de compte sont : repository XDS.b : entrepôt de stockage des documents, utilisé dans l alimentation et la consultation des documents du DMP ; registry XDS.b : registre d indexation des métadonnées des documents, utilisé dans la recherche et l extraction des métadonnées des documents du DMP. Note : Par rapport à l acteur IHE standard, les transactions registerdocumentsetb ainsi que les transactions ITI-44 ne sont pas accessibles à des systèmes externes au DMP sur la Registry du DMP ; le LPS : Document Source (émetteur de document), Document Consumer (utilisateur de document), Document Administrator. Bien qu ils soient disponibles sur deux endpoints SOAP différents, les deux acteurs repository et registry doivent être vus «groupés» comme un seul acteur technique du point de vue du LPS : ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

34 5 Exigences préalables à la DMP Compatibilité LPS (Document Source, Document Consumer, Document Administrator) Recherche de documents Mise à jour de métadonnées Alimentation Consultation documents Registry XDS.b DMP Repository XDS.b Fig. 5 : Schéma de principe des acteurs XDS Domaine d affinité XDS (XDS Affinity Domain) Le domaine d identification des patients au sein du DMP est l INS (INS-A ou INS-C) : voir la métadonnée patientid dans [CI-PARTAGE]. Les nomenclatures associées au domaine d affinité XDS sont définies dans [CI-ANX- NOMENC-DOC] et [CI-ANX-PS-STRU]. Le DMP n impose pas la mise en œuvre stricto sensu du profil IHE ATNA, groupé habituellement avec le profil XDS.b : les considérations d authentification («node authentication») sont définies au 7.1 «Exigences générales de sécurité» ; les considérations d audit («audit trail») ne sont pas imposées au LPS ; l audit est réalisé directement par le système DMP qui génère ses propres traces fonctionnelles et techniques (service d audit du DMP) à la réception des flux. Le LPS peut néanmoins s il le souhaite générer ses propres traces vers un «audit repository» de son choix (y compris lui-même). Les métadonnées XDS L Alimentation met en œuvre le profil IHE XDS.b et la gestion des métadonnées des documents XDS est décrite au «Les métadonnées XDS». La Consultation utilisant également ce profil, les références décrites dans ce paragraphe s appliquent également. Code exemple et aides Des exemples de messages XDS-b sont fournis en annexe au 11.7 «Code exemple». Le wiki d IHE donne des informations sur le profil XDS.b et propose des exemples de trames XDS.b à l adresse suivante : Les documents [CI-PARTAGE] et [IHE-TF3] synthétisent les métadonnées des documents / lots XDS (nom, valeurs, types de données, entryuuid, statuts, codes erreurs XDS ). ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

35 5 Exigences préalables à la DMP Compatibilité Gestion des erreurs La gestion des erreurs est conforme au profil IHE XDS.b, à la nuance suivante : le statut «urn:ihe:iti:2007:responsestatustype:partialsuccess» n'est pas géré. Les erreurs retournées comprennent donc les données suivantes : Nom du champ status errorcode Contenu urn:oasis:names:tc:ebxmlregrep:responsestatustype:success urn:oasis:names:tc:ebxmlregrep:responsestatustype:failure Description Contient le statut de la transaction : Success : la transaction s est correctement déroulée Failure : un problème est survenu. Une ou plusieurs erreurs présentes dans RegistryErrorList permettent d avoir plus d informations sur la nature du problème. Code d erreur (en cas d erreur) Contient un code d erreur XDS. Les valeurs possibles sont décrites dans [IHE- TF3] codecontext Libellé de l erreur associé (en cas d erreur) Location Localisation de l erreur (en cas d erreur) D autres codes spécifiques au DMP peuvent être retournés (voir le détail dans les transactions). Contient des informations complémentaires quant à la nature de l erreur. Dans le cadre du DMP, ce champ est structuré de la manière suivante : [;Info1[,Info2 ]] Les informations complémentaires (Info1, Info2, etc.) dépendent de la nature de l erreur. Il peut s agir par exemple d un identifiant de document. Localisation de l erreur au sein du SI DMP (code interne à l applicatif) Tableau 6 : XDS-b Détails de la structure des erreurs retournées Exemple : paramètre obligatoire manquant pour une recherche dans la registry <RegistryResponse xmlns="urn:oasis:names:tc:ebxml-regrep:registry:xsd:2.1" status="urn:oasis:names:tc:ebxml-regrep:responsestatustype:failure"> <RegistryErrorList> <RegistryError errorcode="xdsstoredquerymissingparam" codecontext="paramètre manquant : $XDSDocumentEntryPatientId" location="xdsregistryadaptor.registrystoredquery" severity="error" /> </RegistryErrorList> </RegistryResponse> ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

36 5 Exigences préalables à la DMP Compatibilité Identification du patient par son INS L INS Les raisons d être de l identifiant National de Santé sont exprimées dans l article L du Code de la Santé Publique : «[ ] Un identifiant de santé des bénéficiaires de l'assurance maladie pris en charge par un PS ou un ES ou dans le cadre d'un réseau de santé est utilisé [ ] pour la conservation, l'hébergement et la transmission des informations de santé. Il est également utilisé pour l'ouverture et la tenue du dossier médical personnel et du dossier pharmaceutique [ ]». En application de l'avis de la CNIL du 20 février 2007, il est : unique : un seul INS pour chaque personne tout au long de sa vie ; non signifiant : la connaissance de l'ins ne doit pas permettre de déduire des informations sur la personne ; sans doublon ni collision. L INS n'est ni public, ni secret : il est privé, c'est une information personnelle du patient, protégée par la Loi informatique et liberté, au même titre que le nom et le prénom. L INS n'est pas porteur en soi de sécurité, c'est la procédure d'authentification qui associe un individu à un identifiant qui concourt à la sécurité Stratégie de déploiement de l INS Pour répondre aux besoins à court terme et ne pas pénaliser le déploiement des systèmes de santé partagés, un INS dit «calculé» est utilisé (INS-C). L INS-C peut être calculé localement dans tout système d information de santé (LGC, SIH, réseau, ) en appliquant un algorithme connu de tous les acteurs sur un nombre réduit de traits d identité extraits de la carte Vitale du patient. Le choix des traits utilisés vise à limiter le risque de doublon dans la mesure où ces traits sont parmi les plus invariables de la personne. Un risque minime et assumé de collision demeure, il est lié au processus mathématique et minimisé par le choix de l algorithme étudié en coopération avec les experts de l ANSSI (Agence nationale de la sécurité des systèmes d information). Note : Le NIR de certains ayants droits n est pas indiqué sur les cartes de leurs ouvrants droits (cas de la majorité des enfants du régime général par exemple). Il n est pas possible de calculer leur INS-C et ils ne peuvent donc pas avoir de DMP. A terme, l INS-A (identifiant généré aléatoirement, sans collision, sans doublon, non signifiant, non prévisible et géré par un système centralisé) remplacera l utilisation de l INS- C. Les règles de passage de l INS-C à l INS-A seront définies ultérieurement Gestion de l INS dans le LPS E EX_GEN-1220 Le LPS doit gérer (et stocker), pour chaque INS, le statut de l INS. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

37 5 Exigences préalables à la DMP Compatibilité Statut de l INS Fourni par un tiers, à vérifier Fourni par un tiers sûr Calculé par le LPS avec une carte Vitale Associé à un DMP Actions possibles L INS doit être vérifié (voir l exigence liée au ). Aucune action vers les DMP n est possible excepté pour vérifier l INS (en utilisant la TD0.2 «Test d existence d un DMP et vérification de l autorisation»). L INS peut être utilisé pour toutes les transactions excepté la transaction TD1.1 «Création d un DMP» et la transaction TD1.2 «Réactivation d un DMP». Dans le cas des EAI recevant l INS par un tiers (par exemple la GAM), les transactions TD1.1 «Création d un DMP» et TD1.2 «Réactivation d un DMP» sont autorisées. L INS peut être utilisé pour toutes les transactions. L INS peut être utilisé pour toutes les transactions. Tableau 7 : Les status de l INS Dans les trois premiers cas, l existence du DMP n est pas connue. EX_GEN-1230 E Il est impératif de mettre en place au niveau des LPS des mécanismes d identito-vigilance dans deux cas de figure : Dans le cas où le dossier existe en local lors d une création ou d une réactivation de DMP, afin d éviter : o L association de la carte Vitale d un patient à un autre patient dans le LPS ; o La sélection de l ouvrant droit (parent, conjoint assuré) au lieu d un ayant droit (enfant, conjoint bénéficiaire) sur la carte Vitale (ou le contraire : ayant droit au lieu de l ouvrant droit) et association au mauvais patient dans le LPS. Dans le cas où l INS est au statut «Fourni par un tiers, à vérifier» (cf ) Pour information : Il est indispensable, avant toute utilisation de la carte Vitale pour calculer l INS du patient et créer son DMP, que le PS (ou autre Acteur de santé) s assure qu elle appartient bien au patient. De même, il est indispensable, si le patient fournit directement l INS, que le PS (ou autre Acteur de santé) s assure qu il s agit bien de celui du patient. En cas de doute, le PS (ou autre Acteur de santé) ne doit pas les utiliser pour créer ou accéder à un DMP. Contrôle d identito-vigilance Dans le cas où les traits d identité de la carte Vitale sont différents des traits d identité stockés dans le dossier du patient existant dans le LPS, le LPS doit proposer une fenêtre d identito-vigilance pour demander à l utilisateur de vérifier qu il s agit bien du bon patient. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

38 5 Exigences préalables à la DMP Compatibilité Dans le cas où les traits sont identiques, le LPS ne doit pas solliciter l utilisateur. La comparaison des traits (effectué automatiquement par le LPS) doit porter sur la comparaison des champs «nom», «prénom» et «date de naissance» et utiliser l algorithme de normalisation de caractères défini dans le dossier INS-C [INSC-DOSS]. Nom de naissance, nom de famille, nom d usage : quelles sont les correspondances? Le nom légal d'une personne en France (celui qui figure sur sa carte d'identité), est son "nom de famille" dont les règles de dévolution en vigueur depuis le 1 er juillet 2006 sont fixées par les articles à du code civil. Le nom de famille est fixé lors de la naissance ou lors de l'adoption de l'enfant ou lors de l'acquisition de la nationalité française par la personne. Il ne change plus par la suite. En plus de ce nom de famille qui est permanent, une personne peut choisir de se faire appeler par un nom d'usage pour une période temporaire de sa vie (par exemple le nom de son époux pour une femme mariée ou réciproquement). Ce nom d'usage est temporaire. Comme c'est sous ce nom d'usage que la personne se désigne de préférence, celui-ci est connu de son environnement et trouve donc naturellement sa place dans les systèmes d'information enregistrant cette personne, dans une case distincte de celle contenant le nom de famille. Le tableau ci-dessous synthétise les correspondances entre les différents supports pour le stockage des noms de famille et d'usage du patient. Nom de famille du patient Nom d'usage du patient Carte Vitale V1bis Absent Obligatoire Désignation : nom usuel ou nom d usage Carte Vitale V1ter Facultatif Désignation : nom de famille nom patronymique ou Obligatoire Désignation : nom usuel ou nom d usage CI-SIS : En-tête CDA des documents partagés CI-SIS : Métadonnée document sourcepatientinfo de XDS Accès web patient DMP Accès web PS DMP Composant 1 de PID-5 lorsque composant 7 de PID-5 = 'L' (Legal name) Facultatif Désignation : Nom de naissance Facultatif Désignation : Nom de naissance Composant 1 de PID-5 lorsque composant 7 de PID-5 = 'D' (Display name) Obligatoire Désignation : Nom d usage Obligatoire Désignation : Nom d usage ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

39 5 Exigences préalables à la DMP Compatibilité Calcul de l INS-C à partir de la carte Vitale R REC_GEN-1240 Il est recommandé que le LPS puisse calculer l INS-C. Le dossier complet [INSC-DOSS] «ASIP Programme INS-C dossier de conception» comporte l algorithme de calcul, des jeux de tests et des exemples de code. EX_GEN-1250 E Les LPS implémentant le profil «Création» doivent obligatoirement savoir calculer l INS-C à partir des éléments lus en carte Vitale. Dans ce cas, les actions sont à réaliser dans l ordre suivant : Lire la carte Vitale ; Calculer l INS ; Stocker l INS dans le LPS au statut «calculé avec une carte Vitale» ; Stocker les traits d identité suivants issus de la carte Vitale ou les utiliser immédiatement dans le processus de création du DMP sans les modifier : o nom de famille ; o nom d usage ; o prénom ; o date de naissance ; Créer le DMP du patient ; REC_GEN-1260 R S il est techniquement possible de calculer l INS antérieurement à la création d un DMP, il est de bonne pratique de proposer la création du DMP uniquement en présence de la carte Vitale (juste après la lecture de celle-ci) ; ainsi : les actions de recueil du consentement et de lecture de la carte Vitale sont associées, l INS est calculé sur la base des données figurant dans la puce de la carte Vitale du patient au moment précis de la création du DMP (important car dans certains cas les données de la carte Vitale d un patient sont sujettes à modification correction d une erreur dans le prénom par exemple). ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

40 5 Exigences préalables à la DMP Compatibilité Vérification de l INS-C lorsqu il n a pas été calculé par le LPS Si l INS n est pas calculé dans le LPS à partir de la carte Vitale, il peut être enregistré dans le dossier du patient au statut «Fourni par un tiers, à vérifier» ou au statut ««Fourni par un tiers sûr». EX_GEN-1270 E Si l INS est au statut «Fourni par un tiers, à vérifier», il est indispensable de s assurer que cet INS correspond bien au patient avant toute action sur le DMP correspondant. Ce contrôle est effectué par le LPS qui doit respecter la séquence d actions suivantes : 1) Contrôler la clé de l INS (si clé invalide, l INS ne doit plus être utilisé) ; 2) Appeler de la transaction TD0.2 «Test d existence d un DMP et vérification de l autorisation» qui permet, si le DMP existe, de récupérer les traits d identité principaux du patient ; 3) Réaliser un contrôle d identito-vigilance tel que décrit au Le LPS doit stocker le fait que les contrôles ont été réalisés avec succès pour ne pas le refaire à chaque fois. Tant que l INS d un patient stocké en local n est pas associé à un DMP existant, le contrôle doit être considéré comme non effectué et le statut de l INS rester à «Fourni par un tiers, à vérifier». Cette règle s applique à tout LPS qui obtient l INS d un tiers, qu il soit repris automatiquement ou par copier/coller d un autre SI ou qu il soit saisie manuellement (lorsqu il a été fourni par une personne voir le patient lui-même) Si le patient a plusieurs INS-C L INS-C est calculé à partir de données qui ne sont pas censées évoluer (prénom, date de naissance et NIR de la personne). Mais il peut arriver qu elles évoluent (par exemple lorsqu un patient demande à corriger une erreur sur sa carte Vitale). Dans ce cas, l INS du patient calculé sur de nouveaux traits d identité sera différent. Dans le DMP, tout nouvel INS-C présenté est associé à un nouveau DMP (avec processus de création). Actuellement, le DMP ne gère pas la fusion des DMP d un même patient qui a eu plusieurs INS-C. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

41 5 Exigences préalables à la DMP Compatibilité EX_GEN-1290 E E Le LPS doit stocker tous les INS-C d un patient (créés suite à des modifications d informations dans sa carte Vitale) dans le même dossier. Une fenêtre de confirmation doit être implémentée pour prévenir les erreurs. Le LPS doit associer un statut à chaque INS-C : «en cours» pour le dernier INS-C calculé ; «obsolète» pour les anciens INS-C. Les INS-C «obsolètes» ne sont plus utilisés par les transactions d alimentation de DMP. EX_GEN-1300 Si un patient a plusieurs INS-C dans son dossier local patient, le LPS ne doit alimenter que le DMP du dernier INS-C calculé Procédure de référencement de logiciels pour le calcul de l INS-C E EX_GEN-1310 Les solutions calculant elles-mêmes l INS-C doivent être référencées INS-C auprès du CNDA. Les éditeurs de logiciels de professionnels de santé peuvent faire référencer leurs solutions depuis le 7 juin 2010 par le Centre National de Dépôt et d Agrément (CNDA) au profit de l ASIP Santé. Les informations relatives à cette procédure se trouvent à l adresse et sont gérées indépendamment de la procédure de DMP Compatibilité. De leur côté, les STS et les professionnels de santé peuvent aussi retrouver sur le site la liste des logiciels référencés intégrant le calcul de l INS-C. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

42 5 Exigences préalables à la DMP Compatibilité Identification des professionnels de santé E EX_GEN-1320 L accès au DMP nécessite l identification nominative des professionnels de santé telle que décrite ci-après (voir champ «Ps_idNat» au 5.4 de [CI-ANX-PS-STRU]). Chaque PS doit être identifié : en authentification directe : par son identifiant national présent dans sa carte CPS (N ADELI ou N RPPS) ou CPE ; en authentification indirecte : o o par son identifiant national de PS (N ADELI ou N RPPS) paramétré dans le LPS ; à défaut, par l'identifiant de structure + identifiant interne du PS dans la structure de santé, séparés par un «/». L identifiant doit être précédé d'un chiffre définissant le type d'identifiant utilisé : Construction des Identifiants des personnes dans le secteur de la Santé 0 + N ADELI 1 + Identifiant cabinet ADELI/identifiant interne 2 + N DRASS 3 + FINESS/identifiant interne 4 + SIREN/identifiant interne 5 + SIRET/identifiant interne 6 + identifiant cabinet RPPS/identifiant interne 8 + N RPPS 9 + N d étudiant Dans le tableau : Tableau 8 : Identifiant des personnes dans le secteur de la santé les noms en majuscule désignent la source d information (annuaires, bases ) de laquelle est tiré l identifiant ; le signe + indique une concaténation du type d'identifiant et de l identifiant sans séparation ; le signe / indique une concaténation des identifiants séparés par le signe / ; quel que soit l identifiant interne utilisé, celui-ci doit être unique au sein de l'organisation et permettre une relation univoque entre le PS et son identifiant ou une machine et son identifiant ; cet identifiant doit être traité comme un ensemble (comme une chaîne de caractères indissociable). Il ne doit pas être interprété par les applications (pour obtenir le numéro de SIRET par exemple) ni être éclaté en plusieurs champs ; D autres identifiants sont susceptibles d être utilisés dans le futur (ex : RMESS). Le document [CI-ANX-PS-STRU] fournit les règles de renseignement des données caractérisant les professionnels et structures de santé (source de données CPS ou gestion dans le LPS). ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

43 5 Exigences préalables à la DMP Compatibilité Identification des structures de santé E EX_GEN-1330 Pour un organisme de santé, l identifiant à utiliser est le numéro d identifiant de l'organisation précédé d'un chiffre définissant le type d'identifiant utilisé (voir champ «Struct_idNat» au 5.5 de [CI-ANX-PS-STRU]). L identifiant de l organisme est défini de la manière suivante : Identifiant de la structure 0 + Identifiant cabinet ADELI 1 + FINESS 2 + SIREN 3 + SIRET 4 + Identifiant cabinet RPPS Tableau 9 : Identifiant des structures Dans le tableau, le signe + indique une concaténation du type de l'identifiant et de l identifiant sans séparation. Le document [CI-ANX-PS-STRU] fournit les règles de renseignement des données caractérisant les professionnels et structures de santé (source de données CPS ou gestion dans le LPS) Autres normes et standards Les spécifications des interfaces avec le DMP s appuient également sur les normes ou standards suivants : XML : L ensemble des formats techniques d échange de données avec le DMP repose sur le métalangage de balisage générique XML. Le lecteur «profil 3» doit posséder les connaissances de base liées à ce format (parseurs, conformité, schémas, espaces de nommages, XPath ). CDA : voir les FAQ CDA-R2 (pour le profil alimentation/consultation) sur : SOAP TLS Signature électronique XML-DSig et XAdES : un rappel des principes de signature est proposé au ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

44 5 Exigences préalables à la DMP Compatibilité 5.2 Paramétrage du LPS OID racine unique par instance du LPS La production et la gestion de données dans le contexte DMP - comme tout échange de données de santé utilisant des standards internationaux tels que HL7 ou XDS - nécessitent la génération d identifiants universels (mondialement uniques) pour certains concepts (identifiant de patient local, identifiant de personne, de structure, identifiant unique de document, ). Les standards utilisent pour cela des identifiants d objets ISO (OID). Selon HL7 France : «Dans l arbre ISO (hiérarchie) des OID construits à partir d une racine, chaque organisation/objet est identifié par le nœud supérieur, et identifie à son tour les nœuds inférieurs. Un OID est une séquence de nombres entiers positifs séparés par des points (sans zéros non significatifs). Les OID sont alloués de manière hiérarchique de telle manière que seule l'autorité qui a délégation sur la hiérarchie "1.2.3" peut définir la signification de l'objet " ". Un OID est formé en concaténant à partir de la racine unique, les différents nœuds parcourus dans l arbre pour atteindre l objet identifié par cet OID. Chaque nœud possède un identifiant numérique. Le détenteur d une racine d OID (ex : 1.2.3) peut décliner autant de sous-branche qu il le souhaite, la longueur d un OID étant néanmoins limitée à 64 caractères. L AFNOR gère une branche d OID identifiée « ». Elle propose aux organisations françaises un service d attribution d OID sous cette branche. Des organisations autres que l AFNOR proposent ce service, comme DICOM, HL7- US» Par exemple, une organisation ayant commandé à l AFNOR un OID numérique (ex : 999) aura un OID racine E EX_GEN-1340 L éditeur doit disposer des racines d OID nécessaires avant de commencer les démarches de DMP Compatibilité. Unicité des identifiants d'objets générés par le LPS EX_GEN-1350 E Chaque identifiant généré doit être mondialement unique. A cette fin, l instance du LPS installé «chez le PS / dans la structure» doit posséder un OID racine qui lui est propre. La présente spécification n impose aucune règle de génération de cet OID racine (ni de la déclinaison de celui-ci), si ce n est qu il doit être unique par instance du LPS. Il appartient à l'éditeur de s assurer de la rigueur de sa méthode de génération d'identifiants uniques d'objets et du respect de l exigence. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

45 5 Exigences préalables à la DMP Compatibilité A titre d exemple, un identifiant unique d objet peut être obtenu : soit en utilisant une racine d OID propre à l éditeur du LPS, que celui-ci décline pour chaque LPS installé chez ses clients PS ; soit en utilisant l OID propre à une structure, si celle-ci en possède une (ex : un CHU peut déjà posséder un OID pour ses besoins internes) ; soit en générant une racine OID à partir d un UUID 128 bits hexadécimal converti en décimal sous la branche 2.25 dédiée à cet usage par l ITU ( T/asn1/uuid.html) ; exemple : Exemple possible d implémentation (cas n 1) : OID commandé par l éditeur «Editeur-lambda» auprès de l AFNOR : o OID du LPS «LPS-alpha» de l éditeur «Editeur-lambda» : OID de l instance du «LPS-alpha» de l «Editeur-lambda» installé dans le «Cabinet Dr Dupont» : OID des identifiants unique de document gérés au sein du LPS «LPSalpha» : o OID complet d un identifiant de document : OID des identifiants de patient locaux gérés au sein du LPS «LPS-alpha» : o OID complet d un identifiant patient local : Gestion des évolutions des Web Services Les services du DMP sont amenés à évoluer. A terme, plusieurs versions des Web Services peuvent coexister sur le DMP. Le principe général est le suivant : version courante et «officielle» des Web Services, installée en environnement de production ; version «-1» toujours opérationnelle en environnement de production pour les LPS qui n ont pas encore migré sur la version courante ; version «+1» pour la prochaine version (après la version courante), utilisable par les éditeurs les plus dynamiques ou bêta-testeurs en environnement de tests. Le numéro de version du Web Service DMP utilisé par le LPS est contrôlé par le DMP. Lors du passage à une nouvelle version, une notification est envoyée à l éditeur. La version «-1» devient obsolète et est retirée (elle ne fonctionne plus), la version courante devient la version «-1», et la version «+1» devient la version courante. A chaque version donnée des Web Services correspond une URL spécifique. L annexe «WSDL des services» reprend la liste de chaque service, fonction et URL (voir 11.3 «WSDL des services»). ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

46 5 Exigences préalables à la DMP Compatibilité Délai de migration du LPS vers les nouvelles versions des Web Services L ASIP Santé préviendra l éditeur ayant au moins une famille de produits homologuée du retrait d une version ancienne de Web Services au minimum six mois avant la date effective du retrait. Il est fortement recommandé à l éditeur de migrer rapidement vers la version courante des Web Services car le retrait d une version suite à la publication d une nouvelle version est irréversible et peut rendre les Web Services du LPS avec le DMP inopérants Nomenclatures et référentiels Le DMP utilise, pour le service de partage de documents médicaux, un certain nombre de nomenclatures qui doivent être facilement paramétrables et extensibles dans le LPS. EX_GEN-1360 E Compte tenu du caractère évolutif des nomenclatures, celles-ci ne doivent pas être codées «en dur» dans le LPS et il doit être possible d intégrer les nouvelles versions des nomenclatures sans devoir lancer une mise à jour ou recompilation de composants du LPS par l éditeur. A terme, la mise à disposition automatique des nomenclatures du CI-SIS est envisagée sur le RNR (Répertoire National des Référentiels) Cadre d exercice, Secteur d activité, Profession / Spécialité Cadre d exercice Le cadre d exercice décrit le contexte d utilisation du LPS et peut être paramétré de manière fixe dans le LPS ou déduit du contexte d usage du LPS. Il ne peut pas être déduit de la carte CPS. Les valeurs possibles du cadre d exercice sont celles du jeu de valeurs «practicesettingcode» (voir [CI-ANX-PS-STRU] et [CI-JEUX-VALEURS]). Exemples : Ambulatoire, Dépistage, Maintien à domicile, Soins à domicile, Hospitalisation à domicile, Etablissement de santé, Soins palliatifs, SAMU/SMUR Le cadre d exercice est renseigné dans : la métadonnée XDS «PracticeSettingCode» la donnée de l entête des documents CDA : «documentationof/serviceevent/performer/assignedentity/representedorganization/s tandardindustryclasscode» ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

47 5 Exigences préalables à la DMP Compatibilité Secteur d activité Lorsqu un PS exerce dans plusieurs secteurs d activité, ceux-ci correspondent généralement à des lieux d exercice différents, équipés de LPS différents. A l inverse, pour un lieu d exercice donné, le secteur d activité sera souvent unique. Un PS travaillant dans le secteur de l assurance (secteur d activité SA23 - Assurances Privées) ne peut pas accéder au DMP. Il peut cependant travailler dans d autres secteurs d activités pour lesquelles l accès au DMP est autorisé (Cabinet individuel par exemple). Il est donc essentiel de définir correctement le secteur d activité dans lequel le PS intervient. Le secteur d activité est déduit : de la CPS en authentification directe : o si le PS a une seule situation d exercice dans sa CPS, prendre le secteur d activité de cette situation. o si le PS a plusieurs situation d exercice dans sa CPS, prendre le secteur d activité de la situation sélectionnée par le PS. du LPS en authentification indirecte (dans ce cas, le secteur d activité est paramétré à l avance). EX_GEN-1370 E E E En authentification directe, le LPS doit permettre aux PS qui possèdent plusieurs situations d exercice dans leur carte CPS de choisir, à la première lecture de la carte CPS ou à la connexion au DMP, la situation d exercice qu il souhaite utiliser pour se connecter au DMP (même si en pratique un LPS sera quasi-systématiquement associé à une seule situation d exercice). EX_GEN-1375 En authentification indirecte, il est nécessaire d assurer la cohérence entre le secteur d activité paramétré dans le LPS et celui connu dans les référentiels nationaux des structures de santé. EX_GEN-1377 Il est nécessaire d assurer la cohérence entre le secteur d activité et le cadre d exercice. Par exemple, on pourra associer un secteur d activité «cabinet individuel» à un cadre d exercice «Ambulatoire» et pas à un cadre d exercice «établissement de santé». Les valeurs possibles du secteur d activité sont celles du jeu de valeurs «healthcarefacilitytypecode» (voir [CI-ANX-PS-STRU] et [CI-JEUX-VALEURS]). Exemples : Etablissement Public de santé, Hôpital militaire du Service de Santé des Armées, Etablissement Privé PSPH, Cabinet individuel, Cabinet de groupe, ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

48 5 Exigences préalables à la DMP Compatibilité Si le secteur d activité est un code de la nomenclature ADELI, il est nécessaire de réaliser, pour les transactions DMP, un transcodage vers un code de la nomenclature RPPS (voir [CI- ANX-PS-STRU]). Le secteur d activité est renseigné dans : les métadonnées XDS : «HealthcareFacilityTypeCode» l entête CDA d un document : «componentof/encompassingencounter/location/healthcarefacility/code» le VIHF : Secteur_Activité Profession / spécialité de l utilisateur Un PS du travail (spécialité SM25 ou SCH35) ne peut pas accéder au DMP. La profession et la spécialité sont déduites : de la CPS en authentification directe du LPS en authentification indirecte (dans ce cas, la profession et la spécialité peuvent être paramétrés à l avance). Si la spécialité du PS est un code de la nomenclature ADELI, il est nécessaire de réaliser, pour les transactions DMP, un transcodage vers un code de la nomenclature RPPS (voir [CI- ANX-PS-STRU]). La spécialité du PS est renseignée dans : les métadonnées XDS : «authorspecialty» l entête CDA d un document : «assignedauthor/code» le VIHF : urn:oasis:names:tc:xacml:2.0:subject:role ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

49 5 Exigences préalables à la DMP Compatibilité 5.3 Configuration poste de travail / serveur Connexion internet L utilisation du DMP par un PS nécessite une connexion à internet entre le LPS et le DMP. Cet accès ne s effectue pas nécessairement entre le poste de travail du PS et le DMP (cas d un LPS avec une architecture client/serveur en STS par exemple). Par contre, dès lors que le poste de travail doit accéder au DMP par le LPS ou par le navigateur, ce poste de travail doit disposer d une connexion internet. Dans le cas où l accès à internet est conditionné par la connexion préalable à un dispositif de restriction et/ou de sécurisation de cet accès (firewall, proxy), ce dispositif devra être en capacité de laisser passer les flux HTTP/TLS du DMP (ouverture éventuelle de l accès aux URL du DMP, port TLS, etc.). Pour une utilisation normale du DMP, une ligne internet haut débit est nécessaire Accès Web-PS E EX_GEN-1380 Pour les LPS implémentant la transaction TD0.9 «Accès Web-PS contextuel», le poste de travail doit être équipé d un des navigateurs compatibles avec les IHM Web-PS du DMP (voir annexe [DMP1-OS-NAVIGATEURS]). Création du DMP via l Accès Web PS Dans le cas où le LPS n implémente pas la transaction TD1.1 «Création de DMP», mais que le poste de travail dispose d un lecteur de cartes opérationnel et que l accueil du patient s effectue à l aide de ce poste de travail, la création peut s effectuer sur l accès Web du DMP. La lecture de la carte Vitale est dans ce cas réalisée par une applet intégrée à l Accès Web. Pour fonctionner, cette applet nécessite un certain nombre de composants qui peuvent être installés en utilisant l ODI (Outil de Diagnostic et d Installation) du service DMP disponible à l adresse suivante : Cet outil se charge d analyser les composants déjà présents sur le poste et le cas échéant installe d autres composants nécessaires. Un guide d utilisation et une FAQ sont disponibles sur la page d accueil de cet outil. E EX_GEN-1390 La configuration du poste de travail pour l AW-PS ne doit pas perturber le mode de fonctionnement du LPS et la configuration du poste de travail pour le LPS ne doit pas perturber le mode de fonctionnement de l AW-PS. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

50 5 Exigences préalables à la DMP Compatibilité Lecteur de cartes (matériel) Pour les LPS nécessitant un dispositif de lecture de la carte Vitale, le poste doit être équipé : d un lecteur homologué SESAM-Vitale dans un des référentiels suivants : Lecture Vitale, Terminal Lecteur, Dispositif intégré ; ou d un (ou deux) lecteur(s) PC/SC (en STS en général) : o o un lecteur si le LPS ne lit pas la carte CPS (carte vitale seule), deux lecteurs en parallèle si le LPS lit la carte CPS et la carte Vitale Dispositifs de lecture des cartes Vitale (logiciel) EX_GEN-1400 E La lecture de la carte Vitale est un prérequis pour le profil «Création» car lors de la création du DMP du patient, la transaction DMP utilise l INS-C (calculé à partir des informations lues sur la carte Vitale. Voir «Identification du patient par son INS») et d autres traits d identité du patient (également lus sur la carte Vitale) Lecture des cartes Vitale EX_GEN-1410 E L accès et la lecture des cartes Vitale doit se faire via une API fournie par le GIE Sesam- Vitale ; le LPS doit donc être : 1. soit un logiciel de facturation agréé SESAM-Vitale (CDC 1.4 a minima) ; 2. soit une solution intégrée homologuée SESAM-Vitale (Référentiel V2.10 a minima) ; 3. soit un logiciel référencé comme intégrant le composant API de Lecture Vitale en vigueur (v.6.03 lors de la publication du présent document). Les dispositions précédentes sont compatibles avec le calcul de l INS-C défini au «Calcul de l INS-C». REC_GEN-1420 R Il est recommandé à l éditeur qui souhaite intégrer pour la première fois la lecture de la carte vitale dans son LPS d utiliser la dernière version des API de lecture Vitale. Les informations sur les API de lecture de carte Vitale sont disponibles sur le site du GIE Sesam-Vitale : ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

51 5 Exigences préalables à la DMP Compatibilité EX_GEN-1430 E Les cartes Vitale de test (cartes de couleur blanche dédiées aux tests éditeurs) ou de démonstration (cartes de couleur verte avec "démonstration" indiqué en diagonale) ne doivent pas être utilisées sur l'environnement DMP de production. Les LPS doivent contrôler le type de carte Vitale remonté par l API exploitation de la carte Vitale (API de lecture ou API FSE) et bloquer l accès à l environnement DMP de production pour ces types de cartes Cas pour lesquels la lecture de la carte Vitale n'est pas nécessaire Pour les autres profils (lorsqu il n y a pas «création du DMP»), la lecture de la carte Vitale n est pas nécessaire pour le DMP. Cela correspond au cas d usages suivants : lorsque le LPS n est pas adapté à la création de DMP et est en mesure de récupérer l'ins par d'autres moyens que la lecture de la carte Vitale ; lorsque le patient n est pas présent. C est en particulier le cas dans : o o o les centres de réception et de régulation des appels (Centres 15) : les médecins régulateurs accèdent au DMP du patient via une fonction spécifique du LDRM (Recherche de DMP sans l INS du patient) ; les plateaux techniques (RIS, SGL) : l INS du patient peut être transmis au PS par une voie alternative (flux informatique, courrier, étiquette, code à barre ). Note : Les PS qui ne voient pas directement le patient, mais travaillent sur des prélèvements (SGL de biologie et d'anatomopathologie) ne sont a priori pas ceux qui ouvriront un DMP ; les SIH pour toute application qui ne créé pas le DMP du patient (c'est-à-dire toutes les applications SIH sauf les GAM). L INS du patient est transmis à l application via des flux informatiques (ex : profil IHE PAM extension Française, voir document [IHE-PAM-FR]). ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

52 5 Exigences préalables à la DMP Compatibilité Dispositifs pour l authentification des utilisateurs En authentification directe (carte CPS/CPF/CPE) Dans le cas d une configuration en authentification directe, le poste de travail nécessite un dispositif de lecture de carte CPS. Dans le document de référence [CI-TR-CLI-LRD], le «Configuration authentification directe» spécifie les composants à utiliser pour la lecture des cartes CPS. L ASIP Santé fournit un middleware permettant de lire ces cartes (librairies cryptographiques «CryptoLib» et API CPS version 5.04 ou ultérieure) ; voir à ce titre l annexe [DMP1-OS- NAVIGATEURS] En authentification indirecte (certificat serveur applicatif) E EX_GEN-1450 En authentification indirecte, un certificat logiciel d authentification pour personne morale de la STS dont les utilisateurs dépendent est utilisé L espace Intégrateur CPS de l ASIP Santé Lors de la mise au point du LPS, il est nécessaire : D utiliser des cartes CPS/CPF/CPE ou des certificats de tests que vous pouvez obtenir auprès de l ASIP Santé ; D intégrer éventuellement au déploiement du LPS des middlewares de lecture de carte CPS (dans le cadre de l authentification directe). Un espace dédié ayant pour objectif de mettre à disposition des éditeurs, industriels et promoteurs d'applications les éléments techniques nécessaires à l'intégration du système CPS dans leurs applications est disponible à l adresse suivante : Pour information : Pour obtenir les bibliothèques des API-CPS de l ASIP Santé, vous devez signer avec l ASIP Santé, un «contrat de diffusion des logiciels API-CPS (éditeurs)» et commander un kit CPS de référence. Pour cela : Téléchargez : o le Contrat éditeurs (attention ce contrat est différent du Contrat Editeur signé pour la DMP Compatibilité), o le Bon de commande kit CPS. Adressez ensuite par courrier à ASIP Santé / Service Editeurs, 9 rue Georges Pitard PARIS : o 2 exemplaires complétés et signés du «Contrat de diffusion des logiciels API- CPS», accompagnés de l'annexe 3 remplie, o le «Bon de commande kit CPS» complété et signé, o le règlement de la commande. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

53 5 Exigences préalables à la DMP Compatibilité L ASIP Santé : 1) vous retourne par courrier un exemplaire du «Contrat de diffusion des logiciels API- CPS (éditeurs)» signé par les deux parties, 2) vous envoie un courrier recommandé ou un mail (au(x) correspondant(s) désigné(s) sur le bon de commande) : un identifiant/mot de passe qui donne un accès aux services contrôlés du serveur et permet plus spécifiquement de télécharger les bibliothèques d'api-cps ainsi que les documents d'aide à l'intégration des services CPS ; vous pourrez ainsi télécharger les diverses bibliothèques d'api-cps dans les environnements d'exploitation que vous désirez intégrer et obtenir leurs versions successives ; les évolutions du système CPS vous seront régulièrement communiquées, 3) vous livre le(s) matériel(s) correspondant(s) à votre commande (jeu de cartes de test, dispositif de lecture). A réception des matériels et des API-CPS, vous retournerez à l ASIP Santé / Service Editeurs le procès-verbal de remise du kit CPS. Attention : les certificats serveurs de tests sont liés à une carte CPA de test que vous devez également commander auprès de l ASIP Santé Synchronisation du temps EX_GEN-1460 E Quel que soit le profil DMP choisi, le poste de travail (ou le «composant logiciel» communicant avec le DMP s il ne s agit pas directement du poste de travail du PS) doit être en capacité de synchroniser son heure, pour des problématiques d horodatage des données médicales, de traçabilité et de pertinence de certains critères de recherche concernant la date. Un délai trop long entre deux synchronisations (par exemple 1 fois par semaine) peut se révéler insuffisant dans la mesure où un décalage de plus de 3 secondes est rejeté par le DMP (erreur SOAP:Fault contenant le message d'erreur du SI DMP). La synchronisation de temps doit se faire suivant la transaction IHE «Maintain Time» du profil IHE «Consistent Time» (CT : [IHE-TF1] et [IHE-TF2A] 3.1). Pour information, ce profil utilise le protocole NTP. L éditeur peut par exemple utiliser le pool de serveurs de temps français 1 «fr.pool.ntp.org». 1 L éditeur qui souhaiterait utiliser ce pool de serveurs de temps est invité à se rapprocher du fournisseur du service pour en connaître les conditions d utilisation et les engagements en termes de niveaux de services. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

54 5 Exigences préalables à la DMP Compatibilité Impression E EX_GEN-1470 Le «document des secrets du patient» doit pouvoir être imprimé et remis ou envoyé au patient pour lui permettre d accéder à son DMP (INS, identifiant et mot de passe). Un LPS implémentant la transaction TD1.5 doit donc être en capacité de lancer des impressions. Les modalités de mise en œuvre de la transaction TD1.5 (récupération du modèle de document à utiliser et impression du document) sont décrites au 8.6. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

55 6 Exemples d intégration du DMP dans les LPS 6 Exemples d intégration du DMP dans les LPS La mise en œuvre du DMP dépend du métier géré par le LPS. Les besoins d un Logiciel de cabinet (LGC) ne sont pas les mêmes que ceux d un Système d Information de Radiologie (SIR) ou de la Gestion Administrative des Malades (GAM) d une structure de soins. Architectures systèmes éligibles aux échanges avec le DMP L ASIP Santé a publié le document [ARCHI-DMP] «Architectures systèmes éligibles aux échanges avec le DMP» qui présente différents axes possibles d implémentations architecturales, correspondant à des existants ou des besoins terrain différents, mais restant conformes aux exigences de DMP Compatibilité. Ce document de recommandation n est pas limitatif, n a pas de vocation normative et pourra être enrichi. Exemples d intégration du DMP dans les LPS Dans ce chapitre, des exemples d intégration du DMP dans les LPS sont présentés : Exemple DMP Minimal : Intégration de l accès web PS contextuel Exemple d un LPS en authentification directe (cas typique du LGC) o 2 exemples : LGC avec calcul de l INS et LGC sans calcul de l INS Exemple d un LPS en authentification indirecte (cas typique du SIH) o 2 exemples : SIH «intégré» et SIH «réparti» Note : Les exemples présentés dans ce chapitre ne représentent pas l exhaustivité des solutions d intégration possibles. Pour plus de détail, il convient de se reporter à la description détaillée des transactions. En supplément et pour information, le 6.6 présente : Exemple de l AW PS non intégré au LPS. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

56 6 Exemples d intégration du DMP dans les LPS 6.1 Exemple DMP minimal : intégration de l AW- PS contextuel Cet exemple d intégration minimale du DMP ne nécessite pas de passage en processus d homologation de la DMP Compatibilité Le cas de l intégration minimale du DMP correspond à l intégration de la seule transaction TD0.9 «Accès Web-PS contextuel» (pour plus de détail voir la description de la transaction TD0.9 au 7.8). L authentification directe par carte CPx, obligatoire, est alors réalisée par l Accès Web PS. Le code porteur de la CPS est demandé à chaque ouverture du navigateur (la première fois ou les fois suivantes s il a été fermé entre temps). Cette transaction permet ensuite d accéder au tableau de bord du professionnel de santé (appel contextuel sans INS) ou directement au DMP du patient (appel contextuel avec INS). Lors de l accès contextuel au DMP du patient avec son INS : Si l accord du PS n a pas encore été donné, la page de déclaration / confirmation de l accord du patient est présentée. Si le DMP du patient correspondant à l INS n existe pas, la page permettant d accéder à la lecture de la carte Vitale (puis au calcul de l INS) est présentée avant d enchainer ensuite vers les pages de création du DMP. Si le DMP du patient existe, mais est fermé, la page procédant à la proposition de réactivation du DMP est présentée à condition que le motif de fermeture soit «à la demande du patient». Fig. 10 : Exemple DMP minimal : intégration de l AW-PS contextuel Pour créer un DMP, il faut lire la carte Vitale et calculer l INS à partir du navigateur. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

57 6 Exemples d intégration du DMP dans les LPS 6.2 Exemple d un LPS en authentification directe (cas typique du LGC) Exemple avec calcul de l INS dans le LPS L INS est calculé par le LPS. L authentification est directe par CPx. Fig. 11 : Exemple d un LPS authentification directe avec calcul de l INS dans le LPS Configuration du poste de travail requise : - Lecteur de carte CPS pour authentification / signature - Lecteur de carte Vitale pour calcul de l INS - API CPS installés, opérationnels et conformes - API Vitale pour le calcul de l INS - Java Virtual Machine (JVM) selon niveau d intégration (si signature par AW-PS) ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

58 6 Exemples d intégration du DMP dans les LPS Exemple sans calcul de l INS dans le LPS Certains professionnels ne rencontrent pas directement le patient ou n ont pas accès à la carte Vitale et ne peuvent donc ni calculer l INS, ni recueillir le consentement du patient (ex : laboratoire d anatomopathologie). Dans ce cas, l INS est récupéré auprès d un tiers (un SI ou une personne). Le cas des LPS en STS et recevant l INS par le biais des flux IHE PAM HL7-ADT est évoqué au chapitre «Exemple de type SIH réparti». L authentification est directe par CPx. Fig. 12 : Exemple d un LPS en authentification directe sans calcul de l INS dans le LPS Configuration du poste de travail requise : - Lecteur de carte CPS pour authentification / signature - API CPS installés, opérationnels et conformes - Java Virtual Machine (JVM) selon niveau d intégration (si signature par AW-PS) ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

59 6 Exemples d intégration du DMP dans les LPS 6.3 Exemple d un LPS en authentification indirecte (cas typique du SIH) Ces exemples s appliquent de façon générale aux structures utilisant un certificat logiciel d authentification pour personne morale. Note : Il est tout à fait possible pour une structure de soins (STS) de n utiliser que des CPx pour ses transactions Exemple de type SIH «intégré» L exemple présenté est celui d un SIH (Système d Information Hospitalier) avec : les transactions de création et d alimentation du DMP en authentification indirecte (utilisation du certificat logiciel pour personne morale de la STS). la consultation du DMP en mode Web-PS qui requiert une authentification par CPx. Fig. 13 : Exemple de type SIH «intégré» Configuration du poste de travail requise (elle est variable selon l action à effectuer) : - Certificat logiciel pour personne morale placé sur un serveur (pour l authentification indirecte) pour toutes les transactions DMP du LPS, - Lecteur de carte Vitale et API Vitale pour calcul de l INS pour la création du DMP, - pour les postes utilisant l accès Web-PS (ici utilisé pour la consultation) : lecteur CPS et modules cryptographiques CPS de l ASIP Santé, et JVM selon les besoins de signature des transactions réalisées (signature par applet DMP), - l alimentation peut être réalisée par un serveur local, sans impact sur le poste de travail. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

60 6 Exemples d intégration du DMP dans les LPS Exemple de type SIH «réparti» L exemple suivant représente un SIH composé de trois LPS distincts : une GAM gérant les admissions des patients, qui fait la création des DMP et distribue les identités des patients (dont l INS) aux autres parties du système (Production et DPI) via les flux HL7-ADT (IHE-PAM) ; un outil de production qui alimente le DMP ; un dossier patient partagé (DPI) qui traite de la consultation. Chaque LPS du SIH utilise donc un profil DMP différent. Fig. 14 : Exemple de type SIH «réparti» Configuration du poste de travail requise (elle est variable selon le poste) : - Certificat logiciel pour personne morale placé sur un serveur (pour l authentification indirecte) pour les transactions création et alimentation DMP du LPS, - Lecteur de carte Vitale et API Vitale pour calcul de l INS pour la création du DMP dans la GAM, - lecteur CPS et API CPS pour le DPI. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

61 6 Exemples d intégration du DMP dans les LPS IHE PAM-fr et DMP Le profil IHE-PAM extension française [IHE-PAM-FR] prévoit la présence de l INS dans ces flux (champ PID-3). R REC_GEN-1510 Le calcul systématique de l INS à partir de la carte Vitale est une bonne pratique pour tout Système d Information de Santé (et pour tout LPS en général). Cela permet de disposer d un réel identifiant de partage. Alors que la création d un DMP requiert l INS, le calcul et le stockage de l INS n imposent pas la création ni l existence d un DMP. Le flux PAM ne présente actuellement que l information INS. Or il est possible qu un patient dispose d un INS sans disposer de DMP. Par ailleurs, le flux PAM ne transporte pas la notion d autorisation d accès donnée par le patient à la structure de soins (autorisation pour une STS en authentification indirecte : limitée à l alimentation). Cette notion ne peut être fournie par la GAM que dans le cas où le DMP est créé par celle-ci ou si le test d existence est intégré systématiquement lors de l accueil du patient dans la STS. Le LPS de production dispose donc de l information INS, mais pas de celle lui permettant de savoir s il peut alimenter l éventuel DMP rattaché à cet INS. REC_GEN-1520 R Pour pallier cette difficulté, il existe plusieurs possibilités pour vérifier si un INS est rattaché à un DMP : appeler la transaction TD0.2 «Test d existence du DMP et vérification de l autorisation» pour tester un INS en particulier (par exemple lors de l enregistrement d un nouvel INS dans le SIH). Ce test d existence permet également de lire le statut de l autorisation éventuelle d accès de la STS sur le DMP du patient. Mais si la STS dispose d un «stock» important d INS sans statut, il n est pas envisageable de balayer incessamment ces INS pour appeler la transaction TD0.2 ; utiliser la transaction TD0.4 «Liste des dossiers autorisés» dans un processus automatique et planifié (ex : tous les 3 jours). Cette transaction permet de récupérer la liste des INS des DMP pour lesquels l acteur de santé (ici la STS) a été autorisé depuis une date donnée (ex : il y a 3 jours). Si le SIH dispose d un INS de cette liste, il peut alors stocker en regard de l INS un statut «DMP existe et STS autorisée» ; certains SIH sont en mesure de distribuer la notion d existence du DMP et celle de l autorisation, par exemple à l aide d un logiciel de type Enterprise Application Integration (EAI). ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

62 6 Exemples d intégration du DMP dans les LPS 6.4 Cas des «Connecteurs / EAI» Les LPS de type «Connecteur» (ou EAI, module ou solution «externe») permettent à un ou plusieurs autres «LPS tiers» d échanger, de collecter ou de concentrer des données, puis de s interfacer avec le SI DMP afin de créer, alimenter, voire consulter le DMP. Ces composants logiciels interviennent le plus souvent dans les structures de soins (STS) pour pallier les problèmes d interopérabilité liés à l hétérogénéité des applications existantes. Avertissement : du point de vue de l ASIP Santé, sont considérés comme «connecteur / EAI» les solutions logicielles commercialisées en tant que telles, et non les modules techniques utilisés en interne par un éditeur pour ses propres solutions. LPS tiers LPS tiers LPS tiers Connecteur SI DMP Fig. 15 : Schéma fonctionnel du connecteur De par leur positionnement en terme de mise en œuvre, ces «connecteurs / EAI» sont admissibles à l homologation à la DMP Compatibilité, moyennant certains aménagements en terme de prise en compte des exigences de DMP Compatibilité. En effet, ces logiciels n étant pas directement en contact avec l utilisateur final, certaines exigences peuvent (ou doivent) être déléguées contractuellement au «LPS tiers». La liste des exigences de DMP Compatibilité pouvant ou devant être déléguées est fournie dans l annexe [PDV-HOMOLOGATION]. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

63 6 Exemples d intégration du DMP dans les LPS 6.5 Cas des logiciels en mode SaaS L utilisation d un logiciel en mode SaaS suppose un accès distant de l utilisateur final audit logiciel et aux données de santé à caractère personnel gérées par ce logiciel. Les données de santé à caractère personnel recueillies ou produites par l utilisateur final du logiciel se retrouvent ainsi hébergées chez un tiers. L article L du code de la santé publique dispose que «les professionnels de santé ou les établissements de santé ou la personne concernée peuvent déposer des données de santé à caractère personnel, recueillies ou produites à l'occasion des activités de prévention, de diagnostic ou de soins, auprès de personnes physiques ou morales agréées à cet effet. Cet hébergement de données, quel qu'en soit le support, papier ou informatique, ne peut avoir lieu qu'avec le consentement exprès de la personne concernée». Les conditions d hébergement de données de santé à caractère personnel sur support informatique ont été précisées par le décret du 4 janvier 2006 relatif à l hébergement de données de santé à caractère personnel (codifié aux articles R à R du code de la santé publique). Ainsi, conformément à l article L du code de la santé publique et au décret du 4 janvier 2006, toute personne physique ou morale hébergeant des données de santé à caractère personnel recueillies à l occasion d activités de prévention, de diagnostic ou de soins pour le compte d un tiers, doit être agréée par décision du ministre en charge de la santé qui se prononce après avis de la CNIL et d un comité d agrément (organe consultatif crée par le décret sus-cité). L alternative suivante s offre à l éditeur de logiciels en mode SaaS pour l hébergement des données de santé à caractère personnel : Etre soi-même agréé pour l hébergement de données de santé à caractère personnel ; Confier l hébergement des données de santé à caractère personnel à un hébergeur agréé à cet effet. Il convient de rappeler que des contrôles diligentés par la CNIL ou par l IGAS peuvent être conduits pour s assurer du respect des conditions de l agrément et que le non-respect de l obligation d agrément est assorti de sanctions pénales. L ensemble des informations relatives à la procédure d agrément ainsi que la liste des hébergeurs agréés sur le site esante.gouv.fr. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

64 6 Exemples d intégration du DMP dans les LPS 6.6 Exemple de l AW-PS non intégré au LPS L Accès Web-PS n est accessible qu en authentification directe (CPx requise). Le poste de travail doit être en mesure d utiliser l AW-PS via le navigateur. En particulier, cela est indispensable si les utilisateurs du LPS ont besoin de fonctions du DMP accessibles uniquement en mode Web-PS ou si ces fonctions du DMP ne sont pas intégrées au LPS. La figure ci-dessous montre la configuration d un poste de travail pour l Accès Web-PS à un «niveau d intégration zéro» où toute action DMP s effectue en dehors du LPS. Fig. 16 : Exemple de l AW-PS non intégré au LPS Configuration du poste de travail requise : - Lecteur de carte CPS pour authentification / signature - Lecteur de carte Vitale pour calcul de l INS - Modules cryptographiques CPS Cryptolib comprenant le PKCS11 et le CSP (Windows) installés, opérationnels et compatibles avec le navigateur internet utilisé - API Vitale pour le calcul de l INS - Applet (pour signature et calcul de l INS) déployée automatiquement - Java Virtual Machine (JVM) - S il existe une autre application CV/CPS sur le poste (LPS), elle doit être installée conformément aux recommandations ASIP et GIE-SESAM-Vitale. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

65 7 Accès sécurisé au DMP 7 Accès sécurisé au DMP Ce chapitre décrit les dispositions de sécurité à assurer pour la mise en œuvre des interfaces externes du DMP. Il aborde également la gestion des autorisations et modalités d accès au DMP. 7.1 Exigences générales de sécurité EX_0.X-1010 E Le LPS doit se conformer aux exigences de transports et de sécurisation des flux, visant à assurer l intégrité, la confidentialité et l imputabilité du contenu de chaque DMP, exprimés dans le document [CI-TR-CLI-LRD]. La mise en œuvre de la sécurité doit se conformer à l ensemble des dispositions de sécurité des volets du CI-SIS implémentés par la présente spécification Connexion au DMP E EX_0.X-1020 La connexion au DMP depuis un LPS est assurée par l établissement d un canal TLS avec authentification mutuelle entre le LPS et le serveur DMP. REC_0.X-1030 R Le DMP supporte les versions TLS 1.0 et supérieures. Il est cependant recommandé aux éditeurs d utiliser les librairies supportant le TLS 1.2 (et qui supportent également les versions antérieures). Ainsi, même si le TLS 1.2 n est pas utilisé actuellement par les principaux navigateurs du marché, les logiciels supporteront les évolutions prochaines. Les suites suivantes sont supportées a minima par le serveur DMP (compatibles avec les clés CPS (RSA1024 et RSA2048 bits avec SHA1) et la majorité des navigateurs) : TLS_DHE_RSA_WITH_AES_256_CBC_SHA ; TLS_DHE_RSA_WITH_AES_128_CBC_SHA ; TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. Les algorithmes et tailles de clés utilisés sont : RSA bits pour la cryptographie asymétrique ; AES ou 3DES avec une taille de clé entre 128 et 256 bits pour la cryptographie symétrique ; utilisation de la fonction de condensat SHA1. A moyen terme, en fonction de l évolution des supports cryptographiques diffusés chez les PS, des clés asymétriques de 2048 bits et symétriques AES 256 leur seront préférées, avec un algorithme de hash SHA256. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

66 7 Accès sécurisé au DMP Comptes à rebours timer d inactivité et timer de renégociation Le SI-DMP met en œuvre deux comptes à rebours (timer) sur le système de gestion des connexions sécurisées TLS. Ces deux timers démarrent lors de la connexion et sont remis à zéro selon des critères qui leur sont propres, définis ci-dessous : le premier, appelé «timer d inactivité», provoque une coupure de la connexion TLS et du socket TCP/IP courant lorsqu il arrive à son terme. Ce timer permet au SI-DMP de désallouer les ressources systèmes bloquées par une connexion inactive. Ce timer est remis à zéro à chaque fois que l utilisateur connecté envoie une commande (via HTTP) au SI-DMP sur le socket courant ; le second, appelé «timer de renégociation», permet de contrôler régulièrement la présence de la modalité d authentification cliente (carte CPX ou certificat serveur) et vient en complément du contrôle d arrachage de la modalité qui doit être effectué coté client (opération décrite ci-après). Lorsqu il arrive à son terme, il bloque l exécution des commandes sur le SI-DMP et conditionne leur déblocage à l exécution d une opération de renégociation TLS. 8h 9h 10h 11h Timer de renégociation : toutes les heures Oblige à une renégociation du TLS et donc à un test de présence de la carte, à l arrivée de la demande suivante T0 T1 T2 T3 T4 Activité PS Inacti vité Activité PS La demande arrive à T2 après le timer de renégociation, un test de présence de la carte est déclenché à sa réception Inactivité Timer d inactivité 1h coupure de la socket Fig. 17 : Timer de renégociation et timer d inactivité Coupure de la socket après 1h d inactivité (T4-T3=1h) Aucune renégociation ne sera lancée, le timer d inactivité ayant coupé la socket A ce stade il est important de noter qu il existe un timer d inactivité par socket TCP/IP et un unique timer de renégociation pour tous les sockets TCP/IP ouverts par un même client (via la notion de session TLS). Le DMP met en œuvre ces deux timers sur un compte à rebours d une heure : une heure depuis la dernière activité sur le socket courant pour le timer d inactivité et une heure depuis la première connexion ou la dernière renégociation pour le timer de renégociation. Ces deux valeurs ont été choisies pour offrir le meilleur compromis performance/sécurité pour l utilisateur. En prenant par exemple pour hypothèse qu une consultation dure en moyenne 20 minutes : pour le timer d inactivité, cela permet de couper les connexions qui sont restées inutilisées alors que deux ou trois patients ont consulté le PS sans que celui-ci n utilise le DMP. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

67 7 Accès sécurisé au DMP R REC_0.X-1035 Le LPS doit gérer correctement la coupure du canal TLS par le SI DMP (timer d'inactivité et timer de renégociation du canal TLS). Détection de l arrachage de la carte CPS EX_0.X-1040 E Les LPS supportant l authentification directe doivent mettre en œuvre un protocole de détection de l arrachage de la modalité d authentification (carte CPS/CPF/CPE), qui le cas échéant déconnectera l utilisateur du SI DMP (en invalidant sa session TLS et en coupant ses sockets TCP/IP par exemple ou, à discrétion, en bloquant le logiciel ou en le fermant). La fonction de détection de l arrachage de carte s assure que la carte CPS/CPF/CPE de l utilisateur authentifié est toujours dans le lecteur de carte lors des demandes de transactions avec le SI DMP. Des préconisations techniques et des exemples d implémentation sont disponibles dans le document [GUIDE-ARR-CPS] disponible dans l espace Intégrateur CPS de l ASIP Santé. REC_0.X-1050 R Pour les LPS supportant l authentification directe, il est recommandé que le LPS vérifie la date de fin de validité de la carte CPS lors du premier accès à la carte CPS pour la session courante de l'utilisateur. En effet, le SI DMP refuse la négociation TLS avec une carte CPS ayant expiré. Note : Le SI DMP refuse également la négociation TLS avec une carte CPS révoquée (cas plus rare). E EX_0.X-1060 Un jeton SAML 2.0 (nommé VIHF, «Vecteur d Identification et d Habilitation Formelles», voir «Le VIHF») doit par ailleurs transiter dans les messages. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

68 7 Accès sécurisé au DMP Vérification du certificat serveur du SI DMP Le certificat serveur des interfaces LPS du SI DMP est émis par l IGC-CPS. Validation du certificat serveur du SI DMP E EX_0.X-1070 Le LPS doit être en capacité de valider le certificat serveur du SI DMP (pour les interfaces LPS) selon la norme PKIX (voir RFC3280 sur et RFC5280 sur R REC_0.X-1090 Il est recommandé de faire également un contrôle de révocation des certificats serveurs du SI DMP. Certificat racine (AC) et listes de révocations des certificats (CRL) Le certificat utilisé par le SI-DMP est un fils de l'ac nommée "AC-classe-4" elle-même fille de l'ac "GIP-CPS". Les ressources liées à ces deux AC sont donc nécessaires pour valider le certificat du SI-DMP. Les informations et ressources (fichiers) sur les Autorités de Certification (AC) et les CRLs "CPS" sont disponibles sur le site dans les onglets «Autorités de Certification» et «CRL». L'autorité de certification "GIP-CPS" ne dispose pas encore d'un service OCSP (Online Certificate Status Protocol). Par conséquent, les CRLs doivent être téléchargées explicitement par le LPS (éventuellement par tâche planifiée : les CRLs GIP-CPS sont mises à jours en totalité une fois par jour mais des deltas CRLs existent également), puis utilisées de manière programmatique lors de la validation (en général en installant ou passant en paramètre les CRLs dans le composant technique de validation de certificat). Il est recommandé de prendre connaissance du guide de bonnes pratiques d utilisation des CRL (voir [GUIDE-CRL]). ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

69 7 Accès sécurisé au DMP R REC_0.X-1100 Pour assurer la sécurité des applications intégrant des certificats d'ac il est recommandé de comparer l'empreinte numérique des clés utilisées avec une source de confiance. Les fichiers (clés) des AC "GIP-CPS" et "AC-classe-4" peuvent être récupérés à l URL citée ci-dessus, et déployés avec le LPS. La validation (comparaison de l empreinte) peut être faite : Automatiquement (dans la majorité des cas) par la librairie ou le composant logiciel de gestion des connexions TLS : o o o soit en passant ces fichiers en paramètre de ce composant lors de l établissement de la connexion TLS (cas de librairies se basant sur OpenSSL par exemple) soit en intégrant ces fichiers dans un magasin de certificat (autorités de confiance) propre au composant de connexion (cas de Java par exemple) soit en intégrant ces fichiers dans le magasin des autorités de confiance de l OS, utilisé par le composant (cas de Microsoft.Net par exemple). Manuellement, en comparant les empreintes ; pour les calculer : o o o cette information est calculée automatiquement par la visionneuse de certificat Windows (onglet "Détail", "<tout>", dernière ligne) ; vous pouvez utiliser la commande "openssl X509 -fingerprint" sur le fichier certificat ; vous pouvez utiliser les commandes "sha1sum" ou "sha256sum" sur le certificat dans sa forme DER. Note : Pour effectuer ce contrôle, le simple téléchargement du certificat du serveur DMP (par exemple depuis un environnement de test éditeur) constitue une mauvaise pratique : il est demandé de bien valider le certificat à l aide de sa racine AC-Classe-4 : en effet, l'ajout du certificat du serveur DMP comme autorité de confiance dans le LPS (ou dans le système d exploitation) n est pas adaptée car, à terme lors du renouvellement du certificat du serveur DMP (tous les 3 ans), cette mesure obligerait à mettre à jour tous les LPS déployés sur les postes de PS. Note : Pour l accès Web-PS, le certificat serveur est émis par l'igc Ministérielle qui dépend de l IGC/A. Le LPS n a pas besoin de valider cette IGC, celle-ci étant prise en charge automatiquement par les navigateurs récents lors de l ouverture de l accès Web-PS. Pour les navigateurs qui ne reconnaissent pas encore l'igc/a, une alerte de sécurité sera présentée par le navigateur lors de l'accès au WebPS : le PS peut forcer l'accès au site malgré l'alerte. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

70 7 Accès sécurisé au DMP Vérification du numéro d homologation du LPS Le LPS conforme à la DMP Compatibilité reçoit un numéro d homologation qui est contrôlé par le SI DMP lors de l accès au DMP. Ce numéro doit transiter dans le «Vecteur d Identification et d Habilitation Formelles» (VIHF), dans le champ LPS_ID_HOMOLOGATION_DMP. Ce champ doit être renseigné dans un champ <saml:attributestatement> du VIHF. EX_0.X-1110 E L éditeur homologué à la DMP Compatibilité s engage à garder secret le numéro d homologation attribué par l ASIP Santé et à se prémunir de la mise en œuvre de ce numéro dans d autres logiciels que ceux référencés dans la famille de produit homologuée à laquelle est rattaché ce numéro ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

71 7 Accès sécurisé au DMP 7.2 TD0.1 - Authentification sur le DMP L authentification sur le DMP (authentification du PS dans le cas d une authentification directe ou de la structure de santé dans le cas d une authentification indirecte) est un prérequis transversal à l appel de toute fonction Web Service DMP par le LPS Authentification directe par CPS, CPE, CPF EX_ E L authentification est assurée par l utilisation de la carte CPS pour l authentification TLS mutuelle. Le canal de connexion TLS mutuelle devra rester ouvert (délai maximum d une heure, voir «Connexion au DMP») afin d éviter trop de sollicitations du PS pour la saisie du code PIN de la carte (le canal TLS ne doit pas être renégocié à chaque requête SOAP vers le DMP). Les opérations cryptographiques nécessaires à l établissement du canal TLS mutuel peuvent être effectuées en utilisant la librairie cryptographique «CryptoLib» de l ASIP Santé et son module PKCS11 interfacé avec un composant standard de gestion de connexion TLS Authentification indirecte E EX_ En authentification indirecte, l'utilisateur doit être authentifié localement (au sein de la structure d'exercice). EX_ E En authentification indirecte, l'identifiant interne du PS au sein de la STS doit : être unique au sein de l'es, pérenne et non réutilisable être traité comme une chaîne de caractères indissociable et ne doit pas pouvoir être interprété par des applications pouvoir être utilisé pour retrouver la personne réelle (traçabilité) ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

72 7 Accès sécurisé au DMP Dans cette configuration, le certificat logiciel d authentification pour personne morale de la structure de soins (STS) est utilisé pour l authentification TLS mutuelle. Par ailleurs, afin d apporter suffisamment de confiance dans l authenticité du jeton VIHF et dans la validité des assertions transmises par la structure de soins (puisque le DMP ne peut se baser sur d autres informations fiables contrairement au mode d authentification directe, notamment au niveau des informations d identification de l acteur de santé connecté), celui-ci doit être signé par le certificat logiciel de signature pour personne morale de la structure de soins en XML- DSIG. EX_ E La signature XML-DSIG doit se situer dans un tag Signature entre l élément Issuer et l élément Subject de l assertion (signature de type «envelopped»). Cette signature doit utiliser les algorithmes SHA-1 pour les digests et «SHA-1 with RSA» pour la signature. Le certificat doit être présent dans l élément : //ds:signature/keyinfo/x509data/x509certificate. Ce mode d authentification requiert donc l obtention préalable pour la structure de deux certificats logiciels pour personne morale (certificats serveurs «classe 4») auprès de l IGC- CPS de l ASIP Santé : un certificat d authentification pour personne morale (type «SSL») ; un certificat de signature pour personne morale (type «S/MIME»). Les principes de la signature électronique sont rappelés au ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

73 Structure de soin Emetteur 7 Accès sécurisé au DMP Le VIHF Les données du Vecteur d Identification et d Habilitation Formelles (voir le «Contenu du jeton VIHF» de [CI-TR-CLI-LRD]) doivent être renseignées dans l entête de chaque message SOAP transitant vers le DMP. La durée de vie du jeton VIHF est de 1heure (voir champ Le processus d authentification peut renvoyer des codes erreur liés au traitement du VIHF sous forme de «SOAP Fault» (voir le «Codes erreurs liés au processus d authentification et d habilitation» de [CI-TR-CLI-LRD] et le «Erreurs spécifiques du processus d authentification»). Les tableaux suivants décrivent le contenu du VIHF (en noir) et les contrôles réalisés par le DMP (en bleu) selon le mode d authentification Le VIHF en authentification directe Champ du VIHF //Assertion/ds:Signature Signature du VIHF //Assertion/Issuer 2 Identité de l'émetteur contenue dans le certificat (DN). t Type de valeur utilisée pour renseigner le champ Issuer (X509) Identifiant_Structure Identifiant de la structure de soins ou du cabinet. CPS (PS_TypeCarte = 0) CPF (PS_TypeCarte = 1) Facultatif Si une signature est fournie : Contrôle de validité du certificat signataire. Contrôle d'habilitation à signer du certificat signataire. Contrôle de la signature du VIHF. Contrôle de cohérence avec le DN de l issuer. DN du certificat d'authentification de la CPS/CPF Contrôle de cohérence avec le DN du certificat ayant initié la connexion TLS. Si le VIHF est signé : contrôle de cohérence avec le DN du certificat de signature Constante :"urn:oasis:names:tc:saml:1.1:nam eid-format:x509subjectname" Contrôle de la valeur Struct_IdNat de la CPS/CPF Contrôle de présence dans l'annuaire Contrôle de cohérence dans l'annuaire entre les structures liées CPE (PS_TypeCarte = 2) Facultatif Si une signature est fournie : Contrôle de validité du certificat signataire. Contrôle d'habilitation à signer du certificat signataire. Contrôle de la signature du VIHF. Contrôle de cohérence avec le DN de l issuer. DN du certificat d'authentification de la CPE Contrôle de cohérence avec le DN du certificat ayant initié la connexion TLS. Si le VIHF est signé : contrôle de cohérence avec le DN du certificat de signature Constante :"urn:oasis:names:tc:saml:1.1:nam eid-format:x509subjectname" Contrôle de la valeur Pour les CPE directement nominatives : Struct_IdNat de la CPE Contrôle de présence dans l'annuaire 2 Selon la RFC 2253 (ex : CN= SN=DUPONT+GN=JEAN,OU=Médecin,O=TEST,C=FR) ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

74 Utilisateur connecté 7 Accès sécurisé au DMP à l'identifiant du PS et la structure fournie. Contrôle de cohérence dans l'annuaire entre les structures liées à l'identifiant du PE et la structure fournie. Pour les CPE non directement nominatives : Struct_IdNat de la CPE. Contrôle de présence dans l'annuaire Secteur_Activite Secteur d activité dans lequel exerce l utilisateur Struct_SectAct de la CPS/CPF Contrôle que le SA fait partie du jeu de valeurs HealthCareFacilityTypeCode Contrôle que le SA ne fait pas partie des SA interdits pour ce mode d'authentification Pour les pharmaciens diplômés ou en formation et en remplacement exclusif, qui ont une CPE : à renseigner par le LPS Struct_SectAct de la CPE Contrôle que le SA fait partie du jeu de valeurs HealthCareFacilityTypeCode Contrôle que le SA ne fait pas partie des SA interdits pour ce mode d'authentification Pour les CPE directement nominatives : PS_IdNat de la CPE Contrôle de cohérence avec le certificat d'authentification utilisé pour monter le canal TLS Contrôle de présence dans l'annuaire //Assertion/Subject/NameI D Identifiant de la personne connectée PS_IdNat de la CPS/CPF Contrôle de cohérence avec le certificat d'authentification utilisé pour monter le canal TLS Contrôle de présence dans l'annuaire PS Pour les CPE non directement nominatives : PS_IdNat de la CPE Contrôle de cohérence avec le certificat d'authentification utilisé pour monter le canal TLS Contrôle que ce qui est avant le "/" est une structure présente dans l'annuaire et qu'elle est égale à Identifiant_Structure du VIHF Pour les pharmaciens dîplômés ou en formation et en remplacement exclusif et qui ont une CPE : le PS_IdNat doit être transcodifié (avec xxxx = Identifiant national du pharmacien) : si IdNat /Axxxx ou /A xxxx => remplacer /A ou /A par "0" si IdNat /Rxxxx ou /R xxxx => remplacer /R ou /R ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

75 7 Accès sécurisé au DMP urn:oasis:names:tc:xspa:1.0 :subject:subject-id Identité de l'utilisateur : - Pour un utilisateur humain : nom, prénom, service au sein d'une structure. - Pour une machine : nom du logiciel, nom du modèle, service au sein d un établissement Ne pas renseigner par "8" si IdNat /Exxxx ou /E xxxx => remplacer /E ou /E par "9" Pour les CPE directement nominatives : Ne pas renseigner Pour les CPE non directement nominatives : informations fournies par le LPS. Pas de contrôle Pour les pharmaciens diplômés ou en formation et en remplacement exclusif et qui ont une CPE : Ne pas renseigner Pour les CPE directement nominatives : code = "SECRETARIAT_MEDICAL" codesystem=" " Controle du code et du codesystem urn:oasis:names:tc:xacml:2. 0:subject:role (1ère occurrence obligatoire) Profession de la personne connectée urn:oasis:names:tc:xacml:2. 0:subject:role (2ème occurrence uniquement et obligatoirement pour les médecins et pharmaciens) Spécialité de la personne connectée PS_Prof de la CPS ou PS_FutureProf de la CPF Contrôle de cohérence dans l'annuaire entre la profession liée à l'identifiant et le code profession fourni Pour les médecins : PS_SpécRPPS de la CPS/CPF Contrôle de cohérence dans l'annuaire Certaines spécialités n'ont pas accès au DMP. Exemple : les médecins du travail (SM25 et SCH35) Pour les pharmaciens : PS_TabPharm de la CPS/CPF Contrôle de cohérence dans l'annuaire Certaines spécialités n'ont pas accès au DMP. Pour les CPE non directement nominatives : code = "SECRETARIAT_MEDICAL" codesystem=" " Controle du code et du codesystem Pour les pharmaciens diplômés ou en formation et en remplacement exclusif et qui ont une CPE : code="21" codesystem=" " Controle du code et du codesystem Pour les CPE directement et non directement nominatives : non renseigné. Pour les pharmaciens diplômés et en remplacement exclusif et qui ont une CPE : code="a" ou "G" codesystem=" " displayname="pharmacien titulaire d'officine" ou "Pharmacien biologiste". contrôle de cohérence dans l'annuaire Pour les pharmaciens en formation et en remplacement exclusif et qui ont une CPE : non renseigné car les pharmaciens ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

76 Assertion SAML 7 Accès sécurisé au DMP en formation ne sont pas inscrits sur les tableaux. //Assertion/AuthnStateme nt/authncontext/authnco ntextclassref Mode d'authentification en local namespace xml SAML Version utilisée Identifiant unique de l'assertion (OID recommandé) Date et heure d'émission de l'assertion SAML Constante :"urn:oasis:names:tc:saml:2.0:ac:cl asses:smartcardpki" Contrôle de la valeur Constante :"urn:oasis:names:tc:saml:2.0:asser tion" Contrôle de la valeur Constante : "2.0" Contrôle de la valeur identifiant unique de l'assertion Date et heure d'émission de l'assertion SAML Contrôle que la date d émission du VIHF : - n est pas dans le futur (date du système DMP + 3 secondes maximum) - n a pas plus d une heure de moins que l heure du système DMP. Constante :"urn:oasis:names:tc:saml:2.0:ac:cl asses:smartcardpki" Contrôle de la valeur Constante :"urn:oasis:names:tc:saml:2.0:asser tion" Contrôle de la valeur Constante : "2.0" Contrôle de la valeur identifiant unique de l'assertion Date et heure d'émission de l'assertion SAML Contrôle que la date d émission du VIHF : - n est pas dans le futur (date du système DMP + 3 secondes maximum) - n a pas plus d une heure de moins que l heure du système DMP. //Assertion/AuthnStateme Date et heure d authentification en local //Assertion/Conditions/Au diencerestriction OID d une PSSI (Politique de Sécurité des Systèmes d Information) applicable otbefore Date et heure de début de validité de l assertion Date/Heure de connexion de l utilisateur dans le système source Ne pas renseigner car aucune PSSI n est définie à ce jour Facultatif Si présent, contrôle de la validité à l'instant I : T < (NotBefore) < I < Date/Heure de connexion de l utilisateur dans le système source Ne pas renseigner car aucune PSSI n est définie à ce jour Facultatif Si présent, contrôle de la validité à l'instant I : T < (NotBefore) < I < ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

77 LPS Système cible Patient 7 Accès sécurisé au DMP otonorafter Date et heure de fin de validité de l assertion VIHF_Version Version du VIHF utilisée Authentification_mode Mode d'authentification utilisé min(t+1h,notonorafter) Constante : "1.0" ou "2.0" Contrôle de la valeur si version VIHF 1.0 : non présent si version VIHF >= 2.0 : Constante : "DIRECTE" Contrôle de la valeur min(t+1h,notonorafter) Constante : "1.0" ou "2.0" Contrôle de la valeur si version VIHF 1.0 : non présent si version VIHF >= 2.0 : Constante : "DIRECTE" Contrôle de la valeur urn:oasis:names:tc:xacml:2. 0:resource:resource-id Identifiant du patient concerné par la requête INS du patient Controle de présence si la transaction concerne un DMP donné à savoir : TD0.2/TD0.3/TD1.x/TD2.x/TD3.x INS du patient Controle de présence si la transaction concerne un DMP donné à savoir : TD0.2/TD0.3/TD1.x/TD2.x/TD3.x Ressource_URN Ressource visée par l utilisateur urn:oasis:names:tc:xspa:1.0 :subject:purposeofuse Mode d accès demandé par l utilisateur (normal, bris de glace ou centre de régulation). Constante: "urn:dmp" Contrôle de la valeur - "normal" : pour un accès normal - "bris_de_glace" : lorsque le PS a besoin de consulter le DMP d un patient en cas d urgence, sans avoir la possibilité de lui demander son autorisation - "centre_15" : réservé aux LDR qui indiquent ainsi l usage «centre de régulation» spécifique à leur rôle ; Contrôle de valeur Constante: "urn:dmp" Contrôle de la valeur Constante : toujours "normal" en CPE Contrôle de valeur Mode_Acces_Raison Explication de la raison de l usage du bris de glace. Obligatoire si mode bris de glace. Contrôle de présence si mode bris de glace. Non applicable en CPE LPS_ID Numéro de série ou identifiant de l installation du logiciel LPS_Nom Nom du logiciel utilisé LPS_Version Version du logiciel utilisé Facultatif (usage à des fins de traces) Nom du LPS Contrôle de cohérence avec le n d'homologation (différentier les différents logiciels éventuellement associés à un n d'homologation, en cas de problème). N de version Contrôle de cohérence avec le n d homologation (différentier les différentes versions de logiciels éventuellement associés à un n d'homologation, en cas de problème) Facultatif (usage à des fins de traces) Nom du LPS Contrôle de cohérence avec le n d'homologation (différentier les différents logiciels éventuellement associés à un n d'homologation, en cas de problème). N de version Contrôle de cohérence avec le n d homologation (différentier les différentes versions de logiciels éventuellement associés à un n d'homologation, en cas de problème) ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

78 Utilisateur connecté Structure de soin Emetteur 7 Accès sécurisé au DMP LPS_ID_HOMOLOGATION_ DMP Numéro d'homologation du logiciel N d'homologation du LPS. Contrôle de l'homologation DMP Compatibilité validée pour la transaction appelée N d'homologation du LPS. Contrôle de l'homologation DMP Compatibilité validée pour la transaction appelée Le VIHF en authentification indirecte Champ du VIHF //Assertion/ds:Signature Signature du VIHF //Assertion/Issuer 3 Identité de l'émetteur contenue dans le certificat (DN). t Type de valeur utilisée pour renseigner le champ Issuer (X509) Identifiant_Structure Identifiant de la structure de soins ou du cabinet. CSA Signature XML-DSIG avec le certificat serveur de signature de la STS Contrôle de validité du certificat signataire. Contrôle d'habilitation à signer du certificat signataire. Contrôle de la signature du VIHF. Contrôle de cohérence avec le DN de l issuer. DN du certificat serveur d'authentification de la STS Contrôle de cohérence avec le DN du certificat ayant initié la connexion TLS. Contrôle de cohérence avec le DN du certificat de signature (le VIHF est signé) Constante :"urn:oasis:names:tc:saml:1.1:nameidformat:x509subjectname" Contrôle de la valeur Struct_IdNat de la STS Contrôle de présence dans l'annuaire Contrôle de cohérence entre le certificat et la structure fournie. Secteur_Activite Secteur d activité dans lequel exerce l utilisateur //Assertion/Subject/NameI D Identifiant de la personne connectée Fourni par le LPS (le secteur d'activité n'est pas renseigné dans le certificat serveur) Contrôle que le secteur d activité fait partie du jeu de valeurs HealthCareFacilityTypeCode Contrôle que le secteur d activité ne fait pas partie des secteurs d activité interdits pour ce mode d'authentification Fourni par le LPS Pour un utilisateur humain : Identifiant du PS Pour les traitements automatisés : Identifiant de la personne responsable du traitement Source de donnée : - soit identifiant national (commence par 0, 2, 8 ou 9) Contrôle du 1er chiffre de l identifiant et que sa longueur est conforme - soit identifiant structure+ «/»+identifiant interne (commence par 1, 3, 4, 5, 6) Contrôle de la cohérence avec le champ identifiant_structure 3 Selon la RFC 2253 (ex : CN=testdmp.etablissement-de-test.fr, OU=10B , L=Paris (75), O=TEST, C=FR) ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

79 Assertion SAML 7 Accès sécurisé au DMP urn:oasis:names:tc:xspa:1.0 :subject:subject-id Identité de l'utilisateur : - Pour un utilisateur humain : nom, prénom, service au sein d'une structure. - Pour une machine : nom du logiciel, nom du modèle, service au sein d un établissement Fourni par le LPS Pour un utilisateur humain : Nom, Prénom et Service de l'utilisateur. Contrôle de présence Pour les traitements automatisés : Nom du logiciel, Nom du modèle et Service. Contrôle de présence urn:oasis:names:tc:xacml:2. 0:subject:role (1ère occurrence obligatoire) Profession de la personne connectée Pour les PS : Prendre la valeur la plus appropriée parmi les codes du jeu de valeurs CI- SIS "subjectrole" avec un codesystem= (table G15) Contrôle du codesystem Pour les PF : Prendre la valeur la plus appropriée parmi les codes du jeu de valeurs CI- SIS "subjectrole" avec un codesystem= (table G16) Contrôle que code et codesystem font partie du jeu de valeur subjectrole Pour les autres : Prendre la valeur la plus appropriée parmi les codes du jeu de valeurs CI- SIS "subjectrole" avec un codesystem=" ". Contrôle que code et codesystem font partie du jeu de valeur subjectrole urn:oasis:names:tc:xacml:2. 0:subject:role (2ème occurrence uniquement et obligatoirement pour les médecins et pharmaciens) Spécialité de la personne connectée Pour les médecins : Prendre la valeur la plus appropriée parmi les codes du jeu CI-SIS "subjectrole" de valeurs dont le codesystem= (table R01) Contrôle que code et codesystem font partie du jeu de valeur subjectrole Pour les pharmaciens : Prendre la valeur la plus appropriée parmi les codes du jeu de valeurs CI- SIS "subjectrole" avec un codesystem= (table G05) Contrôle que code et codesystem font partie du jeu de valeur subjectrole //Assertion/AuthnStateme nt/authncontext/authnco ntextclassref Mode d'authentification en local namespace xml SAML Version utilisée Prendre la valeur la plus appropriée parmi les valeurs possibles indiquées dans le document La valeur utilisée doit être cohérente avec le mode d authentification locale de l utilisateur dans le LPS Contrôle de la valeur Constante :"urn:oasis:names:tc:saml:2.0:assertion" Contrôle de la valeur Constante : "2.0" Contrôle de la valeur ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

80 Système cible Patient 7 Accès sécurisé au DMP Identifiant unique de l'assertion (OID recommandé) Date et heure d'émission de l'assertion SAML identifiant unique de l'assertion Date et heure d'émission de l'assertion SAML Contrôle que la date d émission du VIHF : - n est pas dans le futur (date du système DMP + 3 secondes maximum) - n a pas plus d une heure de moins que l heure du système DMP. //Assertion/AuthnStateme Date et heure d authentification en local //Assertion/Conditions/Au diencerestriction OID d une PSSI (Politique de Sécurité des Systèmes d Information) applicable otbefore Date et heure de début de validité de l assertion otonorafter Date et heure de fin de validité de l assertion VIHF_Version Version du VIHF utilisée Authentification_mode Mode d'authentification utilisé Date/Heure de connexion de l utilisateur dans le système source Ne pas renseigner car aucune PSSI n est définie à ce jour Facultatif Si présent, contrôle de la validité à l'instant I : T < (NotBefore) < I < min(t+1h,notonorafter) Constante : "1.0" ou "2.0" Contrôle de la valeur si version VIHF 1.0 : non présent si version VIHF >= 2.0 : Constante : "INDIRECTE" Contrôle de la valeur urn:oasis:names:tc:xacml:2. 0:resource:resource-id Identifiant du patient concerné par la requête Ressource_URN Ressource visée par l utilisateur INS du patient Controle de présence si la transaction concerne un DMP donné à savoir : TD0.2/TD0.3/TD1.x/TD2.x/TD3.x Constante: "urn:dmp" Contrôle de la valeur urn:oasis:names:tc:xspa:1.0 :subject:purposeofuse Mode d accès demandé par l utilisateur (normal). - "normal" : pour un accès normal - "centre_15" : réservé aux LDR qui indiquent ainsi l usage «centre de régulation» spécifique à leur rôle Contrôle de valeur ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

81 LPS 7 Accès sécurisé au DMP Mode_Acces_Raison Explication de la raison de l usage du bris de glace. LPS_ID Numéro de série ou identifiant de l installation du logiciel LPS_Nom Nom du logiciel utilisé LPS_Version Version du logiciel utilisé LPS_ID_HOMOLOGATION_ DMP Numéro d'homologation du logiciel Non applicable en authentification indirecte. Facultatif (usage à des fins de traces) Nom du LPS Contrôle de cohérence avec le n d'homologation (différentier les différents logiciels éventuellement associés à un n d'homologation, en cas de problème). N de version Contrôle de cohérence avec le n d homologation (différentier les différentes versions de logiciels éventuellement associés à un n d'homologation, en cas de problème) N d'homologation du LPS. Contrôle de l'homologation DMP Compatibilité validée pour la transaction appelée ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

82 7 Accès sécurisé au DMP 7.3 Règles de gestion des droits dans le DMP Les droits d un Acteur de Santé (PS ou structure) sur le DMP d un patient dépendent des facteurs suivants : Autorisations et droits d accès au DMP donnée et/ou retirée par le patient à l acteur de santé (PS ou structure); Droits fonctionnels : o selon le mode d authentification, directe ou indirecte, des restrictions existent, en particulier en mode d authentification indirecte ; o selon des règles de gestion propres au DMP et en fonction du rôle de l acteur. Par exemple, le médecin traitant accède aux documents masqués aux PS. Matrice d habilitations : restriction de la consultation à certains types de documents en fonction de la catégorie professionnelle de l acteur de santé (profession et spécialité) voir [CI-ANX-MHAB]) ; La figure ci-dessous présente le cas d usage général pour déterminer si l utilisateur à les droits d accès et les droits fonctionnels correspondant à sa demande. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

83 7 Accès sécurisé au DMP Début INS du patient présenté dans une transaction impliquant l acteur de santé AS TD0.2- Test Existence du DMP Ou TDx.y (toute transaction accédant au DMP du patient) DMP inexistant OUI PROCESSUS DE CREATION DE DMP (selon le souhait du patient) Fin du scénario NON (le DMP existe) DMP Fermé OUI PROCESSUS DE REACTIVATION DE DMP (selon le souhait du patient) Fin du scénario NON (le DMP est actif) Acteur de santé (PS) bloqué OUI Fin du scénario Le PS ne peut accéder à ce DMP NON Aucune autorisation d accès pour l AS Premier accès NON (une autorisation sur ce DMP existe pour cet AS) OUI PROCESSUS DE (RE)DECLARATION D AUTORISATION Fin du scénario Autorisation d accès de l AS expirée NON (l AS dispose d une autorisation d accès valide sur ce DMP) Accès refusé à la fonction TDx.y Fonction interdite au profil de l AS NON OUI Fin L acteur de santé, bien que disposant d une autorisation d accès valide, ne peut exécuter la transaction du fait de son profil (métier, mode d authentification ) Fin L autorisation de l AS sur ce DMP est valide, La transaction peut être jouée Fig. 18 : Cas d usage général sur droits d accès et droits fonctionnels Les processus de création et de réactivation d un DMP liés à l état du DMP seront abordés au 8 «Création et gestion administrative du dossier». Les processus de déclaration de l autorisation ou les modes d accès en l absence d autorisation sont présentés dans le «Autorisations d accès à un DMP». Les règles fonctionnelles par mode d authentification et rôle des acteurs de santé sont évoquées aux «Droits fonctionnels par mode d authentification et par profil utilisateur». ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

84 7 Accès sécurisé au DMP Autorisations et droits d accès à un DMP Donner une autorisation d accès à un PS / à une STS Le recueil par l acteur de santé auprès du patient d une autorisation d accès est un prérequis sans lequel rien n est permis, sauf cas d urgences spécifiques (accès en mode «bris de glace» ou «centre de régulation»). En pratique, l autorisation d accès est déclarée dans le DMP : Par le patient lui-même via son AW patient ; Par l acteur de santé qui crée le DMP : o Il dispose ensuite automatiquement d une autorisation d accès à ce DMP ; Par l acteur de santé authentifié : o via son LPS à l aide de la transaction TD0.3 «Mise à jour de l autorisation» ou o via l accès web PS. Ces autorisations sont inscrites dans le DMP ; Fin d une autorisation d accès à un PS / à une STS Les autorisations d accès du DMP ne sont actuellement pas limitées dans la durée. Elles s appliquent dès la déclaration et durent jusqu à ce qu elles soient retirées. Pour les autorisations de PS, il est toutefois demandé de confirmer que l autorisation est toujours active s il s est passé un certain laps de temps (paramétrable au niveau du système DMP et actuellement positionné à 12 mois) depuis le dernier accès au DMP du patient par le PS. Note : Cette confirmation ne concerne que les PS, pas les STS. Une autorisation peut prendre fin de l une des façons suivantes : lorsqu elle est supprimée par le patient (via son l accès web Patient) ; lorsqu elle est supprimée par l acteur de santé lui-même (via son LPS avec la transaction TD0.3 ou via l accès web PS) ; en cas de non usage pendant une période donnée (paramétrable au niveau du système DMP et actuellement positionné à 12 mois) par le PS (non applicable aux STS) ; en cas d inscription du PS (non applicable aux STS) dans la liste des PS bloqués (par le Médecin Traitant via son AW PS uniquement). Note : L autorisation n est pas recréée automatiquement si le PS est retiré de la liste des PS bloqués ; lors de la fermeture du DMP. Dans ce cas, toutes les autorisations rattachées prennent fin. Lors de la réactivation du dossier, seule l autorisation de l acteur de santé ayant réactivé le dossier est recrée. Lors de la suppression définitive du DMP. La suppression du DMP ne peut être demandée que par le patient ou le médecin traitant (sur demande du patient) via l accès web DMP. Une autorisation ayant pris fin est appelée autorisation expirée dans la suite de ce document. Dans le cas d une autorisation expirée, l acteur de santé peut à nouveau se déclarer autorisé, sauf pour un PS inscrit dans la liste des PS bloqués. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

85 7 Accès sécurisé au DMP Erreurs transactionnelles liées à l autorisation ou à l état du DMP En fonction des autorisations existantes sur un DMP ou en fonction de l état même de ce DMP, les transactions DMP peuvent retourner un code erreur qui permet d identifier la situation et les actions possibles. L autorisation d accès n existe pas : le PS n a pas accès au DMP du patient, car il n a jamais eu d autorisation. La transaction TD0.2 retourne l erreur «autorisation d accès non trouvée» : code erreur: DMPAuthorizationNotFound / statut NON_EXISTE ; le PS peut se déclarer «autorisé» via la transaction TD0.3 ou passer en mode «bris de glace» (voir le ) si le patient n a pas bloqué ce mode d accès à son dossier. Expiration des droits d accès : le PS n a plus accès au DMP du patient, car son autorisation expirée. La transaction TD0.2 retourne l erreur «accès périmé» : code erreur: DMPAuthorizationExpired / statut EXPIRE ; le PS peut à nouveau se déclarer «autorisé» via la transaction TD0.3 ou passer en mode «bris de glace» (voir le ) si le patient n a pas bloqué ce mode d accès à son dossier ; Blocage d un PS, par le patient ou le MT (blocage positionné via l IHM Web) : L accès du PS au DMP du patient est bloqué. La transaction TD0.2 retourne l erreur «accès bloqué» : code erreur: DMPAccessForbidden / statut INTERDIT ; le PS ne peut plus à nouveau se déclarer «autorisé», ni accéder au DMP en mode «bris de glace» ou «centre de régulation» ; seul un PS peut être bloqué (pas une STS) ; un PS bloqué peut être retiré de la liste des PS bloqué par le patient ou le MT (à la demande du patient) ce qui permettra ultérieurement à ce PS de se déclarer à nouveau «autorisé». Fermeture d un DMP à la demande du patient : toute opération sur un DMP fermé retourne une erreur «DMP fermé» (DMPClosed) ; le PS peut alors proposer au patient la réactivation de son dossier ; la fermeture d un DMP provoque l expiration de toutes les autorisations d accès. La réactivation du DMP ne rétablit pas les autorisations d accès présentes avant la fermeture ; en cas de réactivation du dossier (TD1.2 «réactivation d un DMP»), ces autorisations restent expirées. Suppression définitive du DMP en mode Web, par le patient ou le MT : toute opération sur un DMP supprimé retourne une erreur «DMP inexistant» (DMPPatientNotFound) ; le cas d usage est exactement le même que si le DMP du patient n a jamais existé. Il est donc possible d enclencher le processus de création du dossier par la transaction «TD1.1 création du DMP du patient». ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

86 7 Accès sécurisé au DMP Accès sans l autorisation du patient Il existe 2 cas principaux d accès possible au DMP du patient sans autorisation : L accès en mode «bris de glace», L accès en mode «centre de régulation» (ou «centre 15»). Le patient peut s opposer à l un et / ou l autre de ces modes d accès spécifiques. Ces modes d accès sont accompagnés de restrictions fonctionnelles (certaines fonctions de la gestion administrative du dossier, par exemple, sont inaccessibles en mode bris de glace ou centre de régulation) Mode bris de glace Lorsque le PS a besoin de consulter le DMP d un patient en cas d urgence, sans avoir la possibilité de lui demander son autorisation, au lieu de se déclarer autorisé à accéder au dossier par le patient, il dispose de la possibilité d accéder au dossier en mode «bris de glace». Dans ce cas, le PS doit indiquer la raison de l utilisation du mode «bris de glace». Dans le VIHF, le champ «PurposeOfUse» prend la valeur «bris_de_glace» et le champ «Mode_Acces_Raison» la raison de l utilisation de ce mode. EX_ E Le mode «bris de glace» ne doit pas être persistant en dehors du temps de la session courante du PS dans le LPS et pour le patient actuellement ouvert : il doit être désactivé une fois le dossier local du patient fermé (le LPS ne doit pas continuer à positionner ce champ à la valeur bris de glace). L utilisation de ce mode génère une trace spécifique dans le DMP du patient. L usage du mode bris de glace est suivi par le système de pilotage du DMP pour détecter d éventuels abus. E EX_ L accès au DMP en mode «bris de glace» doit être affiché clairement à l utilisateur du LPS pendant toute la durée de cet accès. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

87 7 Accès sécurisé au DMP Mode centre de régulation Le mode d accès «centre de régulation» est réservé aux centres de réception et de régulation des appels des SAMU-Centres 15 : pour les permanenciers auxiliaires de régulation médicale (PARM) en authentification indirecte avec un certificat logiciel pour personne morale de centre de régulation pour la recherche de DMP sans INS (TD0.5), pour les médecins régulateurs en authentification directe avec leur CPS pour la consultation. Les permanenciers auxiliaires de régulation médicale (PARM) des services de centres de réception et de régulation des appels des SAMU-Centres 15 peuvent utiliser la fonctionnalité de recherche d un DMP sans l INS du patient (à partir d autres traits d identité) mais ils ne peuvent pas consulter le DMP du patient. La consultation du DMP du patient reste réservée au médecin régulateur authentifié par sa CPS (authentification directe) qui n a pas à se déclarer «autorisé par le patient» : il peut accéder au dossier en mode «centre de régulation» (champ PurposeOfUse du VIHF = «centre_15»). L alimentation est accessible en mode «centre de régulation» aussi bien en authentification directe avec CPS qu en authentification indirecte avec un certificat logiciel pour personne morale de centre de réception et de régulation des appels des SAMU-Centres 15. Dans le VIHF, le champ «PurposeOfUse» prend la valeur «centre_15». L utilisation de ce mode génère une trace spécifique dans le DMP du patient Opposition du patient aux accès sans autorisation Le patient a la possibilité de s opposer expressément à l accès à son DMP en modes «bris de glace» et/ou «centre de régulation» : en cas de tentative d accès en mode «bris de glace» alors que le patient n a pas autorisé cet usage, le SI DMP renverra une erreur «accès en urgence refusé» (DMPAccessForbidden) ; en cas de tentative d accès en mode «centre de régulation» alors que le patient n a pas autorisé cet usage, le SI DMP renverra une erreur «accès en urgence refusé» (DMPAccessForbidden). Rappel : Un PS que le patient a bloqué ne peut pas accéder au DMP de ce patient, que ce soit en mode «normal», «bris de glace» ou «centre de régulation». ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

88 7 Accès sécurisé au DMP Droits fonctionnels par mode d authentification et par profil utilisateur En fonction de son mode d accès (authentification directe CPS ou CPE, authentification indirecte) et de son rôle (PS non médecin, médecin traitant (MT), médecin non MT, non PS), l acteur autorisé disposera de droits fonctionnels spécifiques : tous ces droits sont listés dans le tableau ci-après. Attention : Certaines actions sont irréversibles Le PS doit être bien informé que certaines actions sont irréversibles, notamment : Lorsqu un document initialement invisible du patient a été rendu visible au patient, il ne peut plus être rendu invisible du patient. De la même manière un document qui a toujours été visible du patient ne peut pas être rendu invisible du patient. On ne peut pas annuler la suppression d un document. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

89 Authentification directe Authentification CPS CPE Certificat ES acteur PS non médecin Médecin (non MT) Médecin Traitant (MT) non PS tous tous mode_accès normal régulation bris de glace normal régulation bris de glace normal bris de glace normal normal régulation ACCES SECURISE AU DMP TD0.1 Authentification sur le DMP oui oui oui oui oui oui oui oui oui oui oui TD0.2 Test d'existence d'un DMP et vérification de l'autorisation oui oui oui oui oui oui oui oui oui oui oui TD0.3 Mise à jour de l'autorisation Se déclarer autorisé oui non non oui non non oui non oui (1) oui (1) non Supprimer son autorisation oui non non oui non non oui non non oui non Se déclarer MT non non non oui non non non (2) non non non non Se supprimer MT non non non oui non non oui non non non non TD0.4 Liste des DMP autorisés oui oui oui oui oui oui oui oui non oui (3) non TD0.5 Recherche d'un patient dans le DMP sans INS oui oui non oui oui non oui non oui oui oui TD0.9 Accès Web PS contextuel oui oui oui oui oui oui oui oui oui non non CREATION ET GESTION ADMINISTRATIVE DU DMP TD1.1 Création d'un DMP oui non non oui non non oui non oui oui non TD1.2 Réactivation d'un DMP oui non non oui non non oui non oui oui non TD1.3 Données administratives d'un DMP TD1.3a Consultation des données administratives d'un DMP oui oui oui oui oui oui oui oui oui oui oui TD1.3b Mise à jour des données administratives d'un DMP oui non non oui non non oui non oui oui non TD1.4 Fermeture d'un DMP oui non non oui non non oui non non non non TD1.5 Accès internet du patient TD1.5a Création du compte internet patient oui non non oui non non oui non oui oui non TD1.5b Ajout d'un canal OTP oui non non oui non non oui non oui oui non TD1.5d Mise à jour des information du compte internet oui non non oui non non oui non oui oui non TD1.6 Liste des PS autorisés/bloqués sur un DMP oui non non oui non non oui non non non non ALIMENTATION TD2.1 Alimentation d'un DMP oui oui oui oui oui oui oui oui non oui (4) oui (4) CONSULTATION TD3.1 Recherche de documents sur un DMP Rechercher les métadonnées oui oui oui oui oui oui oui oui non non non Rechercher la référence d'un document oui oui oui oui oui oui oui oui non oui (5) oui (5) TD3.2 Consultation d'un document sur un DMP Documents non masqués aux PS oui oui oui oui oui oui oui oui non non non Documents masqués aux PS oui (6) oui (7) oui (7) oui (6) oui (7) oui (7) oui oui (7) non non non Documents non visibles du patient oui oui oui oui oui oui oui oui non non non Documents archivés oui oui oui oui oui oui oui oui non non non Documents obsolètes (anciennes versions) oui oui oui oui oui oui oui oui non non non Documents supprimés oui oui oui oui oui oui oui oui non non non TD3.3 Gestion des attributs d'un document TD3.3a Masquer un document aux PS oui non non oui non non oui non non non non TD3.3a Démasquer un document aux PS oui (8) non non oui (8) non non oui non non non non TD3.3b Rendre un document visible au patient oui non non oui non non oui non non non non TD3.3d Archiver un document * oui (8) non non oui oui oui oui oui non non non TD3.3d Désarchiver un document * oui (8) non non oui oui oui oui oui non non non TD3.3c Supprimer un document * oui (8) oui (8) oui (8) oui oui (8) oui (8) oui oui (8) non oui (8) oui (8) * Pour un document du patient, cette action n'est possible que par le MT (ou le patient lui-même) oui (5) TD3.1 - Recherche référence d'un document en authentification indirecte (en vue de sa suppression par ex.) oui (1) TD0.3 - L'autorisation est donnée à la structure oui (6) TD3.2 - Ses propres documents uniquement (ceux dont il est l'auteur) non (2) TD0.3 - Si le médecin est déjà déclaré MT, il ne peut pas se redéclarer MT. oui (7) TD3.2 - Consultation d'un document masqué en mode bris de glace ou centre 15 possible uniquement si oui (3) TD0.4 - Liste des DMP autorisés : recherche limitée, par date, aux nouvelles autorisations autorisation par le patient oui (4) TD2.1 - Ajout de documents par non PS : imputabilité à la structure oui (8) TD3.3 - Ses propres documents uniquement (ceux dont il est l'auteur) Tableau 19 : Droits fonctionnels par mode d authentification et par profil utilisateur Authentification indirecte ASIP Santé DSFT des interfaces DMP des LPS V /06/ / Accès sécurisé au DMP

90 7 Accès sécurisé au DMP Matrice d habilitation La liste des documents présentés à l utilisateur est restreinte aux seuls documents que le PS est habilité à consulter conformément à la matrice d habilitation du CI-SIS (voir 4.1 du [CI- PARTAGE]). ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

91 7 Accès sécurisé au DMP 7.4 TD0.2 - Test d existence d un DMP et vérification de l autorisation Cette transaction permet de tester l existence d un DMP à partir de son INS et retourne le statut de l autorisation de l acteur de santé sur ce DMP. Cette transaction utilise la norme HL7-V3. Il est nécessaire de lire le 8.8 «Spécifications techniques communes à la gestion administrative du dossier» pour comprendre la structuration de ces messages Prérequis 1. le PS ou la STS est authentifié (TD0.1) ; 2. l INS est disponible Cinématique Le LPS fournit un INS au DMP et récupère 1 ou 0 résultat. Dans le cas où le DMP existe, le PS est susceptible d être sollicité pour contrôler que l identité du patient du DMP (liée à l INS) correspond bien à l identité du patient local (dans le LPS) ; voir à ce titre les exigences liées à l INS au REC_ R Lors d'un test d'existence, en cas de DMP fermé, il est recommandé que le LPS affiche à l'utilisateur : le statut "fermé" du DMP du patient, la date de fermeture, le motif de la fermeture, le commentaire associé au motif de fermeture Transaction La transaction technique est décrite dans le du [CI-GESTPAT] et utilise sur le message HL7 V3 Patient Registry Get Demographics Query (interaction PRPA_IN201307UV02) via un Web Service. L élément doit être positionné à «TEST_EXST» (voir ) Données en entrée La requête doit contenir l INS du patient, dans le paramètre «Patient.id», ainsi qu un identifiant unique de query généré par le LPS, dans l élément controlactprocess/ querybyparameter : ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

92 7 Accès sécurisé au DMP Nom du champ Card. XPath HL7 Remarques Requête paramétrée [1..1] querybyparameter Identifiant unique du query [1..1] queryid Oid des query dans le LPS Oid géré par le LPS Identifiant du query dans le LPS Id généré par le LPS Statut du query [1..1] Fixé à «new» Liste des paramètres [1..1] parameterlist Paramètre de type Identifiant du patient [1..1] patientidentifier Valeur du paramètre [1..1] value Pour un INS-C : Pour un INS-A : OID de l identifiant INS Valeur de l INS Nom du paramètre, contraint par HL7 [1..1] semanticstext Fixé à «Patient.id» Tableau 20 : TD0.2 Données en entrée Données en sortie En retour, le message HL7 V3 Patient Registry Get Demographics Query Response»(PRPA_IN201308UV02) est renvoyé En cas de succès Accusé de réception du traitement «ok» (AA). Dans le cas où le DMP n existe pas : Donnée Elément Description Le DMP n existe pas controlactprocess/queryack/queryresponse «NF» Tableau 21 : TD0.2 Données en sortie le DMP n existe pas le message ne renvoie aucune occurrence de l élément controlactprocess/subject. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

93 7 Accès sécurisé au DMP Dans le cas où le DMP existe : Donnée Elément Description Le DMP existe Le patient controlactprocess/queryack/queryresponse controlactprocess/subject/registrationevent/ subject1/patient «OK» INS du patient patient/id Peut contenir plusieurs valeurs qui se distinguent (INS-C ou INS-A) par l attribut root. Nom d usage Nom de naissance si renseigné Prénom r = 'SP'] r = 'BR'] patient/patientperson/name/given Sexe Date de naissance DMP Actif / Fermé Date de fermeture Motif de fermeture Raison de fermeture Statut de l autorisation Médecin traitant DMP actif DMP fermé controlactprocess/subject/registrationevent/ controlactprocess/reasonof/detectedissueevent/c ode controlactprocess/reasonof/ detectedissueevent/text attentionline (à la racine du message) avec un élément fils attentionline (second élément à la racine du message) avec un élément fils Si le DMP existe mais est fermé Si le DMP existe mais est fermé Avec la structuration définie au ; Valeurs possibles : voir tableau ci-dessous. Si le DMP existe mais est fermé Valeurs possibles : voir tableau ci-dessous. Exemple : <attentionline> <keywordtext code="autorisation" codesystem=" "/> <value xsi:type="cv" code="valide" codesystem=" "/> </attentionline> Cette information n'est pas retournée en authentification indirecte. Exemple : <attentionline> <keywordtext code="statut_mt" codesystem=" "/> <value xsi:type="bl" value="true"/> </attentionline> Tableau 22 : TD0.2 Données en sortie le DMP existe ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

94 7 Accès sécurisé au DMP Nomenclature des motifs de fermeture (OID ) : Code Signification FERMETURE_DEMANDE_PATIENT Fermeture du DMP suite à la demande du patient Tableau 23 : Nomenclature des motifs de fermeture d un DMP Valeurs possibles pour le statut de l autorisation (élément : Code AUTORISATION Description NON_EXISTE INTERDIT EXPIRE VALIDE Pas d autorisation existante Blocage d accès (PS uniquement, pas STS) Autorisation ayant pris fin Autorisation valide Tableau 24 : TD0.2 Statuts d autorisation retournés Valeurs possibles pour le statut médecin traitant (élément : Code MT Description false true Autorisation simple Autorisation de type MT Tableau 25 : TD0.2 Statut MT retourné En cas d erreur En cas d erreur de la transaction, un code et un message d erreur sont renvoyés dans le message. Voir annexe au 11.4 ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

95 7 Accès sécurisé au DMP 7.5 TD0.3 - Mise à jour de l autorisation d accès Cette transaction permet de gérer l autorisation d accès de l acteur de santé identifié (création ou recréation ou retrait) sur le DMP du patient (l INS du patient est connu). Cette transaction permet également de mettre à jour le statut de médecin traitant (ajout ou retrait) Prérequis 1. le PS ou la STS est authentifié (TD0.1) ; 2. l INS est disponible ; 3. pour la création de l autorisation : le patient a donné l autorisation d accès Cinématique Début L acteur de santé (AS) souhaite accéder à un DMP pour lequel le système ne lui connait pas d'autorisation valide Fenêtre de déclaration Vous ne disposez pas/plus de l autorisation d accès à ce DMP (voir les recommandations d ergonomies de cette fenêtre ci-après) Consentement recueilli Case cochée OUI NON PROCESSUS DE DECISION D ACCES SANS AUTORISATION Le PS est Médecin Traitant du patient Case MT cochée par médecin avec CPS Fin du Scénario NON OUI TD0.3 Mise à jour de l autorisation (ajout autorisation + éventuel statut MT) Fin L autorisation de l AS sur ce DMP est valide. Exécution des transactions VIHF: PurposeOfUse= normal Fig. 26 : Processus de déclaration de l autorisation ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

96 7 Accès sécurisé au DMP EX_ E Le LPS ne doit pas positionner systématiquement d auto-déclaration d autorisation d accès du PS ou de la STS sur le DMP d un patient. Le positionnement d une autorisation doit toujours se faire suite à une demande explicite ou à une action spécifique de l utilisateur, par exemple à l aide d une boite de dialogue ou d un élément graphique (case à cocher) dédié à cela. La transaction TD0.3 «Mise à jour de l autorisation» n est appelée qu après réception d un statut retourné par le DMP indiquant qu il n y a pas ou plus d autorisation d accès au DMP du patient pour ce PS ou cette STS. Ce statut peut être récupéré : soit après un test existence du DMP du patient et de la vérification de l autorisation (via la transaction TD0.2, soit après une utilisation d une autre transaction. EX_ E En authentification directe, si le statut renvoyé par le DMP est «autorisation expirée», le LPS doit indiquer au PS qu il doit effectuer une nouvelle autorisation. Le LPS propose ensuite à l utilisateur de confirmer que le patient l autorise à accéder à son DMP. Exemple d implémentation : Votre autorisation d accès au DMP de M xxxxx est expirée. Seul un médecin (code profession CPS 10) qui s est connecté avec sa CPS (en mode d authentification directe) peut s attribuer (avec l accord du patient) ou se retirer le statut de «Médecin traitant». Dans le LPS, les autorisations d accès et le statut de médecin traitant ne peuvent être donnés pour le compte d une autre personne. Note : À la demande du patient, le médecin traitant peut, via l accès web PS uniquement, gérer les autorisations d accès d autres personnes. R REC_ Les éléments de vocabulaire suivants peuvent être intégrés au LPS. Les éléments «[x]» représentent des cases à cocher cochées par défaut. Les éléments «( )» représentent des boutons radio non cochés. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

97 7 Accès sécurisé au DMP Ajout d autorisation En authentification directe : Confirmez-vous que M/Mme XXXX (ou son représentant légal) vous autorise à accéder à son DMP? ( ) Le patient (ou son représentant légal) m'a autorisé à accéder à son DMP ( ) J'accède en urgence au DMP. Le patient est hors d'état d'exprimer sa volonté, et il y a un risque immédiat pour sa santé (accès bris de glace) Motif de l'accès en mode bris d de XXXXX : [ champ de saisie du motif ] En authentification indirecte ou en authentification directe par CPE : Confirmez-vous que M/Mme XXXX (ou son représentant légal) autorise votre structure de soins à accéder à son DMP? [x] Le patient a autorisé ma structure de soins à accéder à son DMP Retrait d autorisation En authentification directe : Mettre fin à mon autorisation d accès au DMP de M/Mme XXXX. En authentification indirecte : Mettre fin à l autorisation d accès de la structure de soins au DMP de M/Mme XXXX S attribuer le statut de médecin traitant Médecin en authentification directe : M attribuer le statut de médecin traitant pour le DMP de M/Mme XXXX Se retirer le statut de médecin traitant Médecin en authentification directe : Se retirer le statut de médecin traitant pour le DMP de M/Mme XXXX. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

98 7 Accès sécurisé au DMP Transaction Cette transaction permet de gérer l autorisation d accès : de l acteur de santé identifié dans le VIHF ; sur le DMP du patient identifié dans le VIHF (l INS du patient est dans le VIHF) ; Les actions possibles sont : mise à jour de l autorisation d accès (création ou recréation ou retrait) ; mise à jour du statut de médecin traitant (ajout ou retrait) ; La fonction permet d ajouter l autorisation d accès et le statut de médecin traitant en un seul appel Données en entrée Fig. 27 : TD0.3 diagramme de classe des données en entrée Nom du champ Type Card Description action Enum [1..1] role Enum [0..1] Code action souhaité : AJOUT : ajout de l autorisation et/ou du rôle SUPPRESSION : suppression de l autorisation et/ou du rôle Rôle spécifique éventuel : MEDECIN_TRAITANT : rôle médecin traitant non fourni pour une autorisation simple Note : Ce paramètre est de type «Enumération» pour faciliter l ajout dans les versions futures d autres rôles pour un PS. Tableau 28 : TD0.3 Données en entrée Le tableau suivant liste les différentes possibilités d appel de la fonction : action role Opération réalisée AJOUT [non fourni] Ajoute une autorisation simple AJOUT MEDECIN_TRAITANT Si le PS possède déjà une autorisation : ajoute le rôle médecin traitant au PS Si le PS ne possède pas d autorisation : ajoute une autorisation avec le rôle médecin traitant SUPPRESSION [non fourni] Supprime l autorisation de l acteur de santé (et de son éventuel rôle médecin traitant dans le cas d un PS médecin) SUPPRESSION MEDECIN_TRAITANT Supprime le rôle médecin traitant du PS Tableau 29 : TD0.3 valeurs possibles pour le paramètre «action» ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

99 7 Accès sécurisé au DMP Données en sortie Fig. 30 : TD0.3 Diagramme de classe des données en sortie Le détail concernant les données de l accusé de réception du traitement est le suivant : Nom du champ Type Taille Card Description status A 50 [0..1] Code de retour : DMPOk (en cas de succès), ou code d erreur (en cas d erreur) context A text [0..1] Message d erreur (en cas d erreur) Tableau 31 : TD0.3 Données en sortie Codes d erreur Voir annexe au 11.4 ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

100 7 Accès sécurisé au DMP 7.6 TD0.4 - Liste des DMP autorisés Prérequis 1. le PS ou la STS est authentifié (TD0.1) Cinématique Cette transaction a deux usages : 1) Pour une structure, elle permet de récupérer la liste des nouveaux DMP autorisés pour la structure (avec les INS et traits d'identités). Outre les habituelles informations d'authentification, il est possible de paramétrer en entrée une date à partir de laquelle la recherche est effectuée (ex: (date du jour - 3 jours) ou (date du jour - 1 semaine)). L'éditeur peut mettre en œuvre dans le LPS un appel à cette transaction planifié régulièrement (par exemple tous les 3 jours ou toutes les semaines). Exemple : Cette transaction peut être utile dans le cas d un logiciel du SIH ne recueillant pas directement l autorisation du patient. 2) Pour un PS, cette transaction permet de récupérer la liste des patients pour lesquels un nouveau document a été ajouté dans son DMP depuis une date donnée. Le retour est le même, seul le paramétrage en entrée est différent. REC_ R Pour la structure le LPS vérifie lors de la réception de la liste, pour chaque INS retourné, si cet INS existe dans l annuaire local et «marque» l INS local pour noter l information «DMP existe et STS autorisé». Les traitements d alimentation de ces DMP par la structure autorisée pourront alors se faire. EX_ E Lorsqu elle est présentée à l utilisateur, la liste des patients ayant autorisé l'accès à leur DMP au PS comprend a minima les éléments de présentation suivants : Nom d'usage ; Prénom ; Nom de naissance. Note : Il y a une limitation du nombre de résultats retournés, issue d un paramètre positionné sur le SI DMP. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

101 7 Accès sécurisé au DMP Transaction L appel à cette transaction déclenche la recherche des patients pour lesquels un PS ou une structure est habilité. Elle est implémentée par un Web Service spécifique au DMP Données en entrée Fig. 32 : TD0.4 Diagramme de classe des données en entrée Le détail concernant les données qui peuvent être fournies en entrée est le suivant : Nom du champ Type Taille Card Description startdate D [1..1] datetype Enum [1..1] date de filtrage à partir de laquelle la recherche est effectuée format YYYYMMDDhhmmss - La date doit être passée en UTC (universal coordinated time) le LPS doit traduire sa date locale en UTC Type de date de recherche : LASTAUTORIZATION : recherche par rapport à la date d'autorisation du PS/STS LASTDOC : recherche par rapport à la date de dernier ajout d un document Tableau 33 : TD0.4 Données en entrée Données en sortie Les données en sortie de la fonction sont pour chaque patient récupéré : l identifiant (INS-C / INS-A) ; données administratives : o le nom d usage ; o le nom de naissance ; o le prénom ; o la date de naissance des patients récupérés ; indicateurs liés au dossier patient et à l acteur de santé : o MT (le cas échéant, pour les DMP dont l AS est autorisé comme MT) ; o date de dernière modification ; o date de dernier accès ; o date de dernier ajout de documents ; o message (champ obsolète ignorer ce champ). ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

102 7 Accès sécurisé au DMP Fig. 34 : TD0.4 Diagramme de classe des données en sortie Le détail concernant les données de l accusé de réception du traitement est le suivant : Nom du champ Type Taille Card Description status A 50 [1..1] Code de retour : DMPOk (en cas de succès), ou code d erreur (en cas d erreur) context A text [0..1] Message d erreur (en cas d erreur) Tableau 35 : TD0.4 Accusé de réception de traitement ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

103 7 Accès sécurisé au DMP En cas de succès Les données administratives des patients retournées sont les suivantes : Nom du champ Type Taille Card Description nationalid A 22 [1..N] Identifiants du patient : INS-C / INS-A nationalidtype A 20 [1..N] OID des identifiants fournis afin de déterminer leur type lastname A 80 [1..1] Nom d usage. Par exemple : nom marital. patronymicalname A 80 [0..1] Nom de naissance (nom de famille) firstname A 60 [1..1] Prénom dateofbirth A 8 [1..1] Date de naissance au format YYYYMMDD MT B - [1..1] Précise si le PS est médecin traitant sur le dossier (true/false) Message B - [1..1] lastaccessdate A 14 [1..1] Ce champ est obsolète et ne doit plus être utilisé par le LPS (ignorer ce champ) Date de dernier accès sur le dossier du patient par le PS Format YYYYMMDDhhmmss - la date est retournée en UTC (universal coordinated time) le LPS doit convertir dans sa date locale avant affichage à l utilisateur Date de dernière modification du dossier patient lastupdatedate A 14 [1..1] lastadddate A 14 [1..1] Format YYYYMMDDhhmmss - la date est retournée en UTC (universal coordinated time) le LPS doit convertir dans sa date locale avant affichage à l utilisateur Date de dernier ajout de document sur le dossier du patient Format YYYYMMDDhhmmss - la date est retournée en UTC (universal coordinated time) le LPS doit convertir dans sa date locale avant affichage à l utilisateur Tableau 36 : TD0.4 Données en sortie En cas d erreur Le champ status de l accusé de réception du traitement contient un code erreur et le champ contexte un message associé. Voir annexe au 11.4 ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

104 7 Accès sécurisé au DMP 7.7 TD0.5 - Recherche sans INS de patients dans le DMP Cette transaction permet à un utilisateur autorisé de faire une recherche de patients à partir de traits d identité (sans INS) et ainsi de retrouver l INS d un patient. Elle s appuie sur la transaction IHE Patient Demographics Query HL7 V3 (ITI-47). D un point de vue «acteurs IHE», le LPS est le Patient Demographic Consumer et le DMP est le Patient Demographic Supplier Prérequis 1. le PS ou la STS est authentifié (TD0.1) ; 2. le PS possède un ou plusieurs traits d identité du patient permettant de l identifier Cinématique Le LPS fournit un ou plusieurs traits d identité du patient et récupère 0 ou N résultats Transaction La transaction technique est définie dans [IHE-PDQV3] (ITI-47) au 3 et 3.47 Patient Demographics Query HL7 V3. La transaction utilise le message HL7 V3 "Patient Registry Find Candidates" (PRPA_IN201305UV02) pour la requête. Note : La recherche ne supporte pas actuellement la réponse incrémentale («continuation option» du profil PDQ V3, via le message «Query Control Act Request Continue/Cancel message (QUQI_MT000001UV01)») Données en entrée Au moins 1 critère de recherche doit être passé en entrée (dans le cas contraire, un code erreur DMPInvalidRequest en renvoyé, accompagné d un détail textuel indiquant la cause de l erreur). Le tableau de synthèse suivant restreint les paramètres de recherche de la requête PDQ et contraint leur cardinalité pour le DMP. Champs PDQ Card. Description livingsubjectname.value.familly [0..1] Nom livingsubjectname.value.given [0..1] Prénom livingsubjectadministrativegender.value. [0..1] Sexe (M, F ou U) livingsubjectbirthtime.value [0..1] Date de naissance (format (AAAAMMJJ) patientaddress.value.postalcode [0..1] Code postal actuel du patient patientaddress.value.city [0..1] Ville actuelle du patient Tableau 37 : TD0.5 Synthèse des paramètres de recherche ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

105 7 Accès sécurisé au DMP Le tableau suivant décrit la structure du message HL7 en entrée : XPath HL7 Card. Valeur / remarque PRPA_IN201305UV02 [1..1] Racine du message [1..1] Fixé à «XML_1.0» Eléments «d entête» du message [ ] [1..1] Voir le chapitre structure commune des messages HL7 envoyés dans la partie «gestion administrative du dossier». controlactprocess [1..1] corps de la requête [1..1] Valeur fixée à [1..1] Valeur fixée à «EVN» code [1..1] [1..1] querybyparameter [1..1] queryid [1..1] Identifiant unique du query, généré par le [1..1] Racine d OID géré par le [1..1] Identifiant unique généré par le LPS code [1..1] Valeur fixé à «new» parameterlist [1..1] Liste des paramètres du query livingsubjectadministrativegender [0..1] Critère sexe [0..1] Valeur du critère : M, F ou U semanticstext [0..1] Fixé à «LivingSubject.administrativeGender» livingsubjectbirthtime [0..1] Critère date de naissance [0..1] Valeur du critère : format AAAAMMJJ semanticstext [0..1] Fixé à «LivingSubject.birthTime» livingsubjectname [0..1] Critères nom/prénom Si présent : use = «SRCH» (permet une recherche [0..1] approchante sur les nom/prénom) Si non présent : recherche stricte sur les nom/prénom value/family [0..1] Valeur du critère nom (au moins 2 caractères) value/given [0..1] Valeur du critère prénom semanticstext [0..1] Fixé à «LivingSubject.name» patientaddress [0..1] Critère adresse Si présent : use = «SRCH» (permet une recherche [0..1] approchante sur «city») Si non présent : recherche stricte «city» value/postalcode [0..1] Critère : code postal value/city [0..1] Critère : city semanticstext [0..1] Fixé à «LivingSubject.addr» Tableau 38 : TD0.5 Structure du message en entrée Recherche sur les noms Un seul critère «nom» est à passer par le LPS. Le DMP recherche sur les deux noms : nom d usage (ex : marital) et nom de naissance. La recherche sur les noms / prénom se fait de manière stricte si l attribut de livingsubjectname n est pas fourni. Dans ce cas, une recherche sur given = «Jean» et family «Dupond» ne retournera que les dossiers des «Jean Dupond». Si l attribut de livingsubjectname est fixé à SRCH, alors une recherche sur given = «Jean» et family= «Du» retournera tous les dossiers dont le nom et le prénom commencent par «Jean» et «Du» (Jean Dupond, Jean Durand ). ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

106 7 Accès sécurisé au DMP Recherche sur l adresse Par défaut, lorsque le critère «ville» (patientaddress/value/city) de l adresse du patient est fourni en entrée, le DMP effectue une recherche stricte sur la ville de l adresse. Si l attribut de patientaddress est fixé à SRCH, alors une recherche sur city = «Bor» retournera tous les dossiers dont la ville commencent par «Bor» (Bora Bora, Bordeaux ) Recherche sur le sexe Une recherche sur le critère sexe avec la valeur «F» (Féminin) ou «M» (Masculin) est étendue automatiquement par le DMP à la valeur «U» (sexe indéterminé) (i.e. une recherche sur «F» ou «M» retournera également les DMP des patients dont le sexe est à «U») Données en sortie La recherche est pour le moment restreinte à un maximum de 10 résultats : si le nombre de résultats à renvoyer dépasse le nombre maximum admissible par le DMP, la fonction renvoie une erreur DMPTooManyResult. En retour, le message HL7 V3 «Patient Registry Find Candidates Query Response» (interaction PRPA_IN201306UV02) est renvoyé. Note : Dans la version HL7 V utilisée dans cette transaction, le code de retour est positionné dans l élément : (au lieu de dans la version HL7 v3 2009). XPath HL7 Card. Valeur / remarque PRPA_IN201306UV02 [1..1] Racine du message [1..1] Fixé à «XML_1.0» Eléments «d entête» du message [ ] [1..1] Voir le chapitre structure commune des messages HL7 renvoyé par le DMP dans la partie «gestion administrative du dossier». controlactprocess [1..1] corps de la requête [1..1] Valeur fixée à [1..1] Valeur fixée à «EVN» code [1..1] [1..1] subject [0..N] Occurrence d un résultat de la réponse (un [1..1] Valeur fixé à [1..1] Valeur fixé à «false» registrationevent [1..1] Valeur fixée à [1..1] Valeur fixée à «EVN» [1..1] Valeur fixée à «active» subject1 [1..1] Valeur fixée à «SBJ» patient [1..1] ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

107 7 Accès sécurisé au DMP [1..1] Valeur fixée à «PAT» id [1..2] Identifiant(s) du patient : INS-A et/ou [1..1] pour INS-A pour [1..1] Valeur de l INS [1..1] Valeur fixée à «active» patientperson [1..1] Valeur fixée à [1..1] Valeur fixée à «INSTANCE» name [1..1] prefix [0..1] Civilité : Mr, Mme, Mlle [1..1] Nom usuel [0..1] Nom de naissance (nom de famille) given [1..1] Prénom [1..1] Sexe : M, F ou U [1..1] Date de naissance (format AAAAMMJJ) addr [0..1] Adresse du patient postalcode [0..1] Code postal city [0..1] Ville subjectof1 [1..1] Valeur fixée à «SBJ» querymatchobservation [1..1] Indicateur de correspondance du résultat (pourcentage de correpondance par rapport aux critères [1..1] Valeur fixée à [1..1] Valeur fixée à «EVN» [1..1] Pour le DMP : valeur fixée à «POURCENTAGE» value [1..1] Valeur fixée à [1..1] Valeur de la correspondance en % custodian [1..1] Organisation responsable de l identité patient fournie (le [1..1] Valeur fixée à «CST» assignedentity [1..1] Valeur fixée à «ASSIGNED» [1..1] OID du DMP : queryack [1..1] Indicateur de retour de l exécution du query queryid [1..1] Identifiant du query envoyé par le [1..1] root de l identifiant du query envoyé par le [1..1] extension de l identifiant du query envoyé par le LPS [1..1] Voir [IHE-PDQV3] Expected Actions : «OK» si le query retourne au moins un résultat «NF» si le query ne retourne aucun résultat [1..1] Nombre de résultats présents dans la réponse * [1..1] Nombre de résultats présents dans la réponse * [1..1] Nombre de résultats présents dans la réponse * querybyparameter [ ] [1..1] Query tel qu il est passé par le LPS en entrée * ces champs servent habituellement à la recherche incrémentale ; pour la première version du DMP, ils seront toujours affectés avec la valeur du nombre de résultat de la réponse courante. Tableau 39 : TD0.5 Structure du message en sortie ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

108 7 Accès sécurisé au DMP En cas de succès accusé de réception du traitement «ok» ; indicateur de retour «OK» si un ou plusieurs résultats retournés ou «NF» si aucun résultat retournés pour les critères passés ; réponse au format HL7 V3 contenant la liste des patients retournés (une ou plusieurs occurrences de controlactprocess/subject). E EX_ Le LPS doit afficher les deux noms retournés dans la réponse (nom d usage et nom de naissance), si deux noms sont renseignés (cas d une femme mariée par exemple) En cas d erreur En cas d erreur, la transaction retourne dans les éléments d entête du message (voir chapitre structuration commune des messages HL7 V3) : l accusé de réception du traitement en erreur un code un message d erreur (acknowledgementdetail/text). Voir annexe au 11.4 ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

109 7 Accès sécurisé au DMP 7.8 TD0.9 - Accès Web-PS Contextuel L accès Web-PS contextuel permet essentiellement au PS d accéder à des fonctionnalités non disponibles via les Web Services et correspondant généralement à des actions rares réservées au médecin traitant (voir tableau des droits fonctionnels au 7.3) : consultation des traces, blocage d un PS sur le DMP, Afin de simplifier l accès du PS à certaines fonctionnalités du DMP directement depuis le LPS, et en fonction du niveau d intégration de ces fonctionnalités dans le LPS lui-même, le LPS doit être en capacité d ouvrir une fenêtre navigateur internet sur une URL du DMP, en passant des éléments de contexte d utilisation (par exemple en passant le «contexte patient» au DMP). Gestion du passage de contexte REC_ R La fenêtre de navigateur peut être encapsulée dans le LPS (recommandation forte), ou lancée en «fenêtre externe» sous certaines contraintes décrites ci-dessous. Dans le cas où une fenêtre externe est ouverte dans un navigateur, le LPS doit s assurer qu il n existe pas, sur le poste de travail simultanément deux fenêtres DMP ouvertes de façon à éviter toute confusion entre «le patient local» au LPS et «le patient distant» sur le DMP. Cela peut être réalisé par exemple en plaçant une constante dans le nom de fenêtre lors de sa création (au sens DOM : window.name) Principes généraux Authentification du PS en Web-PS : L authentification du PS dans ce mode d appel est assurée par une connexion TLS mutuelle entre le navigateur et le serveur DMP. La gestion du canal TLS par carte CPS est transparente pour le LPS et intégrée au navigateur dès lors que la librairie cryptographique «CryptoLib» de l ASIP Santé est installée sur le poste du PS. Le code porteur est demandé lors de la première authentification via le navigateur et, selon les navigateurs, lorsque le navigateur est rouvert après fermeture. Configuration du poste de travail : Voir [DMP1-OS-NAVIGATEURS]. L outil de diagnostic mis à disposition par l ASIP Santé Un outil de diagnostic du poste de travail est également disponible à l adresse suivante : ; ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

110 7 Accès sécurisé au DMP Cet outil : réalise un diagnostic du poste couvrant l ensemble des prérequis pour l accès Web PS du service DMP, puis installe les composants nécessaires en tenant compte des exigences suivantes : o Automatiser le processus lorsque plusieurs étapes sont nécessaires, o Ne pas impliquer l utilisateur dans les opérations de configuration technique, o o Poste fonctionnel en fin d installation sans avoir à redémarrer, Permet de revenir à la configuration antérieure si l utilisateur rencontre des problèmes suite à la mise à jour (1 clic). Navigation : La navigation dans le Web PS se fait au moyen d onglets (par exemple «Paramétrage» ou «DMP de xxx») et de sous onglets (par exemple «Documents») qui sont affichés sous forme de bandeau dans la partie haute de l écran. Sur la figure ci-après représentant l arborescence du Web PS, les onglets et sous onglets sont présentés dans des rectangles. C est à ce niveau de l arborescence de l AW PS que conduit le passage de contexte. Fig. 40 : Arborescence du site Web PS ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

111 7 Accès sécurisé au DMP Des niveaux supplémentaires de navigation sont disponibles, généralement affichés sous forme de menus sur la partie gauche de la page affichée par le Web PS : le passage de contexte conduira systématiquement sur le premier menu correspondant à l onglet ou sous onglet appelé (par exemple l appel de contexte «Paramétrage» amènera sur le menu «Mes informations») ; pour accéder à un autre menu ou sous menu (par exemple pour accéder au menu «Adresse de réception des alertes» le PS peut utiliser le menu de gauche et cliquer sur le menu correspondant. Note : Un utilisateur authentifié avec une carte CPE ne pourra accéder qu aux URL Tableau de bord et Gestion du DMP, conformément au tableau des droits fonctionnels présenté en ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

112 Accès sécurisé au DMP Synthèse avec les transactions LPS Le tableau ci-dessous permet de mettre en rapport les transactions DMP des LPS et les URL disponibles pour le passage de contexte. TD0.9 Accès Web-PS contextuel D = accès direct I = étape intermédiaire requise ACCES SECURISE AU DMP TD0.2 Test d'existence d'un DMP D TD0.3 Mise à jour de l'autorisation D TD0.4 Liste des dossiers autorisés D CREATION ET GESTION ADMINISTRATIVE DU DMP TD1.1 Création d'un DMP I D TD1.2 Réactivation d'un DMP I TD1.3 Mise à jour des données administratives d'un DMP D TD1.4 Fermeture d'un DMP I TD1.5 Accès Internet du patient I TD1.6 Liste des PS autorisés/bloqués sur un DMP I ALIMENTATION DU DMP TD2.1 Alimentation en documents d'un DMP I CONSULTATION DU DMP TD3.1 Recherche de documents sur un DMP D TD3.2 Consultation d un document sur un DMP D TD3.3 Gestion des attributs d'un document I SERVICES DU DMP DISPONIBLES EN ACCES WEB UNIQUEMENT Notifications : adresse de réception des alertes I Notifications : paramétrage des alertes sur un DMP I Traces d un DMP D Situation et cadre d'exercice I Préférences Accès Web I Demandes de copie partielle ou totale I Affichage documents sur " parcours de soins" Page "volontés et droits" du patient Tableau 41 : Correspondance entre transactions et URL de passage de contexte D D ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

113 7.8.3 Accès aux différentes fonctions Un LPS peut donc appeler 9 URL distinctes pour permettre au PS d accéder au Web PS, en transmettant un INS (représenté par [INS] dans la liste suivante) ou un ensemble de paramètres (représenté par [paramètres] dans la liste suivante) : La valeur de l URL de base (représenté par «nom de domaine» dans la liste suivante) dépend de l environnement : Environnement de production : Environnement de mise au point (développement, tests et homologation du LPS) : l éditeur utilisera uniquement l URL de base de l environnement DV que lui aura fourni l équipe DMP Compatibilité de l ASIP Santé. # Fonctionnalité url Liste des paramètres obligatoires Liste des paramètres optionnels de domaine/accesdirect/tableaudebord Accès au tableau de bord du 1 ou aucun professionnel de santé de domaine/accesdirect/tableaudebord/[ins] 2 Page d accueil du DMP d un patient de domaine/accesdirect/dossierpatient/[ins] INS du patient aucun INS du patient 3 Page d information du patient (données administratives) de domaine/accesdirect/gestiondmppatient/[ins] INS du patient aucun 4 Page de la liste des documents de domaine/accesdirect/documents/[ins] INS du patient aucun 5 Page du parcours de soins de domaine/accesdirect/parcoursdesoins/[ins] INS du patient aucun 6 Page d historique des accès d un DMP de domaine/accesdirect/historiqueacces/[ins] INS du patient aucun 7 Page de paramétrage du professionnel de santé de domaine/accesdirect/parametrages aucun aucun 8 Page du document volontés et souhaits du patient de domaine/accesdirect/volontesetdroits/[ins] INS du patient aucun 9 Page de création du DMP de domaine/accesdirect/creationdmp/[paramètres] aucun voir Tableau 42 : Structure des url d accès direct ASIP Santé DSFT des interfaces DMP des LPS V /06/ / Accès sécurisé au DMP

114 7 Accès sécurisé au DMP EX_ E La mise en œuvre de la transaction TD0.9 passe à minima par l implémentation de l accès aux fonctionnalités «Accès au tableau de bord du professionnel de santé» et «Page d accueil du DMP d un patient». Les données en entrées des URL de passage de contexte doivent être respectées Tableau de bord ( de domaine/accesdirect/tableaudebord ou de domaine/accesdirect/tableaudebord/[ins]) L onglet «Tableau de bord» est la première page sur laquelle arrive le PS après s être authentifié. Dans le cas où l URL est fournie sans passer d INS en paramètres, la page lui permet : d afficher la liste des patients pour lesquels il dispose d une autorisation (équivalent à la transaction TD0.4 «Liste des dossiers autorisés») et d accéder à leur DMP ; de créer le DMP d un patient (équivalent à TD1.1 «Création d un DMP») il faut alors cliquer sur le bouton Carte Vitale pour déclencher le calcul de l INS-C ; de rechercher le DMP d'un patient à partir de son INS-C ou à partir de sa carte Vitale : o un test d existence (équivalent TD0.2 «Test d existence») est alors réalisé par l AW PS ; o un écran intitulé «Recherche de patient» présentant l état du DMP est affiché au PS ; o selon le statut du DMP, un lien permet au PS soit de le créer (équivalent à la transaction TD1.1 «Création d un DMP» si le DMP n existe pas), soit de le réactiver (équivalent à la transaction TD1.2 «Réactivation d un DMP» si le DMP est fermé), soit d accéder à ce DMP (DMP créé actif) après avoir déclaré ou confirmé son autorisation d accès à ce DMP. Si un LPS appelle le tableau de bord en passant un INS en paramètre, il arrive directement sur l écran affichant le résultat du test d existence, évitant ainsi au PS de ressaisir l INS du patient dans l accès Web PS. Les différentes actions que le PS pourra réaliser à ce stade (réactivation, fermeture, accès en consultation) dépendent de l état du dossier dans le SI DMP pour l INS-C passé en paramètre. Note : Si un PS demande à accéder à un DMP fermé, à un DMP qui n existe pas (non créé) ou à un DMP pour lequel il a été bloqué, sans passer par l URL «Tableau de bord» mais en utilisant une autre URL («DossierPatient», «Documents», «ParcoursDeSoins», «GestionDMPPatient», «HistoriqueAcces») un message d erreur lui sera affiché ainsi qu un lien lui permettant d accéder à la page «Tableau de bord». ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

115 7 Accès sécurisé au DMP Accueil DMP Patient ( de domaine/accesdirect/dossierpatient/[ins]) L onglet «DMP patient» permet au PS de visualiser la page d accueil du DMP du patient dont l INS-C a été fourni en paramètre et en particulier : de visualiser la liste des 5 derniers documents ajoutés par un PS / une STS dans ce DMP (depuis sa dernière connexion) et consultables par l utilisateur connecté en fonctions des règles de filtrage (rôle, matrice d habilitations, etc.) mises en place par le SI DMP ; d accéder à la liste de tous les documents de ce DMP ; d ajouter un nouveau document ; de visualiser la liste des derniers accès à ce DMP, en mode normal et en mode urgence (la transaction équivalente TD4.3 «Accès aux traces d un DMP» n est pas disponible pour la V1 du DMP) ; d accéder directement aux données du patient - date dernier accès à son DMP par le patient, fiche administrative patient, personnes à prévenir en cas d urgence, perte identifiant/mot de passe ; d accéder directement à la gestion du DMP - demande de copie, paramétrage des alertes du PS pour ce DMP (la transaction équivalente TD4.1 «Notification» n est pas disponible pour la V1 du DMP). Note : L utilisation d un passage de contexte avec en paramètre un INS-C pour lequel le PS ne possède pas d autorisation d accès conduira à une fenêtre demandant au PS de confirmer son autorisation (équivalent à la transaction TD0.3 «Mise à jour de l autorisation») puis à la page d accueil du DMP patient. Dans le cas d une authentification avec une CPE, dont les droits sont restreints à la création de DMP et à la mise à jour des données administratives du patient, la page d accueil n est pas accessible, seules les pages Informations patient et Autorisations > accès en urgence seront affichées. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

116 7 Accès sécurisé au DMP Gestion du DMP ( de domaine/accesdirect/ GestionDMPPatient/[INS]) L onglet «Gestion du DMP» permet au PS d effectuer sur ce DMP toutes les opérations de consultation et mise à jour des informations patient et des autorisations : consultation et mise à jour des informations patients (équivalent aux transactions TD1.3x «Mise à jour des données administratives d'un DMP») et des informations de connexion (équivalent aux transactions TD1.5b «Ajout d'un canal OTP au compte d'accès internet» et TD1.5d «Mise à jour des informations du compte internet») ; consultation et mise à jour des autorisations (équivalent à la transaction TD1.6 «Liste des PS autorisés/bloqués sur un DMP» avec des fonctionnalités supplémentaires par rapport au LPS pour permettre au MT de bloquer des PS à la demande du patient) ; paramétrage des alertes du PS concernant ce DMP (équivalent à la transaction TD4.1x «Notification» qui n est pas disponible pour la V1 du DMP) qui permet au PS de définir le type de document concernant ce patient pour lesquels il souhaite recevoir une alerte, l alerte sera alors envoyée sur le canal paramétré dans l onglet «Paramétrage» ; fermeture du DMP (équivalent à la transaction TD1.4 «Fermeture d un DMP») et demande de destruction du DMP (fonctionnalité spécifique Web PS) ; demande de copie (fonctionnalité spécifique Web PS) ; création d un compte d accès internet (équivalent à la transaction TD1.5a «Initialisation de l'accès internet du patient») Documents ( de domaine/accesdirect/documents/[ins]) L onglet «Documents» permet d afficher la liste de tous les documents du DMP du patient. Le PS peut filtrer cette liste par date, nom de l auteur, spécialité de l auteur, type de document, en incluant ou pas les documents archivés ou masqués (équivalent à la transaction TD3.1 «Recherche de documents sur un DMP»). Cliquer sur un document particulier permet au PS de consulter les métadonnées associées au document et le document lui-même (équivalent à la transaction TD3.2 «Consultation d un document»). La liste des documents affichés est évidemment restreinte aux seuls documents que le PS est habilité à consulter conformément à la matrice d habilitation du CI-SIS (voir [CI- PARTAGE] 4.1) et des droits associés à son profil (voir 7.3.2). ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

117 7 Accès sécurisé au DMP Parcours de soins ( de domaine/accesdirect/parcoursdesoins/[ins]) L onglet «Parcours de soins» permet d afficher au PS les documents du patient sous forme chronologique : les documents sont classés par rubrique (synthèse, traitement et soins, compterendu,..) ; le PS arrive par défaut sur l onglet «toute la période» et peut ensuite choisir le pas de l axe temporel le plus approprié (annuel, mensuel ou journalier). S il existe plusieurs documents dans une période (intersection période avec type de document) un clic sur la case ouvrira l onglet de la période inférieure, ceci jusqu à l affichage journalier qui permet la consultation du ou des documents. Il s agit donc d une représentation graphique particulière du résultat de la transaction TD3.1 «Recherche de documents sur un DMP». Les mêmes restrictions que celles appliquées à l onglet «Documents» sont appliquées à l onglet «Parcours de soins». R REC_ L ancienne URL de domaine/accesdirect/lignedevie/[ins] est toujours active et fonctionnelle pour rétrocompatibilité avec les LPS déjà homologués. Il est recommandé de mettre à jour cette URL et de renommer la fonctionnalité «Parcours de soins» dans le LPS Historique des accès ( de domaine/accesdirect/historiqueacces/[ins]) L onglet «Historique des accès» permet au PS de consulter les traces des dernières actions effectuées sur le dossier du patient : ces traces sont consultables en ligne pour une durée d un an ou de 100 traces dans le cas d un DMP sur lequel il y aurait peu d activité ; le MT peut consulter la totalité des traces du dossier ; les autres PS autorisés à accéder au dossier mais non MT ne peuvent consulter que la trace de leur propres actions sur le dossier. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

118 7 Accès sécurisé au DMP Paramétrages ( de domaine/accesdirect/parametrages) L onglet «Paramétrage» permet au PS de définir ses options de paramétrages, valables uniquement pour le site Web PS. Toute modification de ces options est prise en compte instantanément et conservée pour les accès ultérieurs au site Web PS. Le PS peut à tout moment revenir sur ces options. Plus précisément, l onglet «Paramétrages» permet au PS : de visualiser les informations le concernant déduites de sa carte CPx et de l annuaire CPS (page affichée au PS lorsqu il arrive sur l onglet «Paramétrage» depuis un LPS) ; de sélectionner la situation et le cadre d exercice présents sur sa carte CPS qui restreindront éventuellement l utilisation du SI-DMP (voir «Cadre d exercice) ou seront utilisés par défaut s il ajoute un document au DMP du patient ; de définir les paramètres d affichage des tableaux sur l accès Web PS (par exemple nombre de lignes par page, critères de tri et filtrage par défaut des listes de documents) ; de saisir une adresse pour la réception des alertes (la transaction équivalente TD4.1 «Notifications» n est pas disponible en V1) : courriel ou SMS. Un PS qui a plusieurs situations d exercice sur sa carte CPS doit sélectionner une situation d exercice par défaut avant de pouvoir utiliser le site Web PS. Quelle que soit l URL demandée par le passage de contexte, un PS qui n aura encore jamais utilisé le site Web PS et n aura donc pas sélectionné une situation d exercice par défaut, sera redirigé automatiquement sur cette page «Situation d exercice» pour faire sa sélection Document volontés et droits du patient ( de domaine/accesdirect/volontesetdroits/[ins]) Cette URL permet au PS d accéder directement au document décrivant les volontés et droits du patient. Cela permet de renseigner les coordonnées de : la personne de confiance du patient, la personne à prévenir en cas d urgence. Enfin, cela permet de signaler si le patient a été informé de la loi sur le don d organes. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

119 7 Accès sécurisé au DMP Création de DMP ( de domaine/accesdirect/creationdmp/[paramètres]) Cette url permet de lancer automatiquement la lecture de la carte Vitale et le calcul de l INS (sans clic sur le bouton «Lire la carte Vitale») et de passer en paramètre des informations déjà présentes dans le LPS afin de pré-renseigner des champs dans le processus de «Création du DMP» et d éviter ainsi à l utilisateur d avoir à ressaisir des informations qui seraient déjà connues dans le système appelant (adresse, téléphone, ). S il n y a qu un bénéficiaire sur la carte, l utilisateur est directement redirigé vers l écran «Création du DMP» étape «1/ Recueil du consentement», sans passage préalable par l écran «Personne(s) présentes sur la carte Vitale» où figure le lien «Créez le DMP». S il y a plusieurs bénéficiaires sur la carte (assuré ouvrant droit et un ayant droit par exemple), l enchaînement direct sur l écran «Création du DMP» comportant les champs pré-renseignés ne peut pas être réalisé. Dans ce cas l utilisateur est d abord redirigé sur la page de sélection du bénéficiaire parmi ceux présent sur la carte. La création du DMP se fera alors dans l accès Web PS du service DMP et les informations qui avaient éventuellement été passées par le LPS devront alors être de nouveau saisies. Les paramètres pouvant être passés à cette URL sont décrits dans le tableau ci-dessous. Paramètres Type Taille Card. Mot clé Description téléphone mobile A 10 [0..1] TELMOBILE= Téléphone mobile du patient adresse électronique A 64 [0..1] = Adresse électronique du patient adresse A 38 [0..1] ADRESSE= Adresse du patient adresse complémentaire A 38 [0..1] ADRESSECOMP= Adresse complémentaire du patient code postal A 5 [0..1] CODEPOSTAL= Code postal du patient Ville A 38 [0..1] VILLE= Ville du patient pays A 38 [0..1] PAYS= Pays du patient Tableau 43 : Structure des paramètres possibles pour la liste en entrée de l URL CreationDMP Ces paramètres sont envoyés sous la forme d une liste de paires «clé=valeur», chaque paramètre étant séparé par le séparateur. Le caractère de séparation des paramètres de la liste étant le, il n est pas autorisé dans la liste des paramètres. Le tout est ensuite encodé en base 64 et les caractères spéciaux liés au base 64 ( «+» et «/») sont remplacés respectivement par «-» et «_». Le(s) caractère(s) «=» de fin est (sont) supprimé(s). ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

120 7 Accès sécurisé au DMP Exemple d accès direct à la création du DMP : Adresse du patient en paramètre : ADRESSE=2 rue du bac VILLE=PARIS CODEPOSTAL=75020 Conversion en base 64 : QURSRVNTRT0yIHJ1ZSBkdSBiYWN8VklMTEU9UEFSSVN8Q09ERVBPU1RBTD03NTAyMA== Remplacer les éventuels «+» et «/» par «-» et «_» (respectivement) et supprimer les «=» de fin. QURSRVNTRT0yIHJ1ZSBkdSBiYWN8VklMTEU9UEFSSVN8Q09ERVBPU1RBTD03NTAyMA L URL final appelée est la suivante : SVN8Q09ERVBPU1RBTD03NTAyMA Cas d erreur possibles Une attention particulière est demandée sur les cas d erreur possibles pour cet appel contextuel décrit au tableau ci-dessous : Cas d erreur Traitement / résultat Capture d écran / Description Pas de carte vitale dans le lecteur Affichage de l erreur classique Texte affiché : «Erreur lors de la lecture de la carte Vitale» Format de la chaine base 64 incorrect Affichage de l erreur classique Texte affiché : «le format des données fournies est incorrect» Présence de plusieurs personnes sur la CV Aucun message d erreur, redirection vers la page de sélection de la personne sur la CV ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

121 7 Accès sécurisé au DMP Présence de 2 ayants droits sur la CV sans DMP Aucun message d erreur, redirection vers la page de sélection de la personne sur la CV Idem écran précédant avec «Créez le DMP» à la place de «Accédez au DMP» Le DMP du patient existe déjà Aucun message d erreur, on redirige vers la page de sélection de la personne sur la CV Aucun ayant droit sur la carte vitale Le DMP est fermé Aucun message d erreur, redirection vers la page sélection de la personne sur la CV Aucun message d erreur, redirection vers la page de sélection de la personne sur la CV Idem écran actuel en web PS Autre cas d erreur Affichage de l erreur classique Texte affiché : «Erreur générale non identifiée» Tableau 44 : Structure des paramètres possibles pour la liste en entrée de l URL CreationDMP ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

122 8 Création et gestion administrative du DMP 8 Création et gestion administrative du DMP 8.1 Les différents états d un DMP Fig. 45 : Diagramme de changement des états du DMP Si le DMP n existe pas Il est possible de le créer à condition de disposer d un INS-C calculé à partir de la carte Vitale. Si le DMP n existe pas, seules les transactions suivantes sont possibles : o TD0.2 «Test d existence d un DMP et vérification de l autorisation». o TD1.1 «Création d un DMP» ; Si le DMP est Actif Il est possible d utiliser ce DMP à condition de disposer de l accord du patient, et selon les règles d usage du DMP. Si le DMP est actif, toutes les transactions sont possibles à l exception des transactions suivantes : o TD1.1 «Création d un DMP» ; o TD1.2 «Réactivation d un DMP». ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

123 8 Création et gestion administrative du DMP Si le DMP est Fermé Si le DMP a été fermé à la demande du patient, il est possible de réactiver le DMP, toujours sur demande expresse du patient et à condition de disposer d un INS calculé à partir de la carte Vitale. Un dossier fermé est conservé pendant 10 ans. Au bout de ce délai, le dossier est détruit définitivement. Si le DMP est fermé, seules les transactions suivantes sont possibles : o TD0.2 «Test d existence d un DMP et vérification de l autorisation» ; o TD1.2 «Réactivation d un DMP». EX_1.X-1010 E La création du DMP nécessite au préalable de s assurer que le DMP n existe pas déjà, via TD0.2 «Test existence d un DMP et vérification de l autorisation». Si le résultat de la TD0.2 indique que le DMP n existe pas, alors le DMP peut être créé avec la TD1.1 «Création d un DMP». Si le résultat de la TD0.2 indique que le DMP est fermé, alors le DMP peut être réactivé avec la TD1.2 «Réactivation d un DMP». Destruction d un DMP Il n y a pas de transaction pour détruire définitivement le DMP. Le DMP est détruit définitivement à la demande du patient par le médecin de l hébergeur (le patient doit imprimer un formulaire et l envoyer au support DMP). Le DMP est détruit définitivement lorsqu il est fermé depuis plus de 10 ans. Rappel : les conditions de l utilisation de l INS sont rappelées au ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

124 8 Création et gestion administrative du DMP Début Arrivée du patient Patient créé dans le LPS INS non présent dans le LPS ou non associé à un DMP Le Patient dispose de sa carte Vitale Le poste est équipé d un lecteur fonctionnel NON Le Patient connait son INS NON Fin du scénario OUI OUI Lecture de la carte Calcul de l INS Stockage de l INS (Calculé depuis Vitale) Stockage (ou usage immédiat) des traits CV Saisie de l INS - Contrôle clé INS Stockage de l INS (Fourni par un tiers, à vérifier) TD0.2- Test Existence du DMP TD0.2- Test Existence du DMP Retour : DMP Existe Retour : DMP Existe NON Fin du scénario NON OUI Le Patient souhaite créer son DMP NON Contrôle de l identité du DMP par rapport à l identité du patient local OUI Fin du scénario Identité contrôlée OK NON Fin du scénario PROCESSUS DE CREATION DE DMP Fin Patient local, INS associé à un DMP OUI OUI Retour : DMP Actif NON OUI Fin Patient local, INS associé à un DMP DMP Fermé par le patient Le Patient souhaite réactiver son DMP NON Fin du scénario PROCESSUS DE REACTIVATION DE DMP Fin Patient local, INS associé à un DMP Fig. 46 : Accueil du patient ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

125 8 Création et gestion administrative du DMP 8.2 TD1.1 Création d un DMP Cette transaction permet de créer un DMP pour un patient Prérequis 1. Le PS ou la STS est authentifié (TD0.1) ; 2. L INS-C a été calculé à partir de la carte Vitale ; 3. Le DMP du patient n'existe pas : Vérification avec la TD0.2 «Test existence d un DMP et vérification de l autorisation». Le test d existence du DMP doit retourner que le DMP du patient n existe pas. Si le test d existence retourne que le DMP est fermé, le LPS peut proposer sa réactivation (voir 8.3 «Réactivation d un DMP») ; 4. Le patient souhaite créer son DMP Cinématique Début INS calculé depuis Vitale Traits Vitale présents Test Existence : DMP inexistant Le patient souhaite créer son DMP Saisie des informations Données administratives sur le patient Consentement du patient à la création de son DMP Consentement à autoriser l accès à son DMP * Aux centres de régulation des urgences * En bris de glace TD1.1- Création du DMP du patient Le patient souhaite activer son compte internet patient OUI NON PROCESSUS DE GESTION DE L ACCES PATIENT (INITIALISATION) Fin Patient local, INS associé à un DMP Fig. 47 : Création d un DMP ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

126 8 Création et gestion administrative du DMP Convention de représentation : [x] : Case à cocher, cochée. [ ] : Case à cocher, décochée. (x) : Bouton radio, coché. ( ) : Bouton radio, décoché Recueil du consentement du patient à la création de son DMP EX_ E Lors de la création du DMP du patient, le LPS doit proposer un élément graphique de type «case à cocher» (ou phrase cliquable, ou autre) à l utilisateur afin que celui-ci confirme qu il a bien recueilli le consentement du patient pour l ouverture de son DMP. Le statut «coché» de ce champ vaut recueil du consentement du patient par le PS et le LPS doit stocker cette information. Dans le cas où le PS n a pas recueilli le consentement du patient, le DMP ne doit pas être créé. Exemple possible de mise-en-œuvre : Le patient consent à la création de son DMP, créez le DMP REC_ R Une fois le test d existence du DMP réalisé, il est recommandé de poser la bonne question au patient en fonction du résultat : Si le DMP n existe pas : «Vous n avez pas de DMP, souhaitez-vous le créer?» Si le DMP est fermé, «Votre DMP est fermé, souhaitez-vous le réactiver?». REC_ R L éditeur, libre des choix ergonomiques pour son LPS, peut décider de faire, à chaque nouvel accès au dossier d un patient, le test d existence du DMP et de poser la question «Souhaitez-vous créer votre DMP?». Cependant, afin d éviter de reposer systématiquement la question à un patient qui ne souhaite pas de DMP, il est recommandé de stocker dans le LPS une date de refus de création de DMP. L auteur de la création est automatiquement autorisé par le système DMP à accéder au DMP du patient. Une autorisation d accès est donc créée : au PS en cas d authentification directe par CPS ; à la structure (STS) en cas d authentification indirecte. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

127 8 Création et gestion administrative du DMP Désignation comme Médecin Traitant par le patient EX_ E L option «Vous a désigné comme médecin traitant» ne doit être présentée qu aux médecins en authentification directe. Elle ne doit pas être présentée aux utilisateurs porteurs d une CPE ou après une authentification indirecte en STS. Si le PS a coché la case «Vous a désigné comme médecin traitant», le LPS devra lancer ensuite la TD0.3 pour positionner le PS comme médecin traitant dans le DMP. Exemple possible de mise-en-œuvre : [ ] Le patient vous a désigné comme médecin traitant Recueil du consentement du patient à l accès à son DMP en mode «centre de régulation» et en mode «bris de glace» EX_ E Lors de la création du DMP, les consentements du patient à l accès des PS en mode «centre de régulation» et «bris de glace» doivent être proposés à la saisie à l utilisateur sous forme de cases à cocher «cochées par défaut» : [x] Autorise, en cas d'appel au SAMU ou de tout centre 15, le médecin régulateur à accéder à son DMP [x] Autorise, s'il est dans un état comportant un risque immédiat pour sa santé, tout professionnel de santé à accéder à son DMP Activation du compte internet du patient A la suite de la création de son DMP, il est demandé au patient s il souhaite activer son compte internet qui va lui permettre de consulter et gérer son DMP depuis internet. Pour la description de la création du compte internet du patient, voir 8.6. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

128 8 Création et gestion administrative du DMP Transaction La transaction de création est décrite dans [CI-GESTPAT] Demande de création d un dossier, et utilise le message HL7 V3 Patient Registry Add Request (interaction PRPA_IN201311UV02) via un Web Service. L élément doit être positionné à «CREA_RD» (voir ) Données en entrée Les données requises en entrée de la fonction sont : les données administratives et de gestion du patient, telles que définies dans le : o L INS-C du patient ; o Les données administratives du patient (noms, prénoms, sexe, adresse, etc.) ; o Les données de la carte Vitale du patient ; o Le recueil du consentement patient à la création de son DMP ; o Le choix du patient pour les autorisations d accès en modes «bris de glace» et «centre de régulation» ; les données d identification du PS qui crée le DMP (voir 8.8.3). E EX_ Les informations issues de la carte Vitale (traits stricts) ne doivent pas être modifiées par le LPS même si elles sont différentes des traits d identité du patient ou si elles sont erronées. R REC_ Le représentant légal tel que défini au peut également être fourni si géré dans le LPS (optionnel). Afin de ne pas surcharger le processus de création de dossier, cette information peut être ajoutée en modification de données administratives. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

129 8 Création et gestion administrative du DMP Pour les autorisations d accès en mode «centre de régulation» et «bris de glace» Valable également pour la transaction de mise à jour des données administratives du DMP d un patient. EX_1.X-1110 E Le message HL7 V3 de création de DMP permet de manipuler des concepts «d opposition au mode bris de glace» et «d opposition du patient au mode centre de régulation». Il faut impérativement veiller à la cohérence de l information entre la question qui est posée à l utilisateur dans l IHM du logiciel et la valeur positionnée dans le message technique envoyé au SI DMP ; en effet la question posée dans l IHM peut parler d autorisation alors que le message parle d opposition, il faut donc s assurer que la réponse à la question posée dans l IHM est fidèlement retranscrite dans le message) ; par exemple : si la question posée dans le LPS est : «Le patient autorise, en cas d'appel au SAMU ou de tout centre 15, le médecin régulateur à accéder à son DMP» et que la réponse est positive alors dans le message OPPOSITION_ACCES_URGENCE est positionnée à «false», si la question posée dans le LPS est : «Le patient autorise, s'il est dans un état comportant un risque immédiat pour sa santé, tout professionnel de santé à accéder à son DMP» et que la réponse est négative alors dans le message OPPOSITION_BRIS_DE_GLACE est positionné à «true». Cette remarque est également valable pour la transaction de mise à jour des données administratives du DMP d un patient. Pour les champs de l adresse du patient Valable également pour la transaction de mise à jour des données administratives du DMP d un patient. REC_1.X-1120 R Dans la mesure où le nombre et la taille des champs servant à renseigner les informations d'adresse ne sont pas forcément les mêmes entre le LPS et le SI-DMP, il est recommandé que l éditeur s'assure que les valeurs transmises pour les champs d'adresse décrits aux et soient envoyées de sorte d'être clairement lisibles et intelligibles par un autre utilisateur du DMP (par exemple en Accès Web PS). EX_1.X-1130 E Dans le cas où le nombre de caractères saisis par l utilisateur du LPS excède la taille maximale des champs prévus dans le SI DMP, le LPS doit a minima afficher un message à l utilisateur l incitant à modifier les valeurs saisies afin que le nombre de caractères n excède pas celui prévu par le SI DMP. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

130 8 Création et gestion administrative du DMP E EX_1.X-1140 Il est à noter que l'adresse du patient n'est pas obligatoire dans le DMP (le patient n'est pas obligé de la donner). Le LPS doit la gérer, mais l adresse ne sera pas fournie dans tous les cas : elle peut ne pas être saisie par le PS si le patient ne la donne pas. Pour les dates de naissance Valable également pour la transaction de mise à jour des données administratives du DMP d un patient. Le LPS doit gérer les différents formats de la date de naissance lue en carte Vitale. Cas d une date de naissance lunaire Certaines cartes Vitales contiennent une date de naissance au format «lunaire» (mois > 12 et/ou jour > 31). R REC_1.X-1150 Il est fortement recommandé que le LPS transforme cette date au format standard pour la transmettre dans la «date de naissance de l état civil du patient» au format «AAAAMMJJ» - voir 8.8.4). E EX_1.X-1160 Dans le cas où le LPS transforme la date de naissance lunaire en date de naissance standard pour la transmettre au DMP, le LPS doit suivre les modalités décrites en annexe au «Règle AM_DLU». EX_1.X-1170 E Dans le cas où le LPS transforme la date de naissance lunaire en date de naissance standard et souhaite enregistrer cette date de naissance transformée dans le dossier local du patient, le LPS doit utiliser la date transformée selon la «Règle AM_DLU» transmise au DMP. Le LPS doit permettre à l'utilisateur d en modifier ensuite la valeur. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

131 8 Création et gestion administrative du DMP EX_ E En revanche, c est la valeur lue dans la carte vitale (non transformée au format standard) qui est transmise dans la «date de naissance lue dans la carte vitale» du format décrit au 8.8.4). Par ailleurs, si le LPS utilise un composant de lecture de la carte vitale renvoyant un format différent de «AAMMJJ», la date est mise au format AAMMJJ (sans modification des valeurs, c'est-à-dire que les éventuels jours et mois lunaires doivent être conservés.). Cas d une date de naissance sans siècle EX_1.X-1180 E La «date de naissance de l état civil du patient» doit être fournie au format «AAAAMMJJ» (voir 8.8.4), donc avec le siècle. L API de lecture de la carte Vitale, dans certains cas, retourne une date sans siècle. Le LPS doit alors utiliser la règle AM_DNA_SIECLE de calcul du siècle décrite en annexe au Note : L API de Lecture Vitale (généralement utilisée dans les STS) retourne dans certains cas une date de naissance sans siècle. La date de naissance retournée par l API diffère en fonction de ce qui est réellement stocké dans la carte Vitale du bénéficiaire : voir le manuel fonctionnel des API de lecture Vitale au chapitre «3 - Les données fonctionnelles de niveau Bénéficiaire» ou le manuel de programmation de ces mêmes API au chapitre «Annexe A Données Vitale» (champs <date> (JJMMAAAA) ou <dateencarte> (AAMMJJ)). Par contre, les API FSE ou SSV déterminent elles-mêmes le siècle de naissance. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

132 8 Création et gestion administrative du DMP Données en sortie Pour des contraintes liées aux Web Services (deux types d éléments XML possibles en réponse), le message de sortie sera englobé dans un wrapper <PRPA_IN201311UV02_Response> (voir WSDL associé) En cas de succès En cas de succès de la création du DMP, le message HL7 V3 «Patient Registry Add Request Accepted» (interaction PRPA_IN201312UV02) est renvoyé, avec les informations suivantes : accusé de réception du traitement «ok» (AA) ; données patient avec les champs suivant dans l élément controlactprocess/subject/registrationevent/subject1/patient : o INS du patient ; o traits d identité du patient : nom d usage ; nom de naissance si renseigné ; prénom En cas d erreur En cas d erreur de la création du DMP, le message HL7 V3 «Patient Registry Add Request Rejected» (interaction PRPA_IN201313UV02) est renvoyé, avec les informations suivantes : accusé de réception du traitement «erreur» (AE) avec le code erreur et message associé ; corps «controlactprocess» : o enregistrement controlactprocess/subject/registrationrequest/subject1/patient de la requête HL7 d origine ; o dont la valeur est «completed». Voir annexe au 11.4 ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

133 8 Création et gestion administrative du DMP 8.3 TD1.2 - Réactivation d un DMP Cette transaction permet de réactiver le DMP d un patient qui a été fermé Prérequis 1. Le PS ou la STS est authentifié (TD0.1) ; 2. L INS-C a été calculé à partir de la carte Vitale ; 3. Le DMP du patient existe : Vérification avec la TD0.2 «Test existence d un DMP et vérification de l autorisation». Le test d existence du DMP doit retourner que le DMP du patient existe et est fermé Cinématique Début INS calculé depuis Vitale Traits Vitale présents Test Existence : DMP fermé à la demande du patient Le patient souhaite réactiver son DMP Saisie des informations Données administratives sur le patient Consentement du patient à la réactivation de son DMP TD1.2 - Réactivation du DMP du patient Le patient souhaite activer son compte internet patient OUI NON PROCESSUS DE GESTION DE L ACCES PATIENT (ré)initialisation Fin Patient local, INS associé à un DMP Fig. 48 : Réactivation d un DMP ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

134 8 Création et gestion administrative du DMP EX_ E La présence de la carte Vitale n est pas absolument requise. L INS-C doit être présenté comme ayant été calculé avec la carte Vitale. Dans tous les cas, il est interdit de réactiver un DMP avec un INS obtenu d un tiers (non calculé à partir de la lecture de la carte Vitale). R REC_ S il est techniquement possible de calculer l INS antérieurement à la réactivation d un DMP, il est recommandé de proposer la réactivation du patient uniquement en présence de la carte Vitale Recueil du consentement du patient à la réactivation de son DMP EX_ E Lors de la réactivation du DMP du patient, le LPS doit proposer un élément graphique de type «case à cocher» (ou phrase cliquable, ou autre) à l utilisateur afin que celui-ci confirme qu il a bien recueilli le consentement du patient pour la réactivation de son DMP. Le statut «coché» de ce champ vaut recueil du consentement du patient par le PS et le LPS doit stocker cette information. Dans le cas où le PS n a pas recueilli le consentement du patient, le DMP ne doit pas être réactivé. Exemple possible de mise-en-œuvre : Patient : Thierry DUPONT Le patient consent à la réactivation de son DMP, réactivez le DMP REC_ R Il est recommandé à l éditeur de faire d abord le test d existence du DMP et en fonction du résultat, de poser la bonne question au patient : Si le DMP n existe pas : «Vous n avez pas de DMP, souhaitez-vous le créer?» Si le DMP est fermé, «Votre DMP est fermé, souhaitez-vous le réactiver?». ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

135 8 Création et gestion administrative du DMP REC_ R L éditeur, libre des choix ergonomiques pour son LPS, peut décider de faire, à chaque nouvel accès au dossier d un patient, le test d existence du DMP et de poser la question «Souhaitez-vous réactiver votre DMP?». Cependant, afin d éviter de reposer systématiquement la question à un patient qui ne souhaite pas réactiver son DMP, il est recommandé de stocker dans le LPS une date de refus de réactivation de DMP. L auteur de la réactivation du DMP est automatiquement autorisé par le système DMP à accéder au DMP du patient. Une autorisation d accès est donc créée : au PS en cas d authentification directe par CPS ; à la structure (STS) en cas d authentification indirecte. Dans le cas où le dossier a été fermé à la demande du patient, toutes les autorisations d accès précédant la fermeture ont été supprimées. La réactivation ne redonne pas les autorisations existantes avant la fermeture et seule l autorisation de l acteur ayant réactivé le DMP est recréée Désignation comme Médecin Traitant par le patient EX_ E L option «Vous a désigné comme médecin traitant» ne doit être présentée qu aux médecins en authentification directe. Elle ne doit pas être présentée aux utilisateurs porteurs d une CPE ou après une authentification indirecte en STS. Si le PS a coché la case «Vous a désigné comme médecin traitant», le LPS devra lancer ensuite la TD0.3 pour positionner le PS comme médecin traitant dans le DMP. Exemple possible de mise en œuvre : [ ] Le patient vous a désigné comme médecin traitant Activation du compte internet du patient A la suite de la réactivation de son DMP, il est demandé au patient s il souhaite activer son compte internet qui va lui permettre de consulter et gérer son DMP depuis internet. Pour la description de la création du compte internet du patient, voir 8.6. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

136 8 Création et gestion administrative du DMP Transaction La transaction de réactivation est décrite au du [CI-GESTPAT], et utilise le même message HL7 V3 «Patient Registry Revise Request» (interaction PRPA_IN201314UV02) que la fonction de modification des données administratives, mais avec un sous-ensemble des données patient. L élément doit être positionné à «REAC» (voir ) Données en entrée Les données en entrée de la fonction sont : l INS-C du patient (patient/id) ; le statut «actif» du patient ; au moins le nom et prénom du patient (caractère requis contraint par le message HL7) dans patient/patientperson/name, comme défini dans le ; consentement du patient à la réactivation de son DMP comme défini dans le ; données d identification du PS ayant réactivé le DMP (PS recueillant le consentement tel que défini au 8.8.3) Données en sortie Pour des contraintes liées aux Web Services (deux types d élément XML possibles en réponse), le message de sortie sera englobé dans un wrapper <PRPA_IN201314UV02_Response> (voir WSDL associé) En cas de succès En cas de succès de la transaction, le message HL7 V3 «Patient Registry Revise Request Accepted» (interaction PRPA_IN201315UV02) est renvoyé En cas d erreur En cas d erreur de la transaction, le message HL7 V3 «Patient Registry Revise Request Rejected» (interaction PRPA_IN201316UV02) est renvoyé. Voir annexe au 11.4 ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

137 8 Création et gestion administrative du DMP 8.4 TD1.3 Mise à jour des données administratives La transaction TD1.3 permet de gérer les informations administratives du patient Prérequis 1. Le PS ou la STS est authentifié (TD0.1) ; 2. Le DMP du patient existe et le PS (ou la STS) est autorisé à y accéder : Vérification avec la TD0.2 «Test existence d un DMP et vérification de l autorisation» Cinématique EX_ E Pour modifier les données administratives du DMP d un patient : Etape 1 : Le LPS doit récupérer les données administratives du DMP à partir de l INS. Pour cela, il doit appeler la fonction de récupération des données administratives et de gestion (transaction TD1.3a). Etape 2 : Le LPS affiche les données du patient récupérées du DMP et le PS les modifient dans le LPS Etape 3 : Le LPS envoie les mises à jour au DMP (transaction TD1.3b) Consultation des données administratives et de gestion La transaction TD1.3a permet de récupérer la dernière version des données administratives et de gestion d un DMP Transaction La transaction est décrite au du [CI-GESTPAT] «Consultation de données de gestion de dossier». L élément doit être positionné à «CNSLT_DATA» (voir ) Données en entrée La transaction TD1.3a est quasiment identique à la transaction TD0.2 «Test d existence et vérification de l autorisation» décrite au Seuls les prérequis et les données renvoyées par le DMP diffèrent Données en sortie La transaction TD1.3a est quasiment identique à la transaction TD0.2 «Test d existence et vérification de l autorisation» décrite au Seuls les prérequis et les données renvoyées par le DMP diffèrent. Contrairement au test d existence, si le DMP est fermé, aucune donnée patient n est renvoyée (seul un code erreur est renvoyé). ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

138 8 Création et gestion administrative du DMP En cas de succès accusé de réception du traitement «ok» (AA) ; les données administratives du patient sont renseignées dans l élément pointé par le chemin XPath controlactprocess/subject/registrationevent/subject1/patient, comme indiqué dans le ; Les données suivantes (non modifiables) ne sont cependant pas renvoyées : o données de la carte Vitale ; o recueil du consentement patient à l'ouverture DMP ; s il a été positionné dans le DMP du patient, les données du représentant légal sont renvoyées (dans : controlactprocess/subject/registrationevent/subject1/patient/patientperson/personalr elationship, puis détails dans le «Représentant légal du patient») En cas d erreur En cas d erreur de la transaction, un code et un message d erreur sont renvoyés dans le message. Voir annexe au Modification des données administratives et de gestion Cette fonction TD1.3b permet la modification des données administratives et de gestion d un DMP à partir des données modifiées par le PS dans le LPS. Les informations modifiables sont : les données d identification du patient ; les coordonnées du patient ; Le choix du patient pour les autorisations d accès en modes «bris de glace» et «centre de régulation». Les informations suivantes ne sont pas modifiables : données de la carte Vitale ; données liées au recueil de consentement du patient à la création ou à la réactivation de son DMP. E EX_ Les LPS ne doivent pas réaliser une mise à jour automatique des données administratives : toute mise à jour doit être réalisée à l initiative du PS en toute connaissance de cause. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

139 8 Création et gestion administrative du DMP Dans le SI DMP, le téléphone mobile et l adresse électronique des données administratives sont les mêmes que ceux utilisés pour l envoi du mot de passe à usage unique. Donc la mise à jour du téléphone mobile et l adresse électronique peut se faire avec la transaction TD1.3b ou avec la transaction TD1.5b. Il n est pas possible de supprimer (effacer) les données administratives « » et «téléphone mobile» si le patient possède un compte internet patient. Le SI DMP retourne une erreur «DMPInvalidData» dans ce cas Transaction La transaction de modification des données administratives et de gestion est décrite au du [CI-GESTPAT] et utilise le message HL7 V3 «Patient Registry Revise Request» (interaction PRPA_IN201314UV02) via un Web Service. L élément doit être positionné à «MODIF_DATA» (voir ) Données en entrée les données administratives et de gestion sont définies au ; le représentant légal du patient peut être positionné via cette transaction (dans controlactprocess/subject/registrationrequest/subject1/patient/patientperson/person alrelationship, puis détails dans le «Représentant légal du patient»). E EX_ Le LPS doit suivre les règles de modification / effacement de données définies dans [CI- GESTPAT] au «Règles de gestion particulières». En particulier, un champ non connu ne doit pas être envoyé vide car cela risque d effacer la donnée existante dans le DMP. Pour les autorisations d accès en mode «bris de glace» et «centre de régulation» Les exigences et recommandations décrites dans le TD1.1 s appliquent. Pour les champs d adresse du patient Les exigences et recommandations décrites dans le TD1.1 s appliquent. Pour les dates de naissance Les exigences et recommandations décrites dans le TD1.1 s appliquent. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

140 8 Création et gestion administrative du DMP Données en sortie Pour des contraintes liées aux Web Services (deux types d élément XML possibles en réponse), le message de sortie sera englobé dans un wrapper < PRPA_IN201314UV02_Response> (voir WSDL associé) En cas de succès En cas de succès de la transaction, le message HL7 V3 «Patient Registry Revise Request Accepted» (interaction PRPA_IN201315UV02) est renvoyé En cas d erreur En cas d erreur de la transaction, le message HL7 V3 «Patient Registry Revise Request Rejected» (interaction PRPA_IN201316UV02) est renvoyé. Voir annexe au ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

141 8 Création et gestion administrative du DMP 8.5 TD1.4 Fermeture du DMP Cette transaction permet de fermer un DMP Prérequis 1. Le PS est authentifié (TD0.1) ; 2. Le DMP du patient existe et le PS est autorisé à y accéder : Vérification avec la TD0.2 «Test existence d un DMP et vérification de l autorisation» Cinématique Le PS sélectionne le motif de la fermeture du DMP dans une liste et peut saisir un commentaire pour expliciter les raisons de la fermeture. EX_ E E Actuellement, cette liste ne contient qu un seul motif «A la demande du patient» (code motif de fermeture = «FERMETURE_DEMANDE_PATIENT») mais elle peut évoluer. L éditeur doit prévoir une procédure simple permettant d intégrer une mise à jour de la liste des motifs, sans avoir à intégrer une nouvelle version du logiciel. EX_ Le motif de fermeture est obligatoire. A la fermeture d un DMP, toutes les autorisations d accès sur ce DMP passent à l état «expiré». Un DMP fermé peut être réactivé (voir 8.3 «Réactivation du DMP d un patient»). Cependant, les anciennes autorisations d accès ne sont pas recréées lors de la réactivation du DMP. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

142 8 Création et gestion administrative du DMP Transaction Elle est décrite au du [CI-GESTPAT], et utilise le même message HL7 V3 «Patient Registry Revise Request» (interaction PRPA_IN201314UV02) que la fonction de modification des données administratives, mais avec un sous-ensemble des données patient. L élément doit être positionné à «FERM» (voir ) Données en entrée Les données en entrée de la fonction sont : l INS du patient (patient/id) ; le statut fermé du patient ; au moins un nom et prénom du patient (caractère requis contraint par le message HL7) dans patient/patientperson/name, comme défini dans le 8.8.4) ; le motif de la fermeture, dans l élément controlactprocess/reasonof : Nom du champ Card. XPath HL7 Remarques Motif de la fermeture [1..1] reasonof/detectedissueevent codification du motif [1..1] Code code motif de fermeture Celui correspondant au motif code de la nomenclature valeur fixe : Commentaire du patient [0..1] text Texte libre Tableau 49 : Structure du motif de fermeture d un DMP données d identification du PS ayant fermé le DMP (PS recueillant le consentement tel que défini au 8.8.3) Données en sortie Pour des contraintes liées aux Web Services (deux types d élément XML possibles en réponse), le message de sortie sera englobé dans un wrapper <PRPA_IN201314UV02_Response> (voir WSDL associé) En cas de succès En cas de succès de la transaction, le message HL7 V3 «Patient Registry Revise Request Accepted» (interaction PRPA_IN201315UV02) est renvoyé En cas d erreur En cas d erreur de la transaction, le message HL7 V3 «Patient Registry Revise Request Rejected» (interaction PRPA_IN201316UV02) est renvoyé. Voir annexe au 11.4 ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

143 8 Création et gestion administrative du DMP 8.6 TD1.5 Accès Internet du Patient La transaction TD1.5 permet de gérer le compte internet du patient et en particulier : La transaction TD1.5a permet à un PS de créer le compte internet du patient afin que celui-ci puisse se connecter sur son DMP ; La transaction TD1.5b permet à un PS d ajouter ou modifier un canal OTP ; La transaction TD1.5d permet le déblocage du compte internet patient et la régénération des paramètres de connexion du patient. Le compte internet du patient lui permet de consulter et gérer son DMP depuis internet. Pour cette transaction, on désigne sous le même terme de «patient» le patient lui-même ou son représentant légal dans le cas d un mineur ou d un majeur incapable. Un seul compte internet est créé au nom du patient et l on ne distingue pas la personne qui y accède. Etats du compte internet du patient Le compte internet du patient peut être : inactif ; initialisé (par un PS) ; activé (par le patient) ; bloqué (par le système si erreur de mot de passe). L activation du compte internet ne peut être effectuée que par le patient-lui-même lors de son premier accès, et ne peut pas être effectuée à partir du LPS Prérequis 1. Le PS ou la STS est authentifié (TD0.1) ; 2. Le DMP du patient existe et le PS (ou la STS) est autorisé à y accéder : Vérification avec la TD0.2 «Test existence d un DMP et vérification de l autorisation». ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

144 8 Création et gestion administrative du DMP Cinématique Début DMP existant Suite à création, réactivation Ou indépendamment Le patient souhaite initialiser son compte Sélection ou ajout de canal/canaux OTP TD1.5a - Création du compte patient Erreur: compte patient préexistant NON Plusieurs canaux OTP OUI OUI Le patient souhaite réinitialiser son compte patient car il a perdu ses paramètres de connexion OUI NON Fin du scénario TD1.5b - Gestion des canaux OTP (ajout) GESTION DE L ACCES PATIENT Réinitialisation du compte patient NON Retour : Login et mot de passe permanents du patient Impression du login et du mot de passe Pour le patient Fin Compte Patient initialisé Fig. 50 : Initialisation du compte patient ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

145 8 Création et gestion administrative du DMP EX_ E A la suite de la création ou de la réactivation de son DMP, le LPS doit proposer de créer le compte internet du patient. Si le patient donne son accord, le LPS permet d enchainer la création ou la réactivation du DMP et la création du compte internet du patient. L activation du compte internet peut aussi se faire indépendamment des actions de création ou de réactivation, sur simple demande du patient. Exemple possible de mise-en-œuvre : Compte d'accès DMP du patient : [x] Le patient souhaite activer son compte internet pour accéder à son DMP. Lorsque le patient souhaite activer son compte internet, le LPS doit afficher l écran qui permet de saisir le numéro de téléphone ou l adresse électronique (canal OTP) sur lesquels il désire recevoir son mot de passe à usage unique (OTP). Exemple possible de mise-en-œuvre : Mode d'accès du patient à son DMP : Pour des raisons de sécurité, les patients qui désirent accéder à leur DMP par Internet doivent saisir à chaque connexion un mot de passe à usage unique qui leur est envoyé sur leur téléphone mobile ou sur leur adresse électronique. Modes de réception du mot de passe à usage unique : - Téléphone mobile du patient (10 chiffres sans espace) : [ ] - Adresse électronique du patient : [ ] Il est possible que ces données soient déjà présentes dans le LPS. Le recueil des numéros de téléphone ou de l adresse électronique du patient peut avoir été réalisé en amont dans une «fiche administrative» au sein du LPS (saisie de l adresse, numéros de téléphone, etc ). Dans ce cas, le LPS pourra récupérer les valeurs déjà connues pour le patient. E EX_ Le LPS doit permettre de revenir sur cette fonction pour modifier ou ajouter le numéro de téléphone ou l adresse électronique du patient. Exemple possible de mise-en-œuvre : Mode de réception du mot de passe à usage unique. [Modifier] ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

146 8 Création et gestion administrative du DMP Génération du «document des secrets du patient» E EX_ Le LPS qui met en œuvre les transactions TD1.5a «Création du compte internet patient» et TD1.5d «Mise à jour des informations du compte internet Patient» doit être en mesure de générer un «document des secrets du patient» tel que défini ci-après. Le «document des secrets du patient» contient les données de connexion du patient sur une page en 2 parties à découper : o La 1ère partie de la page contient : La date de création du compte internet patient, L identité du patient (civilité, prénom et nom) L INS du patient L identifiant de connexion du patient o La 2ème partie de la page contient : Le mot de passe du patient. L éditeur peut choisir entre 2 méthodes pour générer ce document des secrets du patient : 1) la méthode standard : le LPS peuple un formulaire PDF «standard» au format A4 défini et fourni par l ASIP Santé. Les modalités de récupération du «modèle standard» sont définies ci-après. 2) une méthode alternative : le LPS peuple un document élaboré par l éditeur. Le document élaboré par l éditeur doit respecter les spécifications décrites dans le document [CHARTE-DOC-SECRETS]. L utilisation de cette méthode doit être motivée (par exemple, pas d impression au format A4) et l information fournie à l ASIP Santé par l éditeur. Modalités de récupération du modèle du formulaire standard Le modèle du formulaire standard est disponible en téléchargement sur une URL référencée dans un fichier XML disponible à l URL fixe Le fichier XML contient les informations sur la dernière version du modèle : Paramètre version date_maj url hash Signification Version du modèle du formulaire PDF Date de mise à jour du modèle du formulaire au format YYYYMMDDhhmmss URL de téléchargement de la dernière version du modèle du formulaire Checksum MD5 du modèle du formulaire PDF afin que le LPS puisse éventuellement vérifier l intégrité du fichier téléchargé Tableau 51 : Paramètres de téléchargement du modèle de formulaire patient ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

147 8 Création et gestion administrative du DMP Exemple : <?xml version="1.0" encoding="utf-8"?> <dmp-parameters version="1.0"> <parameter-list code="param-formulaire-patient"> <parameter code="version" value="4.0.0" /> <parameter code="date_maj" value=" " /> <parameter code="url" value=" /> <parameter code="hash" value="1419fcbeddf7246fd a299b39c" /> </parameter-list> </dmp-parameters> E EX_ Si le LPS utilise le formulaire standard fourni pas l ASIP Santé, il doit vérifier au minimum une fois par semaine qu il dispose de la dernière version du modèle de formulaire. E EX_ Toute nouvelle version du formulaire doit être déployée de manière transparente pour l utilisateur dans les 5 jours ouvrés suivant sa mise à disposition par l ASIP Santé. R REC_ Afin que le déploiement d une nouvelle version du modèle soit simple et rapide, il est recommandé à l éditeur de mettre en place un mécanisme de «live update». Note : Les modifications qui seront apportées au modèle de formulaire ne toucheront que le texte ou sa présentation, mais pas le nombre ou le nom des champs. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

148 8 Création et gestion administrative du DMP Modalités de remplissage du formulaire avec les données du patient E EX_ Le LPS doit remplir automatiquement les champs de type «Text Field» du formulaire PDF avec les données du patient comme indiqué dans le tableau ci-dessous. Nom du champ Donnée à renseigner Civilité, Prénom, NOM Civilité (optionnelle), prénom et nom du patient séparés par un espace INS INS du patient (avec la clé) Date Date de création du compte internet patient Identifiant Identifiant du patient (récupéré via la TD1.5) Password Temporaire Mot de passe temporaire du patient (récupéré via la TD1.5) Tableau 52 : liste des champs «Text Field» du modèle de formulaire patient E EX_ Le LPS ne doit pas permettre à l utilisateur de modifier les informations fournies dans le formulaire contenant les paramètres de connexion du patient. E EX_ Le LPS ne doit pas stocker l identifiant de connexion et le mot de passe initial du patient sous quelque forme que ce soit et sur quelque support que ce soit. Modalités de remise du document des secrets au patient Le document des secrets du patient lui est remis en main propre ou envoyé par courrier. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

149 8 Création et gestion administrative du DMP Création du compte internet patient Cette transaction TD1.5a permet de créer le compte internet patient. Elle est implémentée par un Web Service spécifique au DMP Données en entrée Les données en entrée de la fonction sont : l INS du patient passé dans le VIHF ; les données du canal OTP (Type /Canal). Fig. 53 : TD1.5a - Diagramme de classes des données en entrée Nom du champ Type Taille Card Description Règle de gestion Données de création accès Patient : OTP principal Type Enum - [1..1] Canal A 50 [1..1] Code du type de canal OTP Valeur du canal OTP. Représente soit une adresse mél, soit un numéro de téléphone Valeurs : SMS ou En fonction du type de canal, le système vérifie si la valeur du canal est au format correspondant : Uniquement des chiffres pour un numéro de téléphone Un format d standard Tableau 54 : TD1.5a Données en entrée Les SMS ne peuvent être émis qu'à destination de téléphones portables commençant par 06 ou 07 (ils ne peuvent pas être émis vers des numéros de téléphones fixes) Données en sortie Les données en sortie de la fonction sont : l identifiant / mot de passe ; l accusé de réception du traitement. ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

150 8 Création et gestion administrative du DMP Fig. 55 : TD1.5a - Diagramme de classes des données en sortie Le détail concernant les données de l accusé de réception du traitement est le suivant : Nom du champ Type Taille Card Description status A 50 [1..1] Code de retour : DMPOk (en cas de succès), ou code d erreur (en cas d erreur) context A text [0..1] Message d erreur (en cas d erreur) Tableau 56 : TD1.5a Accusé de réception de traitement En cas de succès Le champ status de l accusé de réception du traitement prend la valeur «DMPOk». Le détail concernant les données de l accès patient renvoyées est le suivant : Nom du champ Type Taille Card Description Login A 50 [1..1] Identifiant de l utilisateur pour son accès Patient Password A 50 [1..1] Mot de passe de l utilisateur généré par le DMP Tableau 57 : TD1.5a Données en sortie En cas d erreur Le champ statut de l accusé de réception du traitement contient un code erreur et le champ contexte un message associé. Voir annexe au 11.4 ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

151 8 Création et gestion administrative du DMP Ajout de canal OTP Cette transaction TD1.5b permet d ajouter/modifier/supprimer un canal OTP sur un DMP dont l accès patient a été initialisé. Cette transaction peut être appelée indépendamment de la création du compte internet patient, dans le cas où le patient souhaiterait changer son canal OTP. Elle est implémentée par un Web Service spécifique au DMP. Rappel : Dans le SI DMP, le téléphone mobile et l adresse électronique des données administratives sont les mêmes que ceux utilisés pour l envoi du mot de passe à usage unique. Donc la mise à jour du téléphone mobile et l adresse électronique peut se faire avec la transaction TD1.3b ou avec la transaction TD1.5b Données en entrée Les données en entrée de cette fonction sont : l INS du patient passé dans le VIHF ; les données du canal OTP (Type /Canal/Default/Action). Fig. 58 : TD1.5b - Diagramme de classes des données en entrée Nom du champ Type Taille Card Description Règle de gestion OTP Type Enum - [1..1] Canal A 50 [0..1] Action Enum - [1..1] Code du type de canal OTP Valeur du canal OTP : - soit une adresse mél, - soit un numéro de téléphone Code d action à effectuer Valeurs : SMS ou Si l action est une suppression, cette donnée n est pas vérifiée En fonction du type de canal, le système vérifie si la valeur du canal est au format correspondant : o o Uniquement des chiffres pour un numéro de téléphone Un format d standard Valeurs : o AJOUT o MODIFICATION o SUPPRESSION Tableau 59 : TD1.5b Données en entrée ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

152 8 Création et gestion administrative du DMP Pour un DMP, il ne peut y avoir qu une seule valeur par type de canal OTP. Les SMS ne peuvent être émis qu'à destination de téléphones portables français sur 10 chiffres (à ce jour ces numéros commencent par 06 ou 07) et pas de téléphones fixes. R REC_ Il est recommandé d afficher la règle concernant le numéro de téléphone destiné à recevoir l OTP par SMS (numéro sur 10 chiffres commençant par 06 ou 07) à l utilisateur du LPS, afin d éviter la non-réception de l OTP par le patient Données en sortie Les données en sortie de la fonction sont : l accusé de réception du traitement. Fig. 60 : TD1.5a - Diagramme de classes des données en sortie Le détail concernant les données de l accusé de réception du traitement est le suivant : Nom du champ Type Taille Card Description status A 50 [1..1] Code de retour : DMPOk (en cas de succès), ou code d erreur (en cas d erreur) context A text [0..1] Message d erreur (en cas d erreur) En cas de succès Tableau 61 : TD1.5b Accusé de réception de traitement Le champ status de l accusé de réception du traitement prend la valeur «DMPOk» En cas d erreur Le champ status de l accusé de réception du traitement contient un code erreur et le champ contexte un message associé. Voir annexe au ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

153 8 Création et gestion administrative du DMP Activation du compte internet par le patient Une fois le compte internet initialisé, le patient active son compte internet en y accédant une première fois. Le fonctionnement de l accès internet du Patient à son DMP est le suivant : le patient accède à la page de connexion du DMP sur le site dmp.gouv.fr ; il saisit son identifiant de connexion et son mot de passe (1) ; s il a indiqué son numéro de téléphone et son adresse électronique, il sélectionne le canal sur lequel il souhaite recevoir son mot de passe à usage unique ; il reçoit alors un message (SMS sur portable ou sur messagerie électronique) avec son mot de passe à usage unique ; il saisit ensuite son mot de passe à usage unique pour accéder à son DMP. (1) Lors de sa première connexion, le patient doit saisir son «mot de passe initial» qui lui a été fourni sur le formulaire des secrets. Il lui sera demandé de remplacer ce mot de passe initial par un mot de passe («permanent») de son choix qu il saisira lors des connexions suivantes Déblocage du compte internet ou mise à jour des codes internet Si le patient se trompe trois fois de mot de passe, son compte internet est bloqué. Dans ce cas, le Patient peut demander à un PS de débloquer son compte. La transaction TD1.5d permet le déblocage d un compte internet patient bloqué, et peut également servir à fournir à nouveau ses paramètres de connexion à un patient qui les aurait perdus. Cette transaction est implémentée par un Web Service spécifique au DMP. Début DMP existant Le patient a bloqué son compte d accès TD1.5d - Mise à jour du compte patient (régénération) Retour : Login et mot de passe permanents du patient Impression du login et nouveau mot de passe Pour le patient Fin Le Patient dispose de ses informations de connexion Fig. 62 : Réinitialisation du compte d accès patient ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

154 8 Création et gestion administrative du DMP Données en entrée Les données en entrée de cette fonction sont : l INS du patient passé dans le VIHF (la transaction updatepatientaccess ne prend donc aucun paramètre en entrée). Fig. 63 : TD1.5d - Diagramme de classes des données en entrée Données en sortie Les données en sortie de la fonction sont : l identifiant / mot de passe ; l accusé de réception du traitement. Fig. 64 : TD1.5d - Diagramme de classes des données en sortie Le détail concernant les données de l accusé de réception du traitement est le suivant : Nom du champ Type Taille Card Description status A 50 [1..1] Code de retour : DMPOk (en cas de succès), ou code d erreur (en cas d erreur) context A text [0..1] Message d erreur (en cas d erreur) Tableau 65 : TD1.5d Accusé de réception de traitement Le détail concernant les données de l accès patient est le suivant : Nom du champ Type Taille Card Description Login A 50 [1..1] Identifiant de l utilisateur pour son accès Patient Password A 50 [1..1] Mot de passe de l utilisateur En cas de succès Tableau 66 : TD1.5d Données en sortie Le champ status de l accusé de réception du traitement prend la valeur «DMPOk» En cas d erreur Le champ status de l accusé de réception du traitement contient un code erreur et le champ contexte un message associé. Voir annexe au 11.4 ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

155 8 Création et gestion administrative du DMP 8.7 TD1.6 - Liste des PS autorisés / bloqués sur un DMP La transaction TD1.6 retourne, pour un DMP donné (à partir de son INS), la liste des PS et STS ayant ou ayant eu une autorisation sur ce DMP avec son statut (autorisé ou bloqué) et l indication «Médecin traitant» si c est le cas (pour les PS uniquement). Le LPS peut ne demander que la liste des PS autorisés (mode = «ACTIVE»), que la liste des PS bloqués (mode = «INTERDITE») ou les 2 (mode = «TOUTE») Prérequis 1. Le PS est authentifié (TD0.1) ; 2. Le DMP du patient existe et le PS est autorisé à y accéder : Vérification avec la TD0.2 «Test existence d un DMP et vérification de l autorisation» Cinématique 1. le PS sélectionne le type de recherche qu il souhaite effectuer : Acteurs autorisés, Acteurs bloqués, ou les 2 ; 2. le LPS envoie la requête au DMP ; 3. le DMP envoie le résultat de la recherche au LPS Transaction Données en entrée Fig. 67 : Diagramme de classes en entrée Note : L INS du patient est passé dans le VIHF. Nom du champ Type Card Description mode Enum [1..1] ACTIVE : PS autorisés INTERDITE : PS bloqués TOUTE : PS autorisés et PS bloqués Tableau 68 : TD1.6 Données en entrée ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

156 8 Création et gestion administrative du DMP Données en sortie Fig. 69 : Diagramme de classe en sortie Le détail concernant les données en sortie est le suivant : Accusé de réception du traitement : Nom du champ Type Taille Card Description status A 50 [1..1] Code de retour : DMPOk (en cas de succès), ou code d erreur (en cas d erreur) context A text [0..1] Message d erreur (en cas d erreur) Tableau 70 : TD1.6 Accusé de réception du traitement ASIP Santé DSFT des interfaces DMP des LPS V /06/ / 250

Le Dossier Médical Personnel

Le Dossier Médical Personnel Le Dossier Médical Personnel Présentation du DMP Vidéo 2 Le DMP : c est parti! En 2011, les premiers pas du DMP > Accès pour les professionnels de santé via leur logiciel homologué «DMP-compatible» (web

Plus en détail

PLUS ON EN SAIT MIEUX ON SE PORTE. Utiliser le Dossier Médical Personnel en EHPAD

PLUS ON EN SAIT MIEUX ON SE PORTE. Utiliser le Dossier Médical Personnel en EHPAD PLUS ON EN SAIT MIEUX ON SE PORTE Utiliser le Dossier Médical Personnel en EHPAD Mai 2013 1 2 S informer sur le DMP Préparer votre q ALIMENTATION établissement Sur le site dmp.gouv.fr espace Structure

Plus en détail

Le Dossier Médical Personnel et la sécurité

Le Dossier Médical Personnel et la sécurité FICHE PRATIQUE JUIN 2011 Le Dossier Médical Personnel et la sécurité www.dmp.gouv.fr L essentiel Un des défis majeurs pour la réussite du Dossier Médical Personnel (DMP) est de créer la confiance des utilisateurs

Plus en détail

Ce document est la propriété du Groupe CEGEDIM. Il ne peut être ni reproduit, ni communiqué à des tiers sans autorisation écrite d une personne

Ce document est la propriété du Groupe CEGEDIM. Il ne peut être ni reproduit, ni communiqué à des tiers sans autorisation écrite d une personne Ce document est la propriété du Groupe CEGEDIM. Il ne peut être ni reproduit, ni communiqué à des tiers sans autorisation écrite d une personne mandatée à cet effet par ledit Groupe CEGEDIM. Table des

Plus en détail

PLUS ON EN SAIT MIEUX ON SE PORTE. Utiliser le Dossier Médical Personnel en EHPAD

PLUS ON EN SAIT MIEUX ON SE PORTE. Utiliser le Dossier Médical Personnel en EHPAD PLUS ON EN SIT MIEUX ON SE PORTE Utiliser le Dossier Médical Personnel en EHPD Mars 01 Le Dossier Médical Personnel : pour améliorer la prise en charge des résidents Depuis 008, les établissements d hébergement

Plus en détail

SI des établissements Impact des référentiels d interopérabilité et de sécurité de l ASIP Santé

SI des établissements Impact des référentiels d interopérabilité et de sécurité de l ASIP Santé SI des établissements Impact des référentiels d interopérabilité et de sécurité de l ASIP Santé Jean-François Parguet Directeur pôle Référentiels Architecture & Sécurité de l ASIP Santé Sommaire Dématérialisation

Plus en détail

Point d actualité DMP et Messageries Sécurisées de Santé

Point d actualité DMP et Messageries Sécurisées de Santé Point d actualité DMP et Messageries Sécurisées de Santé Assemblée Générale GCS Télésanté Basse Normandie 26 mars 2014 Anne Bertaud Pole Territoire Dossier Médical Personnel 2 DMP : quelques chiffres (février

Plus en détail

Livret aide-mémoire LE DOSSIER MÉDICAL PERSONNEL (DMP) EN PICARDIE

Livret aide-mémoire LE DOSSIER MÉDICAL PERSONNEL (DMP) EN PICARDIE Livret aide-mémoire Secrétaires médicales LE DOSSIER MÉDICAL PERSONNEL (DMP) EN PICARDIE 1 Le présent livret vise à : Former les secrétaires médicales à l information et la promotion du DMP auprès des

Plus en détail

La télémédecine en action

La télémédecine en action La télémédecine en action Recommandations pour la mise en œuvre d un projet de télémédecine Déploiement technique : Urbanisation et infrastructure ANAP Jeudi 10 mai 2012 Bruno Grossin ASIP Santé Recommandations

Plus en détail

PLUS ON EN SAIT MIEUX ON SE PORTE FACILITER LA PRISE EN CHARGE ET LA COORDINATION DES SOINS. dmp.gouv.fr

PLUS ON EN SAIT MIEUX ON SE PORTE FACILITER LA PRISE EN CHARGE ET LA COORDINATION DES SOINS. dmp.gouv.fr PLUS ON EN SAIT MIEUX ON SE PORTE FACILITER LA PRISE EN CHARGE ET LA COORDINATION DES SOINS dmp.gouv.fr Le Dossier Médical Personnel (DMP) est une réalité. Il est entré dans sa phase de déploiement. Pour

Plus en détail

MSSanté, la garantie d échanger en toute confiance. Mieux comprendre. MSSanté FAQ. Juin 2013 / V1

MSSanté, la garantie d échanger en toute confiance. Mieux comprendre. MSSanté FAQ. Juin 2013 / V1 MSSanté, la garantie d échanger en toute confiance Mieux comprendre MSSanté FAQ Juin 2013 / V1 FAQ MSSanté MSSanté, la garantie d échanger en toute confiance sommaire 1. Le Système MSSanté 2 MSSanté :

Plus en détail

Projet de Système d Information National (SIN) SAMU Grippe A H1N1 / Déploiement dans les SAMU Centre 15

Projet de Système d Information National (SIN) SAMU Grippe A H1N1 / Déploiement dans les SAMU Centre 15 Projet de Système d Information National (SIN) SAMU Grippe A H1N1 Déploiement dans les SAMU-Centre 15 Mission de préfiguration ASIP 9, rue Georges Pitard 75 015 Paris Tél 01 58 45 32 50 Fax 01 58 45 33

Plus en détail

Présentation du DMP. Dossier Médical Personnel

Présentation du DMP. Dossier Médical Personnel Dossier Médical Personnel Définition C est un dossier médical, informatisé et sécurisé Accessible depuis les LGC DMP-Compatibles Accessible également sur internet C est un service public et gratuit. Il

Plus en détail

Le DMP et vos droits Dossier Médical Personnel

Le DMP et vos droits Dossier Médical Personnel BROChURE D information PATIENT Le DMP et vos droits Dossier Médical Personnel Créer votre DMP, un acte important pour votre santé au service de la santé www.dmp.gouv.fr 2 Le dmp et vos droits 4 Qu est-ce

Plus en détail

Le numerique S investir? Pourquoi et comment? Atelier Professionnels de Santé 17 septembre 2015 de 16h00 à 16h45

Le numerique S investir? Pourquoi et comment? Atelier Professionnels de Santé 17 septembre 2015 de 16h00 à 16h45 Le numerique S investir? Pourquoi et comment? Atelier Professionnels de Santé 17 septembre 2015 de 16h00 à 16h45 Prise en charge pluri-professionnelle Besoins forts de coordination Radiologue, biologiste

Plus en détail

Agrément des Hébergeurs de données de Santé Exemple d Audit de conformité Sécurité et Technique «ASIP Santé»

Agrément des Hébergeurs de données de Santé Exemple d Audit de conformité Sécurité et Technique «ASIP Santé» Agrément des Hébergeurs de données de Santé Exemple d Audit de conformité Sécurité et Technique «ASIP Santé» Sommaire 1 Glossaire et abréviations... 3 1.1 Glossaire... 3 1.2 Abréviations... 3 2 Liminaire...

Plus en détail

ASIP Santé DSFT des interfaces MSSanté des LPS v0.9.0 06/05/2013

ASIP Santé DSFT des interfaces MSSanté des LPS v0.9.0 06/05/2013 Identification du document Référence ASIP Santé MSS_FON_DSFT_des_interfaces_MSSanté_130506_v0.9.0.pdf Date de dernière mise à jour 06/05/13 Classification Non sensible public Nombre de pages 76 Historique

Plus en détail

L impact du programme de relance sur le projet régional 19/05/2009 COPIL AMOA 1

L impact du programme de relance sur le projet régional 19/05/2009 COPIL AMOA 1 L impact du programme de relance sur le projet régional 19/05/2009 COPIL AMOA 1 L Identifiant National Santé (INS) Delphin HENAFF-DARRAUD Point du programme sur l INS Le constat L absence d identifiant

Plus en détail

La solution IdéoSanté une suite Web 2.0

La solution IdéoSanté une suite Web 2.0 La solution IdéoSanté une suite Web 2.0 SQLI et la santé : Une Histoire Des engagements dans la durée Etapes clés de l industrialisation de la suite Idéo santé Conseil SIS MOA, Urbanisation Réseaux de

Plus en détail

Le Dossier Médical Personnel (DMP) Aspects pratiques, déploiement et informations utiles

Le Dossier Médical Personnel (DMP) Aspects pratiques, déploiement et informations utiles Le Dossier Médical Personnel (DMP) Aspects pratiques, déploiement et informations utiles PLAN Principes d'utilisation Le DMP en pratique : Interface Web et LGCs Le DMP illustré : un exemple de prise en

Plus en détail

Manuel d utilisation du terminal de paiement électronique virtuel

Manuel d utilisation du terminal de paiement électronique virtuel TPEV Manuel d utilisation du terminal de paiement électronique virtuel Version: 1.C Payline PROPRIETAIRE Page 1-1/29 Page des évolutions Le tableau ci-dessous liste les dernières modifications effectuées

Plus en détail

PLUS ON EN SAIT MIEUX ON SE PORTE BROCHURE D INFORMATION PATIENT MON DOSSIER MÉDICAL PERSONNEL ET MOI. dmp.gouv.fr

PLUS ON EN SAIT MIEUX ON SE PORTE BROCHURE D INFORMATION PATIENT MON DOSSIER MÉDICAL PERSONNEL ET MOI. dmp.gouv.fr PLUS ON EN SAIT MIEUX ON SE PORTE BROCHURE D INFORMATION PATIENT MON DOSSIER MÉDICAL PERSONNEL ET MOI dmp.gouv.fr Les pratiques médicales évoluent continuellement pour permettre à chacun d être mieux soigné

Plus en détail

professionnelles Un espace de confiance commun pour toutes les messageries Décideurs en établissement de santé

professionnelles Un espace de confiance commun pour toutes les messageries Décideurs en établissement de santé MSSanté, la garantie d échanger en toute confiance Un espace de confiance commun pour toutes les messageries professionnelles Décideurs en établissement de santé Pourquoi sécuriser les échanges dans l

Plus en détail

MSS_FON_DSFT_Opérateurs_MSSanté_v1_0_0.PDF. Non sensible public

MSS_FON_DSFT_Opérateurs_MSSanté_v1_0_0.PDF. Non sensible public Identification du document Référence ASIP Santé MSS_FON_DSFT_Opérateurs_MSSanté_v1_0_0.PDF Date de dernière mise à jour 19/03/2014 Classification Non sensible public Nombre de pages 155 Historique du document

Plus en détail

Présentation éditeurs MCS ASIP Santé - Jeudi 5 Avril 2016

Présentation éditeurs MCS ASIP Santé - Jeudi 5 Avril 2016 Présentation éditeurs MCS ASIP Santé - Jeudi 5 Avril 2016 Edouard BRIS: Chef de projet MSSanté Mathilde SABOURIN: Chef de projet MSSanté Compatibilité Mai 2013 Sommaire Introduction I. Rappels des concepts

Plus en détail

Règlement du label «Logiciel Maison et Centre de santé»

Règlement du label «Logiciel Maison et Centre de santé» Règlement du label «Logiciel Maison et Centre de santé» 1 Candidats éligibles Version n 3.0 du 15/10/2014 La procédure de labellisation est ouverte à toute personne morale propriétaire d une solution logicielle

Plus en détail

CPS CPS CPS CARTE DE PROFESSIONNEL CARTE DE PROFESSIONNEL CHIRURGIEN-DENTISTE ORDRE NATIONAL DES SAGES-FEMMES. www.ordres-sante.

CPS CPS CPS CARTE DE PROFESSIONNEL CARTE DE PROFESSIONNEL CHIRURGIEN-DENTISTE ORDRE NATIONAL DES SAGES-FEMMES. www.ordres-sante. MÉDECIN S CARTE Votre carte professionnellee pour de nouveaux services es en toute confiance. FESSIONNEL ANTÉ MASSEUR- KINÉSITHÉRAPEUTE PÉDICURE-PODOLOGUE SAN S DE SANTÉ PHARMACIEN INFIRMIER(E) DES PÉDICURES-PODOLOGUES

Plus en détail

PLATEFORME DES ACHATS DE L ANFH CÔTÉ PRESTATAIRES. Version juin 2014

PLATEFORME DES ACHATS DE L ANFH CÔTÉ PRESTATAIRES. Version juin 2014 PLATEFORME DES ACHATS DE L ANFH CÔTÉ PRESTATAIRES Version juin 2014 SOMMAIRE 1. Première connexion, inscription de l entreprise sur la plateforme... 4 Compte de mon Entreprise... 6 Rubrique «Identification

Plus en détail

DMP1 DSFT des Interfaces DMP des LPS Annexe : complément de spécification sur l impression des documents à remettre au patient

DMP1 DSFT des Interfaces DMP des LPS Annexe : complément de spécification sur l impression des documents à remettre au patient DMP1 DSFT des Interfaces DMP des LPS Annexe : complément de spécification sur l impression des documents à remettre au patient Identification du document Référence Date de dernière mise à jour 30/06/11

Plus en détail

PLATEFORME DE GESTION DE CONGRÈS SCIENTIFIQUES

PLATEFORME DE GESTION DE CONGRÈS SCIENTIFIQUES PLATEFORME DE GESTION DE CONGRÈS SCIENTIFIQUES ANF Sciencesconf Meudon 10/11 octobre 2013 http://www.sciencesconf.org ! Sommaire La plateforme Sciencesconf.org Le portail L espace conférence Site web Gestion

Plus en détail

Vote électronique par internet : check-list

Vote électronique par internet : check-list Vote électronique par internet : check-list La «check-list» est un outil à destination des organisateurs des élections : IA-DSDEN chefs d établissement responsables de service IEN directeurs d école Elle

Plus en détail

Référentiel Général de Sécurité. version 1.0. Annexe A4

Référentiel Général de Sécurité. version 1.0. Annexe A4 Premier ministre Agence nationale de la sécurité des systèmes d information Ministère du budget, des comptes publics et de la réforme de l État Direction générale de la modernisation de l État Référentiel

Plus en détail

Archives et factures électroniques

Archives et factures électroniques Archives et factures électroniques Edito En 2001, le Conseil de l Union Européenne a publié la Directive 2001/115/CE relative à la facturation. Son objectif était de simplifier, de moderniser et d harmoniser

Plus en détail

NOTICE TELESERVICES : Déclarer la liasse IS

NOTICE TELESERVICES : Déclarer la liasse IS NOTICE TELESERVICES : Déclarer la liasse IS Sommaire Sommaire... 1 Objet de la notice... 2 A qui s adresse cette notice?... 2 Pré-requis... 2 Le guide pas à pas pour saisir et transmettre une déclaration

Plus en détail

CPS CPS CPS CARTE DE PROFESSIONNEL CARTE DE PROFESSIONNEL CHIRURGIEN-DENTISTE ORDRE NATIONAL DES SAGES-FEMMES. www.ordres-sante.fr

CPS CPS CPS CARTE DE PROFESSIONNEL CARTE DE PROFESSIONNEL CHIRURGIEN-DENTISTE ORDRE NATIONAL DES SAGES-FEMMES. www.ordres-sante.fr MÉDECIN SAGE-FEMME S CARTE Votre carte professionnellee pour de nouveaux services es en toute confiance. FESSIONNEL ANTÉ MASSEUR- KINÉSITHÉRAPEUTE PÉDICURE-PODOLOGUE SAN S DE SANTÉ PHARMACIEN INFIRMIER(E)

Plus en détail

OASIS est une fabrique à bien commun via l utilisation des applications proposées sur son store.

OASIS est une fabrique à bien commun via l utilisation des applications proposées sur son store. Guide Utilisateur 1.1 Présentation d OASIS OASIS est une fabrique à bien commun via l utilisation des applications proposées sur son store. Grâce à OASIS, vous serez capable d acheter ou de choisir des

Plus en détail

Directives sur la gestion des dossiers (DGD)

Directives sur la gestion des dossiers (DGD) Guides des mesures organisationnelles et techniques mises en œuvre auprès des caisses de compensation et des offices AI (recommandation) Date 25.01.2013 Auteurs U. Rüttimann / R. Bieri Nom de fichier WAF

Plus en détail

Référentiels pour les SI de santé. Point de situation, évolutions, maintenance

Référentiels pour les SI de santé. Point de situation, évolutions, maintenance Référentiels pour les SI de santé Point de situation, évolutions, maintenance 8 février 2011 Référence : Référentiels ASIP - JNI Rédacteur : ASIP/PRAS Version : v 1.0.0 Classification : non sensible /

Plus en détail

Créer les conditions de l interopérabilité entre les systèmes et pour les dossiers partagés

Créer les conditions de l interopérabilité entre les systèmes et pour les dossiers partagés Créer les conditions l interopérabilité entre les systèmes et pour les dossiers partagés Le Cadre d Interopérabilité Séminaire du 13 avril 2010 Connectathon Européen - Boraux Des référentiels d interopérabilité

Plus en détail

Homologation, référencement,. Gestion des incidents de sécurité. lundi 23 avril 2012

Homologation, référencement,. Gestion des incidents de sécurité. lundi 23 avril 2012 Homologation, référencement,. Gestion des incidents de sécurité lundi 23 avril 2012 Ordre du jour Gestion de de la sécurité à l ASIP Le pilotage de la sécurité à l ASIP La PSI L organisation Retour d expérience

Plus en détail

CHECKLIST : OUVERTURE DES OFFRES

CHECKLIST : OUVERTURE DES OFFRES CHECKLIST : OUVERTURE DES OFFRES 1 Introduction 2 De quoi avez-vous besoin? 2.1 La configuration minimale 2.2 La solution intermédiaire (recommandée) 2.3 La configuration maximale 3 Comment préparer un

Plus en détail

PLATEFORME DE GESTION DE CONGRÈS SCIENTIFIQUES

PLATEFORME DE GESTION DE CONGRÈS SCIENTIFIQUES PLATEFORME DE GESTION DE CONGRÈS SCIENTIFIQUES 7 avril 2014 ! Sommaire La plateforme Sciencesconf.org Le portail L espace conférence Site web Gestion scientifique Dépôt, sélection, envoi de mails, édition

Plus en détail

La Télémédecine dans le cadre de la Plateforme Régionale Santé de Martinique

La Télémédecine dans le cadre de la Plateforme Régionale Santé de Martinique + La Télémédecine dans le cadre de la Plateforme Régionale Santé de Martinique 15 ème Conférence des Fédérations Hospitalières des Antilles et de la Guyane Y. MARIE-SAINTE Directeur 28/04/2011 V1.0 + #

Plus en détail

UNIVERSITE DE LORRAINE CALCIUM

UNIVERSITE DE LORRAINE CALCIUM UNIVERSITE DE LORRAINE CALCIUM Outil pour la gestion des dossiers médicaux des étudiants dans les services universitaires de médecine préventive Table des matières CALCIUM... 0 I. L INFORMATION GÉRÉE PAR

Plus en détail

GCS e-santé Picardie. PROJET BUREAUTIQUE SANTE Présentation Juin 2012

GCS e-santé Picardie. PROJET BUREAUTIQUE SANTE Présentation Juin 2012 GCS e-santé Picardie PROJET BUREAUTIQUE SANTE Présentation Juin 2012 Sommaire Présentation du GCS e-santé Picardie Présentation du projet La solution La démarche et les services proposés La convention

Plus en détail

Dossier Médical Personnel une réalité partagée en Alsace!

Dossier Médical Personnel une réalité partagée en Alsace! Dossier Médical Personnel une réalité partagée en Alsace! Mardi 14 Février 2012 L accompagnement des professionnels de santé sur le terrain M. Gaston STEINER directeur d Alsace e-santé(gcs) Le DMP, socle

Plus en détail

Maîtriser le backend

Maîtriser le backend 4 Maîtriser le backend Les nouveaux utilisateurs de Magento sont souvent impressionnés par la qualité de son interface d administration, mais ils en redoutent aussi la richesse fonctionnelle. Connaître

Plus en détail

ÉTUDES Labellisation des solutions pour SIH Programme Hôpital Numérique

ÉTUDES Labellisation des solutions pour SIH Programme Hôpital Numérique ÉTUDES Labellisation des solutions pour SIH Programme Hôpital Numérique RIR 2 octobre 2014 CONTEXTE Programme Hôpital Numérique Vers un système d information hospitalier cohérent et performant Améliorer

Plus en détail

Conditions d'utilisation 1. Applicabilité et informations juridiques

Conditions d'utilisation 1. Applicabilité et informations juridiques Conditions d'utilisation 1. Applicabilité et informations juridiques Votre accès au site web www.drogistenverband.ch et à ses pages signifie que vous avez compris et accepté les conditions d utilisation

Plus en détail

La Révolution Numérique Au Service De l'hôpital de demain. 18-19 JUIN 2013 Strasbourg, FRANCE

La Révolution Numérique Au Service De l'hôpital de demain. 18-19 JUIN 2013 Strasbourg, FRANCE La Révolution Numérique Au Service De l'hôpital de demain 18-19 JUIN 2013 Strasbourg, FRANCE Le développement de la e-santé : un cadre juridique et fonctionnel qui s adapte au partage Jeanne BOSSI Secrétaire

Plus en détail

Réseau ISO-Raisin. Surveillance des. Infections du Site Opératoire. (Surveillance des interventions prioritaires)

Réseau ISO-Raisin. Surveillance des. Infections du Site Opératoire. (Surveillance des interventions prioritaires) Réseau ISO-Raisin Surveillance des Infections du Site Opératoire (Surveillance des interventions prioritaires) Guide d utilisation de l application WEBISO Année 2015 Sommaire Guide utilisateur - Application

Plus en détail

Coordination des soins, DCC: des projets structurants pour la e-santé. Quels impacts pour les éditeurs?

Coordination des soins, DCC: des projets structurants pour la e-santé. Quels impacts pour les éditeurs? Coordination des soins, : des projets structurants pour la e-santé. Quels impacts pour les éditeurs? Journée Nationale des Industriels 15 novembre 2012 Favoriser l échange et le partage d information médicale

Plus en détail

Référentiel Général de Sécurité. version 1.0. Annexe A3

Référentiel Général de Sécurité. version 1.0. Annexe A3 Premier ministre Agence nationale de la sécurité des systèmes d information Ministère du budget, des comptes publics et de la réforme de l État Direction générale de la modernisation de l État Référentiel

Plus en détail

Guide d utilisateur e-mandataire et e-citoyen

Guide d utilisateur e-mandataire et e-citoyen République du Sénégal ---.. Secrétariat général de la Présidence de la République.. Agence De l Informatique de l Etat Dématérialisation de la procédure de Demande d Autorisation de Construire Guide d

Plus en détail

UserLock Quoi de neuf dans UserLock? Version 8.5

UserLock Quoi de neuf dans UserLock? Version 8.5 UserLock Quoi de neuf dans UserLock? Version 8.5 Table des Matières 1. UserLock Version 8... 3 1.1. Le Statut utilisateur, un nouvel indicateur de risque... 3 1.2. Des alertes en temps réel contre les

Plus en détail

Gestion de documents. Découvrez HYDMedia. Système de gestion électronique de documents médicaux

Gestion de documents. Découvrez HYDMedia. Système de gestion électronique de documents médicaux Gestion de documents Découvrez HYDMedia Système de gestion électronique de documents médicaux Découvrez HYDMedia HYDMedia d Agfa HealthCare permet aux hôpitaux et aux établissements de soins de toute taille

Plus en détail

La e-santé pour communiquer

La e-santé pour communiquer GCS e-santé BRETAGNE Professionnels de la santé, du médico-social, en structure ou en libéral... La e-santé pour communiquer Présentation des services e-santé en Bretagne BIPS², réseau très haut débit

Plus en détail

Circuit d'assistance à la DSI

Circuit d'assistance à la DSI Centre national de la recherche scientifique Direction des systèmes d'information REFERENTIEL QUALITE Procédure Qualité Circuit d'assistance à la DSI Référence : CNRS/DSI/conduite-projet/exploitation-utilisation/technique/proc-circuitAU

Plus en détail

Plateforme Systempay. Intégration du module de paiement pour la plateforme VIRTUEMART 2.0 et supérieur PAIEMENT UNITAIRE Version 1.

Plateforme Systempay. Intégration du module de paiement pour la plateforme VIRTUEMART 2.0 et supérieur PAIEMENT UNITAIRE Version 1. Plateforme Systempay Intégration du module de paiement pour la plateforme VIRTUEMART 2.0 et supérieur PAIEMENT UNITAIRE Version 1.2a Rédaction, Vérification, Approbation Rédaction Vérification Approbation

Plus en détail

Conditions Générales d'utilisation - YOUSIGN SAS - SIGN2 CA

Conditions Générales d'utilisation - YOUSIGN SAS - SIGN2 CA Conditions Générales d'utilisation - YOUSIGN SAS - SIGN2 CA 1- Introduction 1.1 Présentation générale Ce document définit les Conditions Générales d Utilisation (CGU) des certificats délivrés dans le cadre

Plus en détail

Guide technique EDI TDFC : Les Etats Comptables et Fiscaux et Sage DirectDéclaration

Guide technique EDI TDFC : Les Etats Comptables et Fiscaux et Sage DirectDéclaration Guide technique EDI TDFC : Les Etats Comptables et Fiscaux et Sage DirectDéclaration Ce guide a pour vocation de vous aider dans la génération et l envoi de votre déclaration fiscale au format EDI-TDFC

Plus en détail

ALICO MAILDOC. Sommaire

ALICO MAILDOC. Sommaire 2 Sommaire 1 Page d accueil 3 1.1 Connexion à votre espace privé 3 1.1.1 Vous disposez déjà de vos codes d accès 3 1.1.2 Votre compte n est pas encore créé 3 2 Espace privé 4 2.1 Page d accueil de votre

Plus en détail

Etude et développement d un moteur de recherche

Etude et développement d un moteur de recherche Ministère de l Education Nationale Université de Montpellier II Projet informatique FLIN607 Etude et développement d un moteur de recherche Spécifications fonctionnelles Interface utilisateur Responsable

Plus en détail

Sage Business Sync. Guide d utilisation. 2012 Sage

Sage Business Sync. Guide d utilisation. 2012 Sage Sage Business Sync Guide d utilisation 2012 Sage Propriété & Usage Tout usage, représentation ou reproduction intégral ou partiel, fait sans le consentement de Sage est illicite (Loi du 11 Mars 1957 -

Plus en détail

Chorus Factures, solution de dématérialisation fiscale des factures. Kit de communication à destination des fournisseurs. Version 2.0.

Chorus Factures, solution de dématérialisation fiscale des factures. Kit de communication à destination des fournisseurs. Version 2.0. Chorus Factures, solution de dématérialisation fiscale des Kit de communication à destination des fournisseurs Version 2.0 Réf : SOMMAIRE Introduction Enjeux de la dématérialisation fiscale des Description

Plus en détail

Cadre régional d urbanisation des SIPS en Pays de la Loire

Cadre régional d urbanisation des SIPS en Pays de la Loire Cadre régional d urbanisation des SIPS en Pays de la Loire L urbanisation Construire un système d information qui réponde à un usage identifié, qui soit cohérent et adaptable dans le temps. Démarche :

Plus en détail

2e édition Mai 2012 www.dmp.gouv.fr

2e édition Mai 2012 www.dmp.gouv.fr GUIDE PRATIQUE DU PROJET DMP EN ÉTABLISSEMENT DE SANTÉ 2e édition Mai 2012 www.dmp.gouv.fr 2 - GUIDE PRATIQUE DU PROJET DMP EN ÉTABLISSEMENT DE SANTÉ INTRODUCTION 4 1 LES ENJEUX DU DMP EN ÉTABLISSEMENT

Plus en détail

Processus d achat PCard

Processus d achat PCard SOMMAIRE Introduction... 3 Connexion à l espace client... 3 Accès au site internet... 3 Identification... 3 Choix du fournisseur... 5 Page d accueil... 5 Choix du point de livraison... 6 Mes informations...

Plus en détail

H2012 : Cahier des charges

H2012 : Cahier des charges H2012 : Cahier des charges Présentation COPIL régional 28/10/2010 ES 1 Rappel de la démarche ES 1 ES 3 Cartographie du SI ES 37 Définition du contexte de mise en œuvre dans chaque ES ES 1 ES 1 ES 3 ES

Plus en détail

ASIP Santé ASIP- Architectures de systèmes éligibles aux échanges avec le DMP v1 1 1 11/08/14. Date Commentaires Visa

ASIP Santé ASIP- Architectures de systèmes éligibles aux échanges avec le DMP v1 1 1 11/08/14. Date Commentaires Visa Documents de référence Voir chapitre 6 pour la liste des documents de référence. Circuit de validation Nom / Prénom Entité / Direction Date Commentaires Visa Historique du document Version Date Auteur

Plus en détail

Actes Budgétaires. Comment entrer dans la démarche de dématérialisation des documents budgétaires?

Actes Budgétaires. Comment entrer dans la démarche de dématérialisation des documents budgétaires? Actes Budgétaires Comment entrer dans la démarche de dématérialisation des s budgétaires? Notice explicative à destination des collectivités locales et établissements publics voulant entrer dans la démarche

Plus en détail

Conditions générales d utilisation du portail web de FranceAgriMer et de ses e-services (téléservices)

Conditions générales d utilisation du portail web de FranceAgriMer et de ses e-services (téléservices) Conditions générales d utilisation du portail web de FranceAgriMer et de ses e-services (téléservices) 1. Les conditions générales d utilisation (CGU) décrites ci-dessous peuvent être complétées par les

Plus en détail

equalogic Qualité contact@equalogic.fr - www.equalogic.fr

equalogic Qualité contact@equalogic.fr - www.equalogic.fr equalogic Qualité contact@equalogic.fr - www.equalogic.fr Présentation générale equalogic Qualité est un logiciel de gestion de la qualité. Il s adresse à toute entreprise, certifiée ou non, soucieuse

Plus en détail

aroline MASCRET Mission Juridique Pôle «Actes et Produits de Santé» Haute Autorité de Santé

aroline MASCRET Mission Juridique Pôle «Actes et Produits de Santé» Haute Autorité de Santé Champ référentiel 1.2 Chapitre 1, domaine 2 : Juridique Le dossier Médical Personnel ou DMP aroline MASCRET Mission Juridique Pôle «Actes et Produits de Santé» Haute Autorité de Santé Chronologie du DMP

Plus en détail

Carestream Vincent Marcé, Directeur GCS TéléSanté Centre LA SÉCURITÉ DANS LE PROJET MUTUALISATION DES IMAGES MÉDICALES EN RÉGION CENTRE

Carestream Vincent Marcé, Directeur GCS TéléSanté Centre LA SÉCURITÉ DANS LE PROJET MUTUALISATION DES IMAGES MÉDICALES EN RÉGION CENTRE Carestream Vincent Marcé, Directeur GCS TéléSanté Centre LA SÉCURITÉ DANS LE PROJET MUTUALISATION DES IMAGES MÉDICALES EN RÉGION CENTRE Le Projet MIRC PACS Archivage Echange & Partage Processus d amélioration

Plus en détail

Kit d intégration JAVA

Kit d intégration JAVA Kit d intégration JAVA sommaire 1. Introduction... 3 1.1. Objet du document... 3 1.2. Public visé... 3 1.3. Contenu du document... 3 1.4. Liste des documents de référence... 3 1.5. Avertissement... 4 1.6.

Plus en détail

Connexion d un client lourd à la messagerie e-santé PACA

Connexion d un client lourd à la messagerie e-santé PACA Connexion d un client lourd à la messagerie e-santé PACA La messagerie sécurisée e-santé PACA est un service de type Webmail. Un Webmail est une interface Web rendant possible l émission, la consultation

Plus en détail

Guichet ONEGATE COLLECTE XBRL SOLVABILITE II (S2P) Manuel d utilisateur VERSION 1.4 16/04/2014 ORGANISATION ET INFORMATIQUE SDESS.

Guichet ONEGATE COLLECTE XBRL SOLVABILITE II (S2P) Manuel d utilisateur VERSION 1.4 16/04/2014 ORGANISATION ET INFORMATIQUE SDESS. Guichet ONEGATE Manuel d utilisateur COLLECTE XBRL SOLVABILITE II (S2P) ORGANISATION ET INFORMATIQUE SDESS VERSION 1.4 16/04/2014 Version 1 SUIVI DES VERSIONS Version Date Nature des modifications Paragraphe

Plus en détail

Ce document est la propriété du Groupe CEGEDIM. Il ne peut être ni reproduit, ni communiqué à des tiers sans autorisation écrite d une personne

Ce document est la propriété du Groupe CEGEDIM. Il ne peut être ni reproduit, ni communiqué à des tiers sans autorisation écrite d une personne Ce document est la propriété du Groupe CEGEDIM. Il ne peut être ni reproduit, ni communiqué à des tiers sans autorisation écrite d une personne mandatée à cet effet par ledit Groupe CEGEDIM. Table des

Plus en détail

Par messagerie dam@cpam-annecy.cnamts.fr

Par messagerie dam@cpam-annecy.cnamts.fr LES SOLUTIONS PRATIQUES DE L ASSURANCE MALADIE POUR VOTRE INSTALLATION ET VOTRE EXERCICE AU QUOTIDIEN Que contient la convention médicale? Vous pouvez accéder à la nouvelle convention médicale sur le site

Plus en détail

Projet : Plan Assurance Qualité

Projet : Plan Assurance Qualité Projet : Document : Plan Assurance Qualité 2UP_SPEC_DEV1 VERSION 1.00 Objet Ce document a pour objectif de définir la démarche d analyse et de conception objet ainsi les activités liées. Auteur Eric PAPET

Plus en détail

Utilisation des listes de diffusion Sympa (propriétaire)

Utilisation des listes de diffusion Sympa (propriétaire) Utilisation des listes de diffusion Sympa (propriétaire) Qu'est-ce qu'une liste de diffusion? Les listes de diffusion permettent à des personnes d un même groupe ou partageant un même centre d intérêt

Plus en détail

Messagerie du Webmail académique. Le client de messagerie

Messagerie du Webmail académique. Le client de messagerie Le client de messagerie Sommaire Introduction I - VIII Ergonomie 1-6 Carnets d adresses 7-9 Écrire un message 10 Options de rédaction 11 Pièces jointes 12 Mise en forme des messages 13 Filtres de courrier

Plus en détail

PLATEFORME DE GESTION DE CONGRÈS SCIENTIFIQUES. 12 mars 2015

PLATEFORME DE GESTION DE CONGRÈS SCIENTIFIQUES. 12 mars 2015 PLATEFORME DE GESTION DE CONGRÈS SCIENTIFIQUES 12 mars 2015 Sommaire La plateforme Sciencesconf.org Le portail L espace conférence Site web Gestion scientifique Dépôt, sélection, envoi de mails, édition

Plus en détail

GUIDE PRATIQUE DU PROJET DMP EN ÉTABLISSEMENT DE SANTÉ

GUIDE PRATIQUE DU PROJET DMP EN ÉTABLISSEMENT DE SANTÉ GUIDE PRATIQUE DU PROJET DMP EN ÉTABLISSEMENT DE SANTÉ 2 e édition Mai 2012 www.dmp.gouv.fr GuideDMP_ASIP_Couv.indd 1 27/04/12 11:35 2 - GUIDE PRATIQUE DU PROJET DMP EN ÉTABLISSEMENT DE SANTÉ INTRODUCTION

Plus en détail

LIVRE BLANC QUALIOS DOC

LIVRE BLANC QUALIOS DOC LIVRE BLANC QUALIOS DOC Version 4.0 4, rue du Bois de La Champelle BP 306 54515 VANDŒUVRE CEDEX Tél. 33 (0)3 83 44 75 50 Fax. 33 (0)3 83 44 75 51 QUALIOS est une solution informatique développée par SAS

Plus en détail

DMP Compatibilité : une offre logicielle qui couvre la majorité des médecins de ville

DMP Compatibilité : une offre logicielle qui couvre la majorité des médecins de ville Les logiciels DMP-compatibles La plateforme e-learning La plateforme e-doc La cartographie DMP Pour en savoir plus dmp.gouv.fr DMP Compatibilité : une offre logicielle qui couvre la majorité des médecins

Plus en détail

Annexe : Tableau de fonctionnalités La présente Annexe décrit les fonctionnalités du progiciel que l organisation de santé pluriprofessionnelle souhaite mettre en place au sein de l entité. Le progiciel

Plus en détail

Présentation du cadre technique de mise en œuvre d un Service d Archivage Electronique

Présentation du cadre technique de mise en œuvre d un Service d Archivage Electronique Présentation du cadre technique de mise en œuvre d un Service d Archivage Electronique Isabelle GIBAUD Consultante au Syndicat Interhospitalier de Bretagne Co-chair vendor IHE-FRANCE Sommaire 1 Périmètre

Plus en détail

Journées de formation DMP

Journées de formation DMP Journées de formation DMP Le DMP dans l écosystème Chantal Coru, Bureau Etudes, ASIP Santé Mardi 26 juin 2012 Processus de coordination au centre des prises en charge Quelques exemples Maisons de santé

Plus en détail

Exigences V2014 de la certification «Les systèmes d information»

Exigences V2014 de la certification «Les systèmes d information» Exigences V2014 de la certification «Les systèmes d information» G. Hatem Gantzer Hôpital de Saint Denis Séminaire AUDIPOG 9/4/2015 Les autres points clés de la certification impactés par le SI Le dossier

Plus en détail

Développement spécifique d'un système d information

Développement spécifique d'un système d information Centre national de la recherche scientifique Direction des systèmes d'information REFERENTIEL QUALITE Procédure Qualité Développement spécifique d'un système d information Référence : CNRS/DSI/conduite-proj/developpement/proc-developpement-si

Plus en détail

Messagerie Sécurisée de Santé

Messagerie Sécurisée de Santé Messagerie Sécurisée de Santé Présentation Rencontres Inter Régionales Mardi 24 septembre 2012 ASIP Santé Pôle Projets & Coordination des Soins Ordre du jour 1 Présentation de la MSS 2 Principes fonctionnels

Plus en détail

Annexe 1 Annexe technique de la convention d habilitation «société d assurance»

Annexe 1 Annexe technique de la convention d habilitation «société d assurance» Annexe 1 Annexe technique de la convention d habilitation «société d assurance» «professionnel indépendant» (Convention complète) 1 Notice explicative... 2 1.1 Préambule... 2 1.2 Référencement du concentrateur...

Plus en détail

Manuel du logiciel PrestaTest.

Manuel du logiciel PrestaTest. Manuel du logiciel. Ce document décrit les différents tests que permet le logiciel, il liste également les informations nécessaires à chacun d entre eux. Table des matières Prérequis de PrestaConnect :...2

Plus en détail

Présentation Générale

Présentation Générale Présentation Générale Les origines Interop Santé est une association loi 1901 créée en 1990 sous le nom d H.PR.I.M. (Harmoniser PRomouvoir les Informatiques Médicales) En 2004, devient l affiliée française

Plus en détail

Guide utilisateur pour la création des porteurs et les demandes de cartes en mairie

Guide utilisateur pour la création des porteurs et les demandes de cartes en mairie Guide utilisateur pour la création des porteurs et les demandes de cartes en mairie SOMMAIRE A. INTRODUCTION... 4 B. PREREQUIS TECHNIQUES... 4 C. PROCESSUS... 4 D. DECLARATION D UN UTILISATEUR DANS L ANNUAIRE...

Plus en détail

Guide Utilisateur Gamme Prem Habitat Gestion des demandes d intervention

Guide Utilisateur Gamme Prem Habitat Gestion des demandes d intervention Guide Utilisateur Gamme Prem Habitat Gestion des demandes d intervention Version 1 Service Hot Line Aareon 2009 page 1 de 15 Table des matières 1 Saisie d une demande d intervention... 3 1.1 Accès au site

Plus en détail

V 7.3. Vous allez utiliser les services en ligne de la plate forme de dématérialisation de la Salle des Marchés achatpublic.com.

V 7.3. Vous allez utiliser les services en ligne de la plate forme de dématérialisation de la Salle des Marchés achatpublic.com. MANUEL D UTILISATION DE LA SALLE DES MARCHES ACCES ENTREPRISES V 7.3 APPEL D OFFRES RESTREINT Vous allez utiliser les services en ligne de la plate forme de dématérialisation de la Salle des Marchés achatpublic.com.

Plus en détail