Dossier de spécifications fonctionnelles et techniques des interfaces

Transcription

ASIP Santé | DSFT des interfaces DMP des LPS – V 1.0.4 | 17/06/2016
1 / 254
Référence du document :
DSFT des interfaces DMP des LPS_v1.0.4.docx
Classification :
Non sensible public
Historique du document
Version
Date
Commentaires
V 0.9.5
10/09/2010
Version initiale.
Compléments sur :
V 1.0.0
V 1.0.1
04/11/2010
19/11/2010





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 1.0.1.
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.
V 1.0.2
13/02/2014
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.
Correction d’erreur rédactionnelles et de renvois ou liens non opérationnels.
Ajout d’information sur les « CDA autoprésentables ».
V 1.0.3
24/06/2014
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.
V 1.0.4
17/06/2016
Ajout de la possibilité d’alimenter le DMP pour les CPE des secrétaires
médicales du secteur libéral.
2 / 254
1
Introduction .....................................................................................................................7
1.1
Objet du document ...................................................................................................7
1.2
Guide de lecture .......................................................................................................8
1.3
Gestion des versions ................................................................................................9
2
Contexte ........................................................................................................................10
2.1
Le DMP ..................................................................................................................10
2.2
Les LPS .................................................................................................................11
2.2.1
Les différents types de LPS.............................................................................11
2.2.2
Le LPS au cœur des Systèmes d’Information de Santé ..................................12
2.3
Les fonctions DMP du LPS.....................................................................................13
2.3.1
L’accès sécurisé au DMP ................................................................................14
2.3.2
La création et la gestion administrative du DMP ..............................................15
2.3.3
L’alimentation du DMP ....................................................................................16
2.3.4
La consultation du DMP ..................................................................................16
3
Processus d’homologation à la DMP Compatibilité........................................................17
3.1
Présentation du processus d’homologation ............................................................17
3.1.1
Constitution du dossier de candidature ...........................................................17
3.1.2
Développements et tests préparatoires à l’homologation ................................18
3.1.3
Homologation ..................................................................................................19
3.1.4
En savoir plus sur la DMP Compatibilité ..........................................................19
3.2
Les environnements techniques .............................................................................20
3.2.1
Les environnements d’homologation ...............................................................20
3.2.2
Les environnements de formation et de production .........................................21
4
Transactions et profils DMP pour les LPS .....................................................................22
4.1
Description des transactions DMP..........................................................................22
4.2
Mode d’authentification ..........................................................................................25
4.2.1
Authentification indirecte .................................................................................25
4.2.2
Authentification directe ....................................................................................25
4.3
Utilisateurs et droits associés .................................................................................26
4.3.1
Professionnels de santé ..................................................................................26
4.3.2
Les acteurs non PS .........................................................................................27
4.4
Choix de profils à implémenter dans un LPS ..........................................................28
4.4.1
Principes généraux .........................................................................................28
4.4.2
L’implémentation des profils DMP dans les LPS .............................................30
4.5
Homologation des profils implémentés ...................................................................31
5
Exigences préalables à la DMP Compatibilité ...............................................................32
5.1
Standards, normes, référentiels .............................................................................32
5.1.1
Le cadre d’interopérabilité des SIS ..................................................................32
5.1.2
Le profil IHE XDS.b .........................................................................................34
5.1.3
Identification du patient par son INS ................................................................37
5.1.4
Identification des professionnels de santé .......................................................43
5.1.5
Identification des structures de santé ..............................................................44
5.1.6
Autres normes et standards ............................................................................44
5.2
Paramétrage du LPS ..............................................................................................45
5.2.1
OID racine unique par instance du LPS ..........................................................45
5.2.2
Gestion des évolutions des Web Services.......................................................46
5.2.3
Nomenclatures et référentiels ..........................................................................47
5.2.4
Cadre d’exercice, Secteur d’activité, Profession / Spécialité............................47
5.3
Configuration poste de travail / serveur ..................................................................50
3 / 254
Sommaire
Sommaire
Sommaire
Connexion internet ..........................................................................................50
Accès Web-PS ................................................................................................50
Lecteur de cartes (matériel).............................................................................51
Dispositifs de lecture des cartes Vitale (logiciel) ..............................................51
Dispositifs pour l’authentification des utilisateurs .............................................53
Synchronisation du temps ...............................................................................54
Impression ......................................................................................................55
6
Exemples d’intégration du DMP dans les LPS...............................................................56
6.1
Exemple DMP minimal : intégration de l’AW-PS contextuel....................................57
6.2
Exemple d’un LPS en authentification directe (cas typique du LGC) ......................58
6.2.1
Exemple avec calcul de l’INS dans le LPS ......................................................58
6.2.2
Exemple sans calcul de l’INS dans le LPS ......................................................59
6.3
Exemple d’un LPS en authentification indirecte (cas typique du SIH) .....................60
6.3.1
Exemple de type SIH « intégré » .....................................................................60
6.3.2
Exemple de type SIH « réparti »......................................................................61
6.3.3
IHE PAM-fr et DMP .........................................................................................62
6.4
Cas des « Connecteurs / EAI » ..............................................................................63
6.5
Cas des logiciels en mode SaaS ............................................................................64
6.6
Exemple de l’AW-PS non intégré au LPS ...............................................................65
7
Accès sécurisé au DMP ................................................................................................66
7.1
Exigences générales de sécurité ............................................................................66
7.1.1
Connexion au DMP .........................................................................................66
7.1.2
Vérification du certificat serveur du SI DMP ....................................................69
7.1.3
Vérification du numéro d’homologation du LPS ...............................................71
7.2
TD0.1 - Authentification sur le DMP .......................................................................72
7.2.1
Authentification directe par CPS, CPE, CPF ...................................................72
7.2.2
Authentification indirecte .................................................................................72
7.2.3
Le VIHF ...........................................................................................................74
7.3
Règles de gestion des droits dans le DMP .............................................................83
7.3.1
Autorisations et droits d’accès à un DMP ........................................................85
7.3.2
Droits fonctionnels par mode d’authentification et par profil utilisateur.............89
7.3.3
Matrice d’habilitation .......................................................................................91
7.4
TD0.2 - Test d’existence d’un DMP et vérification de l’autorisation.........................92
7.4.1
Prérequis.........................................................................................................92
7.4.2
Cinématique ....................................................................................................92
7.4.3
Transaction .....................................................................................................92
7.5
TD0.3 - Mise à jour de l’autorisation d’accès ..........................................................96
7.5.1
Prérequis.........................................................................................................96
7.5.2
Cinématique ....................................................................................................96
7.5.3
Transaction .....................................................................................................99
7.6
TD0.4 - Liste des DMP autorisés ..........................................................................101
7.6.1
Prérequis.......................................................................................................101
7.6.2
Cinématique ..................................................................................................101
7.6.3
Transaction ...................................................................................................102
7.7
TD0.5 - Recherche sans INS de patients dans le DMP ........................................105
7.7.1
Prérequis.......................................................................................................105
7.7.2
Cinématique ..................................................................................................105
7.7.3
Transaction ...................................................................................................105
7.8
TD0.9 - Accès Web-PS Contextuel ......................................................................110
7.8.1
Principes généraux .......................................................................................110
7.8.2
Synthèse avec les transactions LPS .............................................................113
7.8.3
Accès aux différentes fonctions .....................................................................114
4 / 254
Sommaire
5.3.1
5.3.2
5.3.3
5.3.4
5.3.5
5.3.6
5.3.7
Création et gestion administrative du DMP ..................................................................123
8.1
Les différents états d’un DMP ..............................................................................123
8.2
TD1.1 – Création d’un DMP .................................................................................126
8.2.1
Prérequis.......................................................................................................126
8.2.2
Cinématique ..................................................................................................126
8.2.3
Transaction ...................................................................................................129
8.3
TD1.2 - Réactivation d’un DMP ............................................................................134
8.3.1
Prérequis.......................................................................................................134
8.3.2
Cinématique ..................................................................................................134
8.3.3
Transaction ...................................................................................................137
8.4
TD1.3 – Mise à jour des données administratives ................................................138
8.4.1
Prérequis.......................................................................................................138
8.4.2
Cinématique ..................................................................................................138
8.4.3
Consultation des données administratives et de gestion ...............................138
8.4.4
Modification des données administratives et de gestion ................................139
8.5
TD1.4 – Fermeture du DMP .................................................................................142
8.5.1
Prérequis.......................................................................................................142
8.5.2
Cinématique ..................................................................................................142
8.5.3
Transaction ...................................................................................................143
8.6
TD1.5 – Accès Internet du Patient ........................................................................144
8.6.1
Prérequis.......................................................................................................144
8.6.2
Cinématique ..................................................................................................145
8.6.3
Création du compte internet patient...............................................................150
8.6.4
Ajout de canal OTP .......................................................................................152
8.6.5
Activation du compte internet par le patient ...................................................154
8.6.6
Déblocage du compte internet ou mise à jour des codes internet ..................154
8.7
TD1.6 - Liste des PS autorisés / bloqués sur un DMP ..........................................156
8.7.1
Prérequis.......................................................................................................156
8.7.2
Cinématique ..................................................................................................156
8.7.3
Transaction ...................................................................................................156
8.8
Spécifications techniques communes ...................................................................159
8.8.1
Documentation et références ........................................................................159
8.8.2
Structure commune des messages HL7 V3 ..................................................159
8.8.3
PS (ou professionnel non PS) recueillant le consentement / auteur de l’action
sur le dossier ...............................................................................................................165
8.8.4
Données patient ............................................................................................166
8.8.5
Représentant légal du patient........................................................................170
9
Alimentation du DMP ...................................................................................................172
9.1
TD2.1/TD2.2 - Alimentation du DMP en documents .............................................172
9.1.1
Prérequis.......................................................................................................172
9.1.2
Cinématique générale ...................................................................................172
9.1.3
Saisie du document dans le LPS ...................................................................173
9.1.4
Génération du document CDA et des métadonnées XDS .............................176
9.1.5
Signature du document (non obligatoire) .......................................................188
9.1.6
Constitution et signature du lot de soumission ..............................................189
9.1.7
Transaction : Envoi de la requête au DMP ....................................................191
9.2
Remplacement d’un document existant dans le DMP...........................................193
10 Consultation du DMP ..................................................................................................195
10.1 TD3.1 - Recherche de documents dans un DMP .................................................196
10.1.1 Prérequis.......................................................................................................196
10.1.2 Cinématique ..................................................................................................196
10.1.3 Transaction ...................................................................................................199
5 / 254
Sommaire
8
11 Annexes ......................................................................................................................212
11.1 Documents externes ............................................................................................212
11.1.1 Documents applicables .................................................................................212
11.1.2 Documents de référence ...............................................................................215
11.1.3 Annexes externes .........................................................................................216
11.2 Terminologie et acronymes ..................................................................................217
11.3 WSDL des services ..............................................................................................219
11.4 Codes d’erreurs....................................................................................................220
11.4.1 Liste des codes d’erreurs ..............................................................................220
11.4.2 Erreurs spécifiques du processus d’authentification (« SOAP Fault ») ..........223
11.4.3 Erreurs fréquentes liées aux transactions XDS (TD2.1 / TD2.2 / TD3.3 / TD3.1)
226
11.4.4 Autres erreurs fréquentes ..............................................................................229
11.5 Signature XAdES .................................................................................................230
11.5.1 Principes généraux de XAdES ......................................................................230
11.5.2 Rappel des principes de la signature électronique ........................................230
11.5.3 Structure « XAdES W3C » ............................................................................231
11.5.4 Erreurs fréquentes lors de la mise en œuvre .................................................235
11.6 Aide à l’implémentation du profil IHE DSG pour le DMP .......................................237
11.6.1 Structure d’une soumission XDS.b ................................................................238
11.6.2 Construction de la pièce jointe XAdES de signature du lot de soumission.....240
11.6.3 Requête d’alimentation XDS.b commentée ...................................................244
11.7 Code exemple ......................................................................................................248
11.8 Règles sur les dates de naissance lues en carte Vitale ........................................249
11.8.1 Règle AM_DLU : date de naissance « lunaire » ............................................249
11.8.2 Règle AM_BISSEX : détermination d'une année bissextile ...........................249
11.8.3 Règle AM_DNA_SIECLE : détermination du siècle d’une date de naissance 250
6 / 254
Sommaire
10.2 TD3.2 - Consultation d’un document du DMP ......................................................203
10.2.1 Prérequis.......................................................................................................203
10.2.2 Cinématique ..................................................................................................203
10.2.3 Transaction ...................................................................................................206
10.3 TD3.3 – Gestion des attributs d’un document .......................................................207
10.3.1 Prérequis.......................................................................................................207
10.3.2 Cinématique ..................................................................................................208
10.3.3 Transaction ...................................................................................................210
1 Introduction
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.
7 / 254
1 Introduction
1.1 Objet du document
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.
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
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é.
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é.
8 / 254
1 Introduction
Profil du lecteur / chapitres à lire en priorité
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 à V1.0.2.
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
V1.0
V1.0
V1.0
V1.0
V1.1
V2.0
Version du DSFT DMP
V1.0.0
V1.0.1
V1.0.2
V1.0.3
V1.1.0
V2.0.0
Type de version
Mineure
Mineure
Mineure
Mineure
Intermédiaire
Majeure
9 / 254
1 Introduction

2 Contexte
2.1 Le DMP
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.
10 / 254
2 Contexte
Améliorer la coordination des soins
2.2 Les LPS
2.2.1 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.

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
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
par
les
accueils
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.
11 / 254
2 Contexte
Parmi les types de LPS couramment répandus aujourd'hui, on distingue :
2.2.2 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.
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).
12 / 254
2 Contexte
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.
2.3 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 ;
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.
Ⓡ
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.
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é.
13 / 254
2 Contexte
Les principales fonctions DMP pouvant être implémentées dans le LPS sont :
2.3.1 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.

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 :
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.
14 / 254
2 Contexte
La sécurité est une ligne directrice de la conception du système d’information DMP et se
traduit par :
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
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 ;
o
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.
o
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 ».
2.3.2 La création et la gestion administrative du DMP
Ⓡ
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 ».
15 / 254
2 Contexte

2.3.3 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.
Ⓡ
Ⓡ
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.
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
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é).
2.3.4 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é.
16 / 254
2 Contexte
Ⓡ
REC_GEN-1050
à
la
DMP
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].
3.1.1 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é :
http://esante.gouv.fr/services/espace-dmp/processus-d-homologation-a-la-dmp-compatibilite.
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 [email protected].
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 [email protected], y compris s’il n’a pas encore
signé de contrat.
17 / 254
3 Processus d’homologation à la DMP Compatibilité
3 Processus d’homologation
Compatibilité
3.1.2.1 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/TD2.2 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.
3.1.2.2 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.
18 / 254
3.1.2 Développements et tests préparatoires à l’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.
3.1.4 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 : http://esante.gouv.fr/services/espace-dmp/faq-dmp-compatibilite et
régulièrement mises à jour.
Les éditeurs peuvent aussi contacter l’équipe en charge de la DMP Compatibilité à l’ASIP
Santé par mail à : [email protected].
19 / 254
3.1.3 Homologation
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é.
3.2.1 Les environnements d’homologation
Environnement
Environnement de
test mutualisé
(DV1)
Phase
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/TD2.2 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é.
Développement des transactions complémentaires.
Environnement de
test dédié (DVx)
Environnement
d’homologation
dédié (VA)
Tests de pré-homologation et envoi à l’ASIP Santé des résultats
pour validation.
Tests d’homologation et envoi à l’ASIP Santé des résultats pour
validation.
Tests de transactions homologués pour :
Environnement de
test mutualisé
pour transactions
homologués (DVH)


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 à : [email protected].
L’accès à ces environnements se fait au moyen de cartes CPx et de certificats de test.
20 / 254
3.2 Les environnements techniques
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 DMPCompatible 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 :
http://www.dmp.gouv.fr/professionnel-de-sante/utiliser-le-dmp/vousformer-au-dmp/utiliser-le-dmp-avec-la-base-ecole
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 0810 33 11 33 (prix d’un appel local)
via le formulaire de contact http://www.dmp.gouv.fr/contact-ps.
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.
21 / 254
3.2.2 Les environnements de formation et de production
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
22 / 254
4 Transactions et profils DMP pour les LPS
Les spécifications détaillées des transactions sont décrites aux paragraphes 7 à 10 du
présent document.
Transactions DMP pour LPS
Description synthétique
ACCES SECURISE AU DMP
Authentification sur le DMP
TD0.1
Permet d’authentifier l’acteur de santé (PS ou STS)
auprès du système DMP.
Test d’existence d’un DMP et Permet de vérifier qu’un DMP existe, de récupérer le
TD0.2 vérification de l’autorisation statut d’un DMP et celui de l’autorisation d’accès de
d’accès
l’acteur de santé sur ce DMP.
Mise à jour de l’autorisation Permet à l’acteur de santé de se déclarer autorisé par le
TD0.3 d’accès
patient à accéder au DMP du patient ou au contraire se
retirer de la liste des PS autorisés.
Liste des dossiers 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
TD0.4
exhaustive des dossiers ou liste des dossiers pour
lesquels une nouvelle autorisation a été donnée depuis
une date donnée).
Recherche
sans
INS
de Permet de chercher un ou des patients dans le SI DMP,
TD0.5
patients dans le SI DMP
sans son INS, à partir d’autres traits d’identité.
Accès web-PS contextuel
Permet d’ouvrir l’Accès Web DMP dans un navigateur,
TD0.9
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é.
Données administratives d’un Permet de consulter et mettre à jour les données
TD1.3
DMP
administratives d’un DMP
TD1.4 Fermeture d’un DMP
Permet de fermer un DMP.
Accès internet du patient
Permet d’initialiser, mettre à jour ou débloquer le compte
TD1.5
d’accès internet d’un patient.
Liste des PS autorisés/bloqués Permet d’obtenir, pour un DMP, la liste des PS autorisés
TD1.6
sur un DMP
à y accéder, la liste des PS bloqués, ou les 2.
ALIMENTATION DU DMP
Alimentation en documents d’un Permet de déposer un (ou des) document(s) dans le DMP
DMP
d’un patient. Cette transaction gère aussi les mises à jour
TD2.1
successives d’un document avec le remplacement d’un
document par une nouvelle version.
Alimentation en documents d’un Transaction identique à TD2.1, mais dédié à
DMP, par CPE pour les l'authentification par carte CPE pour les secrétaires
TD2.2
secrétaires
médicales
du médicales du secteur libéral
secteur libéral
CONSULTATION DU DMP
Recherche de documents dans Permet de rechercher des documents dans l’index des
TD3.1
un DMP
documents du DMP d’un patient.
Consultation d’un document Permet de récupérer et consulter un document (à partir de
TD3.2
dans un DMP
l’identifiant du document récupéré par la TD3.1).
Gestion des attributs d’un Permet de gérer les attributs d’un document :
TD3.3 document
masquer/démasquer aux PS, rendre visible au patient,
archiver/désarchiver et supprimer.
Tableau 2 : Description des transactions
23 / 254
Description synthétique des transactions DMP
24 / 254
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 ».
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 § 0.
Comme spécifié dans [CI-TR-CLI-LRD], deux configurations d’authentification du PS sur le
DMP sont possibles pour un LPS :
4.2.1 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.
4.2.2 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
25 / 254
4.2 Mode d’authentification
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.
4.3.1 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
créer et alimenter un DMP
o
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
accéder à tous les documents masqués de ce dossier (et si nécessaire
démasquer un document masqué),
o
accéder à toutes les traces fonctionnelles du dossier (les siennes et celles des
autres PS),
o
gérer les autorisations d’accès à un DMP,
o
effectuer une demande de copie du DMP pour le compte de son titulaire,
o
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.
26 / 254
4.3 Utilisateurs et droits associés
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) ou à l’aide de certaines CPE (sécrétaires médicales du
secteur libéral), 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) ou par CPE.
27 / 254
4.3.2 Les acteurs non PS
4.4.1 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
TD0.1
TD0.2
Test d’existence d’un DMP et vérification de
l’autorisation d’accès
TD0.3
Mise à jour de l’autorisation d’accès
TD0.4
TD0.5
Recherche sans INS du DMP d’un patient
TD0.9
Accès web-PS contextuel
TD1.1
Création d’un DMP
TD1.2
Réactivation d’un DMP
TD1.3
Données administratives d’un DMP
TD1.4
Fermeture d’un DMP
TD1.5
TD1.6
Liste des PS autorisés/bloqués sur un DMP
ALIMENTATION DU DMP
TD2.1
Alimentation en documents d’un DMP
TD2.2
Alimentation en documents d’un DMP par CPE
pour les secrétaires médicales du secteur
libéral
CONSULTATION DU DMP
TD3.1
Recherche de documents dans un DMP
TD3.2
Consultation d’un document dans un DMP
TD3.3
Gestion des attributs d’un document
CREATION
ALIMENTATION
CONSULTATION
Obligatoire
Obligatoire (2)
Optionnelle
Optionnelle (1)
Obligatoire (2)
Optionnelle
Optionnelle
Optionnelle (1)
Optionnelle (2)
Obligatoire (1) (2)
Obligatoire
Optionnelle
Optionnelle
Optionnelle (1)
Obligatoire
Optionnelle (1)
Obligatoire
Optionnelle
Obligatoire (3)
Obligatoire (1)
Obligatoire (1)
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
Ⓔ
EX_GEN-1110
L’éditeur doit obligatoirement implémenter les transactions « Obligatoires » du profil « Accès
sécurisé au DMP ».
28 / 254
4.4 Choix de profils à implémenter dans un LPS
Ⓔ
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.
29 / 254
Ensuite, selon ses besoins, l’éditeur sélectionne les profils qu’il souhaite implémenter dans
son 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.
Ⓔ
EX_GEN-1140
Ⓔ
EX_GEN-1145
Ⓔ
EX_GEN-1150
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.
Les messages affichées doivent être spécifiques à chaque situation (code retour ou d’erreur)
et facilement compréhensibles des utilisateurs.
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.
30 / 254
4.4.2 L’implémentation des profils DMP dans les LPS
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
Ⓔ
EX_GEN-1170
Ⓔ
EX_GEN-1180
Ⓔ
EX_GEN-1190
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.
Le logiciel DMP-Compatible doit impérativement proposer aux utilisateurs les transactions
obligatoires des profils implémentés.
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).
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.
31 / 254
4.5 Homologation des profils implémentés
à
la
DMP
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).

à l’INS
5.1.1 Le cadre d’interopérabilité des SIS
Ⓔ
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é « CISIS ».
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.
32 / 254
5 Exigences préalables à la DMP Compatibilité
5 Exigences
préalables
Compatibilité
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.1.0.1 accessible
sur http://esante.gouv.fr/services/referentiels/referentiels-d-interoperabilite/ci-sis-historique
(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 [CIANX-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) ;
33 / 254
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.
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
10 – Comptes rendus
10 – Comptes rendus
11 - Synthèses
Type
11488-4 CR ou fiche de consultation ou de visite
11528-7 CR d’imagerie médicale
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.
5.1.2 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 :
34 / 254
Les tables de transcodage des spécialités et des secteurs d’activité entre ADELI et RPPS
sont dans [TRANS-ADELI-RPPS].
Recherche de
documents
Registry XDS.b
LPS
(Document
Source,
Document
Consumer,
Document
Administrator)
Mise à jour de
métadonnées
DMP
Alimentation
Repository XDS.b
Consultation
documents
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-ANXNOMENC-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 § 9.1.4.2 « 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 : http://wiki.ihe.net/index.php?title=XDS.b .
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…).
35 / 254
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
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
correctement déroulée
s’est
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.
errorCode
Code d’erreur (en cas d’erreur) Contient un code d’erreur XDS. Les
valeurs possibles sont décrites dans [IHETF3] § 4.1.13
D’autres codes spécifiques au DMP
peuvent être retournés (voir le détail dans
les transactions).
codeContext Libellé de l’erreur associé (en Contient
des
informations
cas d’erreur)
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.
Location
Localisation de l’erreur (en cas Localisation de l’erreur au sein du SI DMP
d’erreur)
(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>
36 / 254
Gestion des erreurs
5.1.3.1 L’INS
Les raisons d’être de l’identifiant National de Santé sont exprimées dans l’article L1111-8-1
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é.
5.1.3.2 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’INSC. Les règles de passage de l’INS-C à l’INS-A seront définies ultérieurement.
5.1.3.3 Gestion de l’INS dans le LPS
Ⓔ
EX_GEN-1220
Le LPS doit gérer (et stocker), pour chaque INS, le statut de l’INS.
37 / 254
5.1.3 Identification du patient par son INS
Actions possibles
Fourni par un tiers, à L’INS doit être vérifié (voir l’exigence liée au § 5.1.3.5).
vérifier
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»).
Fourni par un tiers sûr
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.
Calculé par le LPS avec L’INS peut être utilisé pour toutes les transactions.
une carte Vitale
Associé à un DMP
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
Ⓔ
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. § 5.1.3.5)
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.
38 / 254
Statut de l’INS
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 1er juillet 2006 sont
fixées par les articles 311-21 à 311-24 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.
Carte Vitale V1bis
Nom de famille du patient
Nom d'usage du patient
Absent
Obligatoire
Désignation : nom usuel ou nom
d’usage
Carte Vitale V1ter
Facultatif
Désignation : nom de famille
nom patronymique
Obligatoire
ou
Désignation : nom usuel ou nom
d’usage
CI-SIS : En-tête CDA
des
documents
partagés
patient/name/family[@qualifier='BR']
patient/name/family[@qualifier='SP']
CI-SIS : Métadonnée
document
sourcePatientInfo de
XDS
Composant 1 de PID-5 lorsque
composant 7 de PID-5 = 'L' (Legal
name)
Composant 1 de PID-5 lorsque
composant 7 de PID-5 = 'D'
(Display name)
Accès
DMP
Facultatif
Obligatoire
Désignation : Nom de naissance
Désignation : Nom d’usage
Facultatif
Obligatoire
Désignation : Nom de naissance
Désignation : Nom d’usage
web
patient
Accès web PS DMP
39 / 254
Dans le cas où les traits sont identiques, le LPS ne doit pas solliciter l’utilisateur.
Ⓡ
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
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
Ⓡ
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).
40 / 254
5.1.3.4 Calcul de l’INS-C à partir de la carte Vitale
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
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 § 5.1.3.3.
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).
5.1.3.6 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.
41 / 254
5.1.3.5 Vérification de l’INS-C lorsqu’il n’a pas été calculé par le LPS
Ⓔ
Ⓔ
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é.
5.1.3.7 Procédure de référencement de logiciels pour le calcul de l’INS-C
Ⓔ
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
http://www.cnda-vitale.fr/php/services-cnda.php?libelle=T%E9l%E9chargements&page=5.INS-C
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
www.cnda-vitale.fr la liste des logiciels référencés intégrant le calcul de l’INS-C.
42 / 254
EX_GEN-1290
Ⓔ
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
par son identifiant national de PS (N°ADELI ou N°RPPS) paramétré dans le
LPS ;
o
à 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
Tableau 8 : Identifiant des personnes dans le secteur de la santé
Dans le tableau :

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).
43 / 254
5.1.4 Identification des professionnels de santé
Ⓔ
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).
5.1.6 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 :
http://esante.gouv.fr/services/referentiels/interoperabilite/faq-sur-le-cda-r2.

SOAP

TLS
•
Signature électronique XML-DSig et XAdES : un rappel des principes de signature est
proposé au § 11.5.2.
44 / 254
5.1.5 Identification des structures de santé
5.2.1 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 "1.2.3.4".
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 « 1.2.250.1 ». 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, HL7US… »
Par exemple, une organisation ayant commandé à l’AFNOR un OID numérique (ex : 999)
aura un OID racine 1.2.250.1.999.
Ⓔ
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
Ⓔ
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.
45 / 254
5.2 Paramétrage du LPS

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 (http://www.itu.int/ITUT/asn1/uuid.html) ; exemple : 2.25.329800735698586629295641978511506172918
Exemple possible d’implémentation (cas n°1) :

OID commandé par l’éditeur « Editeur-lambda » auprès de l’AFNOR : 1.2.250.1.999
o
OID du LPS « LPS-alpha » de l’éditeur « Editeur-lambda » : 1.2.250.1.999.1

OID de l’instance du « LPS-alpha » de l’« Editeur-lambda » installé dans le
« Cabinet Dr Dupont » : 1.2.250.1.999.1.432
-
OID des identifiants unique de document gérés au sein du LPS « LPSalpha » : 1.2.250.1.999.1.432.1
o
-
OID complet d’un identifiant de document : 1.2.250.1.999.1.432.1.98765
OID des identifiants de patient locaux gérés au sein du LPS « LPS-alpha » :
1.2.250.1.999.1.432.2
o
OID complet d’un identifiant patient local : 1.2.250.1.999.1.432.2.3456
5.2.2 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 »).
46 / 254
A titre d’exemple, un identifiant unique d’objet peut être obtenu :
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.
5.2.3 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
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).
5.2.4 Cadre d’exercice, Secteur d’activité, Profession / Spécialité
5.2.4.1 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
« practiceSettingCode » (voir [CI-ANX-PS-STRU] et [CI-JEUX-VALEURS]).
de
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 »
47 / 254
Délai de migration du LPS vers les nouvelles versions des Web Services
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
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
Ⓔ
EX_GEN-1377
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é.
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
« healthcareFacilityTypeCode » (voir [CI-ANX-PS-STRU] et [CI-JEUX-VALEURS]).
valeurs
Exemples : Etablissement Public de santé, Hôpital militaire du Service de Santé des Armées, Etablissement
Privé PSPH, Cabinet individuel, Cabinet de groupe, …
48 / 254
5.2.4.2 Secteur d’activité
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é
5.2.4.3 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 [CIANX-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
49 / 254
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 [CIANX-PS-STRU]).
5.3.1 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.
5.3.2 Accès Web-PS
Ⓔ
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 : http://www.outil-diagnostic.dmp.gouv.fr. 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.
Ⓔ
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.
50 / 254
5.3 Configuration poste de travail / serveur
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
un lecteur si le LPS ne lit pas la carte CPS (carte vitale seule),
o
deux lecteurs en parallèle si le LPS lit la carte CPS et la carte Vitale.
5.3.4 Dispositifs de lecture des cartes Vitale (logiciel)
Ⓔ
EX_GEN-1400
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 § 5.1.3 « Identification du patient par son INS ») et
d’autres traits d’identité du patient (également lus sur la carte Vitale).
5.3.4.1 Lecture des cartes Vitale
EX_GEN-1410
Ⓔ
L’accès et la lecture des cartes Vitale doit se faire via une API fournie par le GIE SesamVitale ; 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 § 5.1.3.4
« Calcul de l’INS-C ».
Ⓡ
REC_GEN-1420
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 :
http://www.sesam-Vitale.fr
51 / 254
5.3.3 Lecteur de cartes (matériel)
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.
5.3.4.2 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
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) ;
o
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 ;
o
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]).
52 / 254
Ⓔ
EX_GEN-1430
5.3.5.1 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 § 4.3.2.2 « 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-OSNAVIGATEURS].
5.3.5.2 En authentification indirecte (certificat serveur applicatif)
Ⓔ
EX_GEN-1450
En authentification indirecte, un certificat logiciel d’authentification pour personne morale
de la STS dont les utilisateurs dépendent est utilisé.
5.3.5.3 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 : http://integrateurscps.asipsante.fr/.
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 - 75015 PARIS :
o 2 exemplaires complétés et signés du «Contrat de diffusion des logiciels APICPS», 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.
53 / 254
5.3.5 Dispositifs pour l’authentification des utilisateurs
1) vous retourne par courrier un exemplaire du « Contrat de diffusion des logiciels APICPS (é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é.
5.3.6 Synchronisation du temps
Ⓔ
EX_GEN-1460
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] § 2.2.7 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çais1 « 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.
54 / 254
L’ASIP Santé :
Ⓔ
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.
55 / 254
5.3.7 Impression
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.
56 / 254
6 Exemples d’intégration du DMP dans les LPS
6 Exemples d’intégration du DMP dans les
LPS
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.
57 / 254
6.1 Exemple DMP minimal : intégration de l’AWPS contextuel
6.2.1 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)
58 / 254
6.2 Exemple d’un LPS en authentification directe
(cas typique du LGC)
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 § 6.3.2 « 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
- API CPS installés, opérationnels et conformes
- Java Virtual Machine (JVM) selon niveau d’intégration (si signature par AW-PS)
59 / 254
6.2.2 Exemple sans calcul de l’INS dans le LPS
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.
6.3.1 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.
60 / 254
6.3 Exemple d’un LPS en authentification
indirecte (cas typique du SIH)
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.
61 / 254
6.3.2 Exemple de type SIH « réparti »
Le profil IHE-PAM extension française [IHE-PAM-FR] prévoit la présence de l’INS dans ces
flux (champ PID-3).
Ⓡ
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
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).
62 / 254
6.3.3 IHE PAM-fr et DMP
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].
63 / 254
6.4 Cas des « Connecteurs / EAI »
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 1111-8 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 2006-6 du 4 janvier 2006 relatif à l’hébergement
de données de santé à caractère personnel (codifié aux articles R 1111-9 à R 1111-15-1 du
code de la santé publique). Ainsi, conformément à l’article L 1111-8 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 2006-6 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.
64 / 254
6.5 Cas des logiciels en mode SaaS
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
- 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.
65 / 254
6.6 Exemple de l’AW-PS non intégré au LPS
7 Accès sécurisé au DMP
7.1 Exigences générales de sécurité
Ⓔ
EX_0.X-1010
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.
7.1.1 Connexion au DMP
Ⓔ
Ⓡ
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
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 1024 - 2048 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.
66 / 254
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.
Comptes à rebours – timer d’inactivité et timer de renégociation


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
Activité PS
Inacti
vité
T3
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
Aucune
renégociation ne
sera lancée , le
timer d’inactivité
ayant coupé la
socket
Coupure de la
socket après 1h
d’inactivité
(T4-T3=1h)
T4
Inactivité
Timer d’inactivité 1h
coupure de la socket
Fig. 17 : Timer de renégociation et timer d’inactivité
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.
67 / 254
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 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
Ⓔ
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
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).
Ⓔ
EX_0.X-1060
Un jeton SAML 2.0 (nommé VIHF, « Vecteur d’Identification et d’Habilitation Formelles », voir
§ 7.2.3 «
Le VIHF ») doit par ailleurs transiter dans les messages.
68 / 254
Ⓡ
REC_0.X-1035
7.1.2 Vérification du certificat serveur du SI DMP
Le certificat serveur des interfaces LPS du SI DMP est émis par l’IGC-CPS.
Ⓔ
Ⓡ
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 http://tools.ietf.org/html/rfc3280 et RFC5280
sur http://tools.ietf.org/html/rfc5280).
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 http://annuaire.asipsante.fr/ 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]).
69 / 254
Validation du certificat serveur du SI DMP
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
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)
o
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)
o
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
cette information est calculée automatiquement par la visionneuse de
certificat Windows (onglet "Détail", "<tout>", dernière ligne) ;
o
vous pouvez utiliser la commande "openssl X509 -fingerprint" sur le fichier
certificat ;
o
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.
70 / 254
Ⓡ
REC_0.X-1100
7.1.3 Vérification du numéro d’homologation du LPS
Ce champ doit être renseigné dans un champ <saml:AttributeStatement> du VIHF.
Ⓔ
EX_0.X-1110
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
71 / 254
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.
7.2 TD0.1 - Authentification sur le DMP
7.2.1 Authentification directe par CPS, CPE, CPF
Ⓔ
EX_0.1-1010
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 § 7.1.1 « 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.
7.2.2 Authentification indirecte
Ⓔ
EX_0.1-1020
En authentification indirecte, l'utilisateur doit être authentifié localement (au sein de la
structure d'exercice).
EX_0.1-1025
Ⓔ
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é)
72 / 254
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.
Ⓔ
EX_0.1-1030
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’IGCCPS 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 § 11.5.2.
73 / 254
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 XMLDSIG.
7.2.3 Le VIHF
La durée de vie du jeton VIHF est de 1heure (voir champ //Assertion/@IssueInstant).
Le processus d’authentification peut renvoyer des codes erreur liés au traitement du VIHF
sous forme de « SOAP Fault » (voir le § 4.3.1.7 « Codes erreurs liés au processus
d’authentification et d’habilitation » de [CI-TR-CLI-LRD] et le § 11.4.2 « 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.
7.2.3.1 Le VIHF en authentification directe
Champ du VIHF
Structure
de soin
Emetteur
//Assertion/ds:Signature
Signature du VIHF
2
//Assertion/Issuer2
Identité de l'émetteur
contenue dans le certificat
(DN).
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
du certificat ayant initié la
connexion TLS.
Si le VIHF est signé : contrôle de
cohérence avec le DN du certificat
de signature
//Assertion/Issuer/@Forma
Constante
t
:"urn:oasis:names:tc:SAML:1.1:nam
Type de valeur utilisée pour
eid-format:X509SubjectName"
renseigner le champ Issuer
Contrôle de la valeur
(X509)
Struct_IdNat de la CPS/CPF
Identifiant_Structure
Contrôle de présence dans
l'annuaire
de soins ou du cabinet.
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.
de l’issuer.
DN du certificat d'authentification
de la CPE
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"
Pour les CPE directement
nominatives :
Struct_IdNat de la CPE
l'annuaire
Selon la RFC 2253 (ex : CN=801234567890+SN=DUPONT+GN=JEAN,OU=Médecin,O=TEST,C=FR)
74 / 254
Les données du Vecteur d’Identification et d’Habilitation Formelles (voir le § 4.3.1.5
« 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.
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.
l'annuaire
Utilisateur connecté
Secteur_Activite
Secteur d’activité dans
lequel exerce l’utilisateur
//Assertion/Subject/NameI
D
Identifiant de la personne
connectée
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 CPS/CPF
Struct_SectAct de la CPE
Contrôle que le SA fait partie du jeu Contrôle que le SA fait partie du jeu
de valeurs
de valeurs
HealthCareFacilityTypeCode
Contrôle que le SA ne fait pas partie Contrôle que le SA ne fait pas partie
des SA interdits pour ce mode
des SA interdits pour ce mode
d'authentification
d'authentification
nominatives :
PS_IdNat de la CPE
Contrôle de cohérence avec le
certificat d'authentification utilisé
pour monter le canal TLS
l'annuaire
PS_IdNat de la CPS/CPF
l'annuaire PS
nominatives :
PS_IdNat de la CPE
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
exclusif et qui ont une CPE :
le PS_IdNat doit être transcodifié
(avec xxxx = Identifiant national du
pharmacien) :
si IdNat 3000000001/Axxxx ou
3000000018/A xxxx => remplacer
3000000001/A ou 3000000018/A
par "0"
si IdNat 3000000001/Rxxxx ou
3000000018/R xxxx => remplacer
3000000001/R ou 3000000018/R
75 / 254
à l'identifiant du PS et la structure
fournie.
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
urn:oasis:names:tc:xacml:2.
0:subject:role
(1ère occurrence
obligatoire)
Profession de la personne
connectée
PS_Prof de la CPS
ou
PS_FutureProf de la CPF
l'annuaire entre la profession liée à
l'identifiant et le code profession
fourni
nominatives :
informations fournies par le LPS.
Pas de contrôle
Ne pas renseigner
nominatives :
code = "SECRETARIAT_MEDICAL"
codeSystem="1.2.250.1.213.1.1.4.6"
Controle du code et du codeSystem
nominatives :
code = "SECRETARIAT_MEDICAL"
codeSystem="1.2.250.1.213.1.1.4.6"
code="21"
codeSystem="1.2.250.1.71.1.2.7"
Pour les CPE directement et non
directement nominatives :
non renseigné.
Pour les médecins :
PS_SpécRPPS de la CPS/CPF
Pour les pharmaciens diplômés et
en remplacement exclusif et qui
l'annuaire
ont une CPE :
0:subject:role
Certaines spécialités n'ont pas accès
code="A" ou "G"
(2ème occurrence
au DMP. Exemple : les médecins du
codeSystem="1.2.250.1.71.4.2.6"
uniquement et
travail (SM25 et SCH35)
displayName="Pharmacien titulaire
obligatoirement pour les
d'officine" ou "Pharmacien
médecins et pharmaciens)
Pour les pharmaciens :
biologiste".
Spécialité de la personne
PS_TabPharm de la CPS/CPF
contrôle de cohérence dans
connectée
l'annuaire
l'annuaire
Certaines spécialités n'ont pas accès
Pour les pharmaciens en formation
au DMP.
et en remplacement exclusif et qui
ont une CPE :
non renseigné car les pharmaciens
76 / 254
par "8"
si IdNat 3000000001/Exxxx ou
3000000018/E xxxx => remplacer
3000000001/E ou 3000000018/E
par "9"
nominatives :
Ne pas renseigner
Assertion SAML
//Assertion/AuthnStateme
nt/AuthnContext/AuthnCo
ntextClassRef
Mode d'authentification en
local
Constante
:"urn:oasis:names:tc:SAML:2.0:ac:cl
asses:SmartcardPKI"
//Assertion/@xmnls
namespace xml SAML
Constante
Constante
:"urn:oasis:names:tc:SAML:2.0:asser :"urn:oasis:names:tc:SAML:2.0:asser
tion"
tion"
Constante
:"urn:oasis:names:tc:SAML:2.0:ac:cl
asses:SmartcardPKI"
//Assertion/@Version
Version utilisée
Constante : "2.0"
Constante : "2.0"
//Assertion/@ID
Identifiant unique de
l'assertion (OID
recommandé)
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.
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.
Date/Heure de connexion de
l’utilisateur dans le système source
Date/Heure de connexion de
l’utilisateur dans le système source
Ne pas renseigner
car aucune PSSI n’est définie à ce
jour
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 <
Facultatif
Si présent, contrôle de la validité à
l'instant I :
T < (NotBefore) < I <
//Assertion/@IssueInstant
l'assertion SAML
nt/@AuthnInstant
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
//Assertion/Conditions/@N
otBefore
Date et heure de début de
validité de l’assertion
77 / 254
en formation ne sont pas inscrits sur
les tableaux.
VIHF_Version
Version du VIHF utilisée
Patient
Authentification_mode
Mode d'authentification
utilisé
0:resource:resource-id
Identifiant du patient
concerné par la requête
LPS
Système cible
Ressource_URN
Ressource visée par
l’utilisateur
min(T+1h,NotOnOrAfter)
min(T+1h,NotOnOrAfter)
Constante : "1.0" ou "2.0"
si version VIHF 1.0 :
non présent
non présent
si version VIHF >= 2.0 :
Constante : "DIRECTE"
Constante : "DIRECTE"
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 :
Constante: "urn:dmp"
- "normal" : pour un accès normal
- "bris_de_glace" : lorsque le PS a
besoin de consulter le DMP d’un
:subject:purposeofuse
patient en cas d’urgence, sans avoir
Mode d’accès demandé par
la possibilité de lui demander son
l’utilisateur (normal, bris de
autorisation
glace ou centre de
- "centre_15" : réservé aux LDR qui
régulation).
indiquent ainsi l’usage « centre de
régulation » spécifique à leur rôle ;
Contrôle de 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
Facultatif
(usage à des fins de traces)
Facultatif
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
d’homologation (différentier les
différentes versions de logiciels
éventuellement associés à un n°
d'homologation, en cas de
problème)
Nom du LPS
d'homologation (différentier les
différents logiciels éventuellement
associés à un n° d'homologation, en
cas de problème).
N° de version
d’homologation (différentier les
différentes versions de logiciels
éventuellement associés à un n°
d'homologation, en cas de
problème)
LPS_Nom
Nom du logiciel utilisé
LPS_Version
Version du logiciel utilisé
78 / 254
otOnOrAfter
Date et heure de fin de
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
Contrôle de l'homologation DMP
Compatibilité validée pour la
transaction appelée
Champ du VIHF
Emetteur
//Assertion/ds:Signature
Signature du VIHF
//Assertion/Issuer3
Identité de l'émetteur
contenue dans le certificat
(DN).
Utilisateur connecté
Structure de soin
//Assertion/Issuer/@Forma
t
Type de valeur utilisée pour
renseigner le champ Issuer
(X509)
3
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 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"
de soins ou du cabinet.
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
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
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
//Assertion/Subject/NameI
D
Identifiant de la personne
connectée
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
Selon la RFC 2253 (ex : CN=testdmp.etablissement-de-test.fr, OU=10B0011797, L=Paris (75), O=TEST, C=FR)
79 / 254
7.2.3.2 Le VIHF en authentification indirecte
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
Pour les PS :
Prendre la valeur la plus appropriée parmi les codes du jeu de valeurs CISIS "subjectRole" avec un codeSystem=1.2.250.1.71.1.2.7 (table G15)
Contrôle du codeSystem
0:subject:role
Pour les PF :
(1ère occurrence
Prendre la valeur la plus appropriée parmi les codes du jeu de valeurs CIobligatoire)
SIS "subjectRole" avec un codeSystem=1.2.250.1.71.1.2.8 (table G16)
Profession de la personne
Contrôle que code et codeSystem font partie du jeu de valeur subjectRole
connectée
Pour les autres :
Prendre la valeur la plus appropriée parmi les codes du jeu de valeurs CISIS "subjectRole" avec un codeSystem="1.2.250.1.213.1.1.4.6".
Pour les médecins :
Prendre la valeur la plus appropriée parmi les codes du jeu CI-SIS
0:subject:role
"subjectRole" de valeurs dont le codeSystem=1.2.250.1.71.4.2.5 (table
(2ème occurrence
R01)
uniquement et
obligatoirement pour les
médecins et pharmaciens)
Pour les pharmaciens :
Spécialité de la personne
Prendre la valeur la plus appropriée parmi les codes du jeu de valeurs CIconnectée
SIS "subjectRole" avec un codeSystem=1.2.250.1.71.4.2.6 (table G05)
//Assertion/@xmnls
namespace xml SAML
Prendre la valeur la plus appropriée parmi les valeurs possibles indiquées
dans le document http://docs.oasis-open.org/security/saml/v2.0/samlauthn-context-2.0-os.pdf
La valeur utilisée doit être cohérente avec le mode d’authentification
locale de l’utilisateur dans le LPS
Constante :"urn:oasis:names:tc:SAML:2.0:assertion"
//Assertion/@Version
Version utilisée
Constante : "2.0"
Assertion
SAML
nt/AuthnContext/AuthnCo
ntextClassRef
Mode d'authentification en
local
80 / 254
: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…
//Assertion/@IssueInstant
l'assertion SAML
nt/@AuthnInstant
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
otOnOrAfter
Date et heure de fin de
VIHF_Version
Version du VIHF utilisée
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.
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)
non présent
Patient
Authentification_mode
Mode d'authentification
utilisé
0:resource:resource-id
Identifiant du patient
concerné par la requête
Système cible
Ressource_URN
Ressource visée par
l’utilisateur
:subject:purposeofuse
Mode d’accès demandé par
l’utilisateur (normal).
Constante : "INDIRECTE"
INS du patient
Controle de présence si la transaction concerne un DMP donné à savoir :
- "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
81 / 254
//Assertion/@ID
Identifiant unique de
l'assertion (OID
recommandé)
Non applicable en authentification indirecte.
LPS_ID
Numéro de série ou
identifiant de l’installation
du logiciel
Facultatif
LPS
LPS_Nom
Nom du logiciel utilisé
LPS_Version
Version du logiciel utilisé
LPS_ID_HOMOLOGATION_
DMP
Numéro d'homologation du
logiciel
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)
Contrôle de l'homologation DMP Compatibilité validée pour la transaction
appelée
82 / 254
Mode_Acces_Raison
Explication de la raison de
l’usage du bris de glace.
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.
83 / 254
7.3 Règles de gestion des droits dans le DMP
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)
OUI
PROCESSUS DE REACTIVATION DE DMP
(selon le souhait du patient)
Fin du
scénario
NON (le DMP existe)
DMP Fermé
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
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 …)
NON
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 § 7.3.1 « 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 § 0 « Droits fonctionnels par mode d’authentification et par profil utilisateur ».
84 / 254
Début
INS du patient présenté
dans une transaction
impliquant l’acteur de santé AS
7.3.1 Autorisations et droits d’accès à un DMP
7.3.1.1 Donner une autorisation d’accès à un PS / à une STS
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 ;
7.3.1.2 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.
85 / 254
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 »).
7.3.1.3 Erreurs transactionnelles liées à l’autorisation ou à l’état du DMP
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 § 7.3.1.4) 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 § 7.3.1.4) 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 ».
86 / 254
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.
7.3.1.4 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 »).
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).
7.3.1.4.1 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_0.1-1040
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.
Ⓔ
EX_0.1-1050
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.
87 / 254
Le patient peut s’opposer à l’un et / ou l’autre de ces modes d’accès spécifiques.
7.3.1.4.2 Mode centre de régulation


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.
7.3.1.4.3 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 ».
88 / 254
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 :
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.
89 / 254
7.3.2 Droits fonctionnels par mode d’authentification et par profil
utilisateur
Authentification directe
Authentification
acteur
mode_accès
TD0.1
TD0.2
Test d'existence d'un DMP et vérification de l'autorisation
TD0.3
Mise à jour de l'autorisation
Se déclarer autorisé
Supprimer son autorisation
Se déclarer MT
Se supprimer MT
TD0.4
Liste des DMP autorisés
TD0.5
Recherche d'un patient dans le DMP sans INS
TD0.9
Accès Web PS contextuel
TD1.1
Création d'un DMP
TD1.2
Réactivation d'un DMP
TD1.3
Données administratives d'un DMP
TD1.3a
Consultation des données administratives d'un DMP
TD1.3b
Mise à jour des données administratives d'un DMP
TD1.4
Fermeture d'un DMP
TD1.5
TD1.5a
Création du compte internet patient
TD1.5b
Ajout d'un canal OTP
TD1.5d
Mise à jour des information du compte internet
TD1.6
ALIMENTATION
TD2.1
Alimentation d'un DMP
Alimentation d'un DMP par CPE pour les secrétaires
TD2.2
médicales du secteur libéral
CONSULTATION
TD3.1
Recherche de documents sur un DMP
Rechercher les métadonnées
Rechercher la référence d'un document
TD3.2
Consultation d'un document sur un DMP
Documents non masqués aux PS
Documents masqués aux PS
Documents non visibles du patient
Documents archivés
Documents obsolètes (anciennes versions)
Documents supprimés
TD3.3
Gestion des attributs d'un document
TD3.3a
Masquer un document aux PS
TD3.3a
Démasquer un document aux PS
TD3.3b
Rendre un document visible au patient
TD3.3d
Archiver un document *
TD3.3d
Désarchiver un document *
TD3.3c
Supprimer un document *
oui (1)
non (2)
oui (3)
oui (4)
oui (5)
Authentification indirecte
CPS
normal
PS non médecin
régulation
bris de glace
normal
CPE
Médecin (non MT)
régulation
bris de glace
Médecin Traitant (MT)
normal
bris de glace
Certificat ES
non PS
normal
tous
normal
tous
régulation
oui
oui
oui
oui
oui
oui
oui
oui
oui
oui
oui
oui
oui
oui
oui
oui
oui
oui
oui
oui
oui
oui
oui
oui
non
non
oui
oui
oui
non
non
non
non
oui
oui
oui
non
non
non
non
oui
non
oui
oui
oui
oui
oui
oui
oui
oui
non
non
non
non
oui
oui
oui
non
non
non
non
oui
non
oui
oui
oui
non (2)
oui
oui
oui
oui
non
non
non
non
oui
non
oui
oui (1)
non
non
non
non
oui
oui
oui (1)
oui
non
non
oui (3)
oui
non
non
non
non
non
non
oui
non
oui
oui
non
non
non
non
oui
oui
non
non
non
non
oui
oui
non
non
oui
oui
oui
oui
non
non
oui
oui
oui
oui
non
non
oui
non
non
oui
oui
oui
oui
non
non
oui
non
non
oui
oui
oui
oui
non
non
oui
oui
non
oui
oui
non
oui
non
non
oui
oui
oui
oui
non
non
non
non
non
non
non
non
oui
oui
oui
oui
non
non
non
non
non
non
non
non
oui
oui
oui
oui
non
non
non
non
oui
oui
oui
non
oui
oui
oui
non
non
non
non
non
oui
oui
oui
oui
oui
oui
oui
oui
non
oui (4)
oui (4)
non
non
non
non
non
non
non
non
oui (4)
non
non
oui
oui
oui
oui
oui
oui
oui
oui
oui
oui
oui
oui
oui
oui
oui
oui
non
oui (5)
non
oui (5)
non
oui (5)
oui
oui (6)
oui
oui
oui
oui
oui
oui (7)
oui
oui
oui
oui
oui
oui (7)
oui
oui
oui
oui
oui
oui (6)
oui
oui
oui
oui
oui
oui (7)
oui
oui
oui
oui
oui
oui (7)
oui
oui
oui
oui
oui
oui
oui
oui
oui
oui
oui
oui (7)
oui
oui
oui
oui
non
non
non
non
non
non
non
non
non
non
non
non
non
non
non
non
non
non
oui
oui (8)
oui
oui (8)
oui (8)
oui (8)
non
non
non
non
non
oui (8)
non
non
non
non
non
oui (8)
oui
oui (8)
oui
oui
oui
oui
non
non
non
oui
oui
oui (8)
non
non
non
oui
oui
oui (8)
oui
oui
oui
oui
oui
oui
non
non
non
oui
oui
oui (8)
non
non
non
non
non
oui (9)
non
non
non
non
non
oui (9)
non
non
non
non
non
oui (9)
* Pour un document du patient, cette action n'est possible que par le MT (ou le patient lui-même)
oui (6)
TD0.3 - L'autorisation est donnée à la structure
oui (7)
TD0.3 - Si le médecin est déjà déclaré MT, il ne peut pas se redéclarer MT.
TD0.4 - Liste des DMP autorisés : recherche limitée, par date, aux nouvelles autorisations
oui (8)
TD2.1/TD2.2 : Ajout de documents. Imputabilité à la structure.
oui (9)
TD3.1 - Recherche référence d'un document en authentification indirecte ou par CPE (en vue de sa suppression par ex.)
TD3.2 - Ses propres documents uniquement (ceux dont il est l'auteur)
TD3.2 - Consultation d'un document masqué en mode bris de glace ou centre 15 possible uniquement si
autorisation par le patient
TD3.3 - Ses propres documents uniquement (ceux dont il est l'auteur)
TD3.3 - Les documents de la structure uniquement (ceux dont la structure (ou une CPE de la structure) est
l'auteur)
Tableau 19 : Droits fonctionnels par mode d’authentification et par profil utilisateur
90 / 254
7.3.3 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 [CIPARTAGE]).
91 / 254
7.4 TD0.2 - Test d’existence d’un DMP et
vérification de l’autorisation
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.
7.4.1 Prérequis
1. le PS ou la STS est authentifié (TD0.1) ;
2. l’INS est disponible.
7.4.2 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 § 5.1.3.
REC_0.2-1010
Ⓡ
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.
7.4.3 Transaction
La transaction technique est décrite dans le § 3.3.2 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 « reasonCode/@code » doit être positionné à « TEST_EXST » (voir § 8.8.2.5).
7.4.3.1 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 :
92 / 254
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.
Card. XPath HL7
Requête paramétrée
Identifiant unique du query
Oid des query dans le LPS
Identifiant du query dans le LPS
Statut du query
Liste des paramètres
Paramètre de type Identifiant du
patient
Valeur du paramètre
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
OID de l’identifiant
INS
Nom du paramètre, contraint
par HL7
Remarques
queryByParameter
queryId
@root
@extension
statusCode/@code
parameterList
[1..1]
[1..1]
[1..1]
[1..1]
Oid géré par le LPS
Id généré par le LPS
Fixé à « new »
Nom du champ
patientIdentifier
value
Pour un INS-C :
1.2.250.1.213.1.4.2
Pour un INS-A :
1.2.250.1.213.1.4.1
Valeur de l’INS
@root
@extension
[1..1]
semanticsText
Fixé à « Patient.id »
Tableau 20 : TD0.2 – Données en entrée
7.4.3.2 Données en sortie
En retour, le message HL7 V3 Patient Registry
Response »(PRPA_IN201308UV02) est renvoyé.
Get
Demographics
Query
7.4.3.2.1 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
Code/@code
« 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.
93 / 254
Donnée
Elément
Description
Le DMP existe
controlActProcess/queryAck/queryResponse
Code/@code
« OK »
Le patient
controlActProcess/subject/registrationEvent/
subject1/patient
INS du patient
patient/Id
Nom d’usage
patient/patientPerson/name/family[@qualifie
r = 'SP']
Nom de
naissance si
renseigné
patient/patientPerson/name/family[@qualifie
r = 'BR']
Prénom
patient/patientPerson/name/given
Sexe
patient/patientPerson/administrativeGenderCode/
@code
Date de
naissance
patient/patientPerson/birthTime/@value
DMP Actif /
Fermé
patient/@statusCode


Date de
fermeture
controlActProcess/subject/registrationEvent/
effectiveTime/@value
Si le DMP existe mais est fermé
Motif de
fermeture
controlActProcess/reasonOf/detectedIssueEvent/c
ode
Peut contenir plusieurs valeurs qui se distinguent
(INS-C ou INS-A) par l’attribut root.
DMP actif : @statusCode="active"
DMP fermé : @statusCode="terminated"
Avec la structuration définie au § 8.5.3.1 ;
Valeurs possibles : voir tableau ci-dessous.
Raison de
fermeture
controlActProcess/reasonOf/
detectedIssueEvent/text
Statut de
l’autorisation
attentionLine (à la racine du message)
Valeurs possibles : voir tableau ci-dessous.
avec un élément fils
keyWordText/@code="AUTORISATION"
Exemple :
<attentionLine>
<keyWordText code="AUTORISATION"
codeSystem="1.2.250.1.213.4.1.2.6.1"/>
<value xsi:type="CV" code="VALIDE"
codeSystem="1.2.250.1.213.4.1.2.6.2"/>
</attentionLine>
Médecin traitant
attentionLine (second élément à la racine du
message)
Cette information n'est pas retournée en
authentification indirecte.
avec un élément fils
keyWordText/@code="STATUT_MT"
Exemple :
<attentionLine>
<keyWordText code="STATUT_MT"
codeSystem="1.2.250.1.213.4.1.2.6.3"/>
<value xsi:type="BL" value="true"/>
</attentionLine>
Tableau 22 : TD0.2 – Données en sortie – le DMP existe
94 / 254
Dans le cas où le DMP existe :
Nomenclature des motifs de fermeture (OID 1.2.250.1.213.4.1.2.4) :
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 value/@code) :
Code AUTORISATION
NON_EXISTE
Description
Pas d’autorisation existante
INTERDIT
Blocage d’accès (PS uniquement, pas STS)
EXPIRE
Autorisation ayant pris fin
VALIDE
Autorisation valide
Tableau 24 : TD0.2 – Statuts d’autorisation retournés
Valeurs possibles pour le statut médecin traitant (élément value/@value) :
Code MT
Description
false
Autorisation simple
true
Autorisation de type MT
Tableau 25 : TD0.2 – Statut MT retourné
7.4.3.2.2 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
95 / 254
7.5 TD0.3 - Mise à jour de l’autorisation d’accès
Cette transaction permet également de mettre à jour le statut de médecin traitant (ajout ou
retrait).
7.5.1 Prérequis
2. l’INS est disponible ;
3. pour la création de l’autorisation : le patient a donné l’autorisation d’accès.
7.5.2 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
NON
PROCESSUS DE DECISION
D’ACCES SANS AUTORISATION
OUI
Le PS est Médecin Traitant du patient
Case MT cochée par médecin avec CPS
NON
Fin du
Scénario
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
96 / 254
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).
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_0.3-1020
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.
Ⓡ
REC_0.3-1030
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.
97 / 254
Ⓔ
EX_0.3-1010
7.5.2.1 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.
7.5.2.2 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.
7.5.2.3 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.
7.5.2.4 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.
98 / 254
7.5.3 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) ;


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.
Fig. 27 : TD0.3 – diagramme de classe des données en entrée
Nom du champ
Type
Card
Action
Enum
[1..1]
Role
Enum
[0..1]
Description
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.
Le tableau suivant liste les différentes possibilités d’appel de la fonction :
action
role
AJOUT
[non fourni]
AJOUT
Opération réalisée
Ajoute une autorisation simple
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
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)
MEDECIN_TRAITANT Supprime le rôle médecin traitant du PS
Tableau 29 : TD0.3 – valeurs possibles pour le paramètre « action »
99 / 254
Les actions possibles sont :
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
7.5.3.2.1 Codes d’erreur
100 / 254
7.6 TD0.4 - Liste des DMP autorisés
7.6.1 Prérequis
7.6.2 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_0.4-1010
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_0.4-1020
Ⓔ
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.
101 / 254
1. le PS ou la STS est authentifié (TD0.1).
7.6.3 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.
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
date de filtrage à partir de laquelle la recherche est
effectuée
startDate
D
format YYYYMMDDhhmmss - La date doit être passée
en UTC (universal coordinated time) – le LPS doit
[1..1] traduire sa date locale en UTC
Type de date de recherche :
dateType
Enum
[1..1]

LASTAUTORIZATION : recherche par rapport à
la date d'autorisation du PS/STS

LASTDOC : recherche par rapport à la date de
dernier ajout d’un document
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).
102 / 254
Fig. 34 : TD0.4 – Diagramme de classe des données en sortie
Nom du champ
Type
Taille
Card
Description
Status
A
50
[1..1]
Context
A
text
[0..1]
Tableau 35 : TD0.4 – Accusé de réception de traitement
103 / 254
Les données administratives des patients retournées sont les suivantes :
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
-
Ce champ est obsolète et ne doit plus être utilisé par le LPS (ignorer
[1..1] ce champ)
Date de dernier accès sur le dossier du patient par le PS
lastAccessDate
A
14
Format YYYYMMDDhhmmss - la date est retournée en UTC
(universal coordinated time) – le LPS doit convertir dans sa date
[1..1] locale avant affichage à l’utilisateur
Date de dernière modification du dossier patient
lastUpdateDate
A
14
[1..1]
locale avant affichage à l’utilisateur
Date de dernier ajout de document sur le dossier du patient
lastAddDate
A
14
[1..1]
locale avant affichage à l’utilisateur
Le champ status de l’accusé de réception du traitement contient un code erreur et le champ
contexte un message associé.
104 / 254
Nom du champ
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.
7.7.1 Prérequis
2. le PS possède un ou plusieurs traits d’identité du patient permettant de l’identifier.
7.7.2 Cinématique
Le LPS fournit un ou plusieurs traits d’identité du patient et récupère 0 ou N résultats.
7.7.3 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) »).
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
livingSubjectName.value.familly
Card.
[0..1]
Description
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
105 / 254
7.7 TD0.5 - Recherche sans INS de patients dans
le DMP
XPath HL7
Card.
Valeur / remarque
PRPA_IN201305UV02
[1..1]
Racine du message HL7
@ITSVersion
[1..1]
Eléments « d’entête » du message […]
[1..1]
controlActProcess
@classCode
@moodCode
Code
@code
@codeSystem
queryByParameter
queryId
@root
@extension
statusCode@ code
parameterList
livingSubjectAdministrativeGender
value/@code
semanticsText
livingSubjectBirthTime
value/@value
semanticsText
livingSubjectName
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
[0..1]
[0..1]
[0..1]
[0..1]
[0..1]
[0..1]
[0..1]
Fixé à « XML_1.0 »
Voir le chapitre structure commune des messages HL7
envoyés dans la partie « gestion administrative du
dossier ».
corps de la requête HL7
Valeur fixée à « CACT »
Valeur fixée à « EVN »
PRPA_TE201305UV02
2.16.840.1.113883.1.6
Identifiant unique du query, généré par le LPS
Racine d’OID géré par le LPS
Identifiant unique généré par le LPS
Valeur fixé à « new »
Liste des paramètres du query
Critère sexe
Valeur du critère : M, F ou U
Fixé à « LivingSubject.administrativeGender »
Critère date de naissance
Valeur du critère : format AAAAMMJJ
Fixé à « LivingSubject.birthTime »
Critères nom/prénom
Si présent : use = « SRCH » (permet une recherche
value/@use
[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
value/@use
[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
7.7.3.1.1 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 « value/@use » 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 « value/@use » 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…).
106 / 254
Le tableau suivant décrit la structure du message HL7 en entrée :
7.7.3.1.2 Recherche sur l’adresse
Si l’attribut « value/@use » de patientAddress est fixé à SRCH, alors une recherche sur city
= « Bor » retournera tous les dossiers dont la ville commencent par « Bor » (Bora Bora,
Bordeaux…).
7.7.3.1.3 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 »).
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 V3 2008 utilisée dans cette transaction, le code de retour est
positionné dans l’élément : acknowledgement/typeCode/@code="AA"
(au lieu de
acknowledgement/@typeCode="AA" dans la version HL7 v3 2009).
XPath HL7
Card. Valeur / remarque
PRPA_IN201306UV02
[1..1]
@ITSVersion
[1..1]
Eléments « d’entête » du message […]
[1..1]
controlActProcess
@classCode
@moodCode
code
@code
@codeSystem
subject
@typeCode
@contextConductionInd
registrationEvent
@classCode
@moodCode
statusCode/@code
subject1
@typeCode
patient
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
[0..N]
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
Voir le chapitre structure commune des messages HL7
renvoyé par le DMP dans la partie « gestion
administrative du dossier ».
corps de la requête HL7
PRPA_TE201306UV02
2.16.840.1.113883.1.6
Occurrence d’un résultat de la réponse (un patient)
Valeur fixé à « SUBJ »
Valeur fixé à « false »
Valeur fixée à « REG »
Valeur fixée à « active »
Valeur fixée à « SBJ »
107 / 254
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.
[1..1]
[1..2]
@root
[1..1]
Valeur fixée à « PAT »
Identifiant(s) du patient : INS-A et/ou INS-C
1.2.250.1.213.1.4.1 pour INS-A
1.2.250.1.213.1.4.2 pour INS-C
Valeur de l’INS
Valeur fixée à « active »
@extension
statusCode/@code
patientPerson
@classCode
@determinerCode
name
prefix
family[@qualifier="SP"]
family[@qualifier="BR"]
given
administrativeGenderCode/@c
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
[0..1]
[1..1]
[0..1]
[1..1]
[1..1]
Sexe : M, F ou U
birthTime/@value
addr
postalCode
city
subjectOf1
@typeCode
[1..1]
[0..1]
[0..1]
[0..1]
[1..1]
[1..1]
Date de naissance (format AAAAMMJJ)
Adresse du patient
Code postal
Ville
ode
queryMatchObservation
@classCode
@moodCode
code/@code
value
@xsi:type
@value
custodian
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
@typeCode
assignedEntity
@classCode
id/@root
queryAck
queryId
@root
@extension
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
queryResponseCode/@code
resultTotalQuantity/@value
resultCurrentQuantity/@value
resultRemainingQuantity/@value
queryByParameter […]
[1..1]
[1..1]
[1..1]
[1..1]
[1..1]
@classCode
id
Valeur fixée à « PSN »
Valeur fixée à « INSTANCE »
Civilité : Mr, Mme, Mlle
Nom usuel
Nom de naissance (nom de famille)
Prénom
Valeur fixée à « SBJ »
Indicateur de correspondance du résultat (pourcentage de
correpondance par rapport aux critères passés)
Valeur fixée à « COND »
Pour le DMP : valeur fixée à « POURCENTAGE »
Valeur fixée à « INT »
Valeur de la correspondance en %
Organisation responsable de l’identité patient fournie (le
DMP)
Valeur fixée à « CST »
Valeur fixée à « ASSIGNED »
OID du DMP : 1.2.250.1.213.4.1.1.1
Indicateur de retour de l’exécution du query
Identifiant du query envoyé par le LPS
root de l’identifiant du query envoyé par le LPS
extension de l’identifiant du query envoyé par le LPS
Voir [IHE-PDQV3] § 3.47.4.2.3 Expected Actions :
« OK » si le query retourne au moins un résultat
« NF » si le query ne retourne aucun résultat
Nombre de résultats présents dans la réponse *
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
108 / 254
Ⓔ

accusé de réception du traitement « ok » (acknowledgement/typeCode/@code=AA) ;

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).
EX_0.5-1010
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, 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
(acknowledgement/typeCode/@code=AE),
un code (acknowledgementDetail/@code),
un message d’erreur (acknowledgementDetail/text).
en
erreur
109 / 254
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_0.9-1010
Ⓡ
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).
7.8.1 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 :
http://www.outil-diagnostic.dmp.gouv.fr ;
110 / 254
7.8 TD0.9 - Accès Web-PS Contextuel


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 Poste fonctionnel en fin d’installation sans avoir à redémarrer,
o 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
111 / 254
Cet outil :


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
§ 0.
112 / 254
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 :
7.8.2 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.2
Test d'existence d'un DMP
TD0.3
TD0.4
D
D
D
TD1.1
Création d'un DMP
I
D
TD1.2
I
TD1.3
D
TD1.4
Fermeture d'un DMP
I
TD1.5
Accès Internet du patient
I
TD1.6
I
ALIMENTATION DU DMP
TD2.1 / TD2.2
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
D
D
Tableau 41 : Correspondance entre transactions et URL de passage de contexte
113 / 254
https://../CreationDMP/[paramètres]
https://../VolontesEtDroits/[INS]
https://../ParcoursDeSoins/[INS]
https://../Documents/[INS]
https://../HistoriqueAcces/[INS]
https://../GestionDMPPatient/[INS]
https://../DossierPatient/[INS]
https://../Parametrages
https://../TableauDeBord
D = accès direct
I = étape intermédiaire requise
Accès Web-PS contextuel
https://../TableauDeBord/[INS]
TD0.9
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 : https://ledmp.dmp.gouv.fr
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é.
#
url
Fonctionnalité
Liste des
paramètres
obligatoires
Liste des
paramètres
optionnels
1
Accès au tableau de bord du
professionnel de santé
https://nom de domaine/AccesDirect/TableauDeBord
ou
https://nom de domaine/AccesDirect/TableauDeBord/[INS]
aucun
INS du patient
2
Page d’accueil du DMP d’un patient
https://nom de domaine/AccesDirect/DossierPatient/[INS]
INS du patient
aucun
3
Page d’information du patient
(données administratives)
https://nom de domaine/AccesDirect/GestionDMPPatient/[INS]
INS du patient
aucun
4
Page de la liste des documents
https://nom de domaine/AccesDirect/Documents/[INS]
INS du patient
aucun
5
Page du parcours de soins
https://nom de domaine/AccesDirect/ParcoursDeSoins/[INS]
INS du patient
aucun
https://nom de domaine/AccesDirect/HistoriqueAcces/[INS]
INS du patient
aucun
aucun
aucun
INS du patient
aucun
aucun
voir § 7.8.3.9
6
7
8
9
Page d’historique des accès d’un
DMP
Page de paramétrage du
professionnel de santé
Page du document volontés et
souhaits du patient
Page de création du DMP
https://nom de domaine/AccesDirect/Parametrages
https://nom de domaine/AccesDirect/VolontesEtDroits/[INS]
https://nom de domaine/AccesDirect/CreationDMP/[paramètres]
Tableau 42 : Structure des url d’accès direct
114 / 254
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.
7.8.3.1 Tableau de bord
(https://nom de domaine/AccesDirect/TableauDeBord ou
https://nom 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 ».
115 / 254
Ⓔ
EX_0.9-1020
7.8.3.2 Accueil DMP Patient
(https://nom de domaine/AccesDirect/DossierPatient/[INS])






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.
116 / 254
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 :
7.8.3.3 Gestion du DMP
(https://nom de domaine/AccesDirect/ GestionDMPPatient/[INS])






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 »).
7.8.3.4 Documents
(https://nom 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 [CIPARTAGE] § 4.1) et des droits associés à son profil (voir § 0).
117 / 254
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 :
7.8.3.5 Parcours de soins
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 ».
Ⓡ
REC_0.9-1030
L’ancienne URL https://nom 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.
7.8.3.6 Historique des accès
(https://nom 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.
118 / 254
(https://nom de domaine/AccesDirect/ParcoursDeSoins/[INS])
7.8.3.7 Paramétrages
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 § 5.2.4 « 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.
7.8.3.8 Document volontés et droits du patient
(https://nom 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.
119 / 254
(https://nom de domaine/AccesDirect/Parametrages)
7.8.3.9 Création de DMP
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, email).
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.
A
10
[0..1]
adresse électronique
A
64
[0..1]
adresse
A
38
[0..1]
adresse
complémentaire
A
38
[0..1]
code postal
A
5
Ville
A
pays
A
téléphone mobile
Mot clé
Description
TELMOBILE=
Téléphone mobile du
patient
EMAIL=
Adresse électronique du
patient
ADRESSE=
Adresse du patient
ADRESSECOMP=
Adresse complémentaire
du patient
[0..1]
CODEPOSTAL=
Code postal du patient
38
[0..1]
VILLE=
Ville du patient
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).
120 / 254
(https://nom de domaine/AccesDirect/CreationDMP/[paramètres])
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 :
https://.../AccesDirect/CreationDMP/QURSRVNTRT0yIHJ1ZSBkdSBiYWN8VklMTEU9UEFS
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
Pas de carte
vitale dans le
lecteur
Traitement
/ résultat
Capture d’écran / Description
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
121 / 254

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 »
Présence de
2 ayants
droits sur la
CV sans
DMP
Aucun
message
d’erreur, on
Le DMP du
redirige vers la
patient existe
page de
déjà
sélection de la
personne sur la
CV
Aucun ayant
droit sur la
carte vitale
Aucun
message
d’erreur,
redirection vers
la page
sélection de la
personne sur la
CV
Le DMP est
fermé
Aucun
message
d’erreur,
redirection vers
la page de
sélection de la
personne sur la
CV
Autre cas
d’erreur
Affichage de
l’erreur
classique
Idem écran actuel en web PS
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
122 / 254
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
o
TD0.2 « Test d’existence d’un DMP et vérification de l’autorisation ».
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
o
TD1.1 « Création d’un DMP » ;
123 / 254
8 Création et gestion administrative du DMP
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
o
TD0.2 « Test d’existence d’un DMP et vérification de l’autorisation» ;
EX_1.X-1010
Ⓔ
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 § 5.1.3.
124 / 254
Si le DMP est Fermé
Le Patient dispose de sa carte Vitale
Le poste est équipé d’un lecteur
fonctionnel
NON
Le Patient connait son INS
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)
Retour : DMP Existe
Retour : DMP Existe
NON
OUI
Le Patient souhaite créer son DMP
OUI
NON
NON
Fin du
scénario
NON
Fin du
scénario
NON
Fin du
scénario
Contrôle de l’identité du DMP
par rapport à l’identité du patient local
Fin du
scénario
Identité contrôlée OK
PROCESSUS DE
CREATION DE DMP
Fin
Patient local,
INS associé à un DMP
OUI
OUI
Retour : DMP Actif
OUI
Fin
Patient local,
NON
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,
Fig. 46 : Accueil du patient
125 / 254
Début
Arrivée du patient
Patient créé dans le LPS
INS non présent dans le LPS
ou non associé à un DMP
Cette transaction permet de créer un DMP pour un patient.
8.2.1 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.
8.2.2 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,
Fig. 47 : Création d’un DMP
126 / 254
8.2 TD1.1 – Création d’un DMP
[x] : Case à cocher, cochée.
[ ] : Case à cocher, décochée.
(x) : Bouton radio, coché.
( ) : Bouton radio, décoché.
8.2.2.1 Recueil du consentement du patient à la création de son DMP
EX_1.1-1010
Ⓔ
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_1.1-1020
Ⓡ
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_1.1-1030
Ⓡ
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.
127 / 254
Convention de représentation :
EX_1.1-1040
Ⓔ
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.
[ ] Le patient vous a désigné comme médecin traitant.
8.2.2.3 Recueil du consentement du patient à l’accès à son DMP en mode « bris de
glace » et en mode « centre de régulation »
EX_1.1-1050
Ⓔ
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
8.2.2.4 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.
128 / 254
8.2.2.2 Désignation comme Médecin Traitant par le patient
La transaction de création est décrite dans [CI-GESTPAT] § 3.3.3 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 « reasonCode/@code » doit être positionné à « CREA_RD » (voir § 8.8.2.5).
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 §
8.8.4 :
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).
Ⓔ
EX_1.1-1060
Ⓡ
REC_1.1-1070
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.
Le représentant légal tel que défini au § 8.8.5 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.
129 / 254
8.2.3 Transaction
Valable également pour la transaction de mise à jour des données administratives du DMP
d’un patient.
EX_1.X-1110
Ⓔ
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
d’un patient.
REC_1.X-1120
Ⓡ
Ⓔ
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 §
8.8.4 et § 8.8.5 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
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.
130 / 254
Pour les autorisations d’accès en mode « bris de glace » et « centre de régulation »
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
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).
Ⓡ
Ⓔ
Ⓔ
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 »
(patientPerson/birthTime/@value au format « AAAAMMJJ » - voir § 8.8.4).
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
§ 11.8.1 « Règle AM_DLU ».
EX_1.X-1170
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.
131 / 254
Ⓔ
EX_1.X-1140
Ⓔ
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 »
(contactParty/contactPerson/birthTime/@value 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
La « date de naissance de l’état civil du patient » (patientPerson/birthTime/@value) 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 §
11.8.3.
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.
132 / 254
EX_1.1-1080
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 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 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
controlActProcess/subject/registrationRequest/statusCode/@code
valeur est « completed ».
dont
la
133 / 254
Cette transaction permet de réactiver le DMP d’un patient qui a été fermé.
8.3.1 Prérequis
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é.
8.3.2 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,
Fig. 48 : Réactivation d’un DMP
134 / 254
8.3 TD1.2 - Réactivation d’un DMP
Ⓡ
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).
REC_1.2-1020
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.
8.3.2.1 Recueil du consentement du patient à la réactivation de son DMP
EX_1.2-1030
Ⓔ
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é.
Patient : Thierry DUPONT
Le patient consent à la réactivation de son DMP, réactivez le DMP
REC_1.2-1040
Ⓡ
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 ? ».
135 / 254
Ⓔ
EX_1.2-1010
Ⓡ
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.
8.3.2.2 Désignation comme Médecin Traitant par le patient
EX_1.2-1060
Ⓔ
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.
8.3.2.3 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.
136 / 254
REC_1.2-1050
La transaction de réactivation est décrite au § 3.3.7 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 « reasonCode/@code » doit être positionné à « REAC » (voir § 8.8.2.5).
Les données en entrée de la fonction sont :

l’INS-C du patient (patient/id) ;

le statut « actif » du patient (patient/@statusCode="active") ;

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 § 8.8.4 ;


consentement du patient à la réactivation de son DMP comme défini dans le § 8.8.4 ;
données d’identification du PS ayant réactivé le DMP (PS recueillant le consentement
tel que défini au § 8.8.3).
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
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 de la transaction, le message HL7 V3 « Patient Registry Revise
Request Rejected » (interaction PRPA_IN201316UV02) est renvoyé.
137 / 254
8.3.3 Transaction
à
jour
des
données
La transaction TD1.3 permet de gérer les informations administratives du patient.
8.4.1 Prérequis
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 ».
8.4.2 Cinématique
EX_1.3-1010
Ⓔ
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).
8.4.3 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.
8.4.3.1 Transaction
La transaction est décrite au § 3.3.4 du [CI-GESTPAT] « Consultation de données de gestion
de dossier ».
L’élément « reasonCode/@code » doit être positionné à « CNSLT_DATA » (voir § 8.8.2.5).
8.4.3.1.1 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 § 7.4.3.
Seuls les prérequis et les données renvoyées par le DMP diffèrent.
8.4.3.1.2 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 § 7.4.3.
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é).
138 / 254
8.4 TD1.3 – Mise
administratives


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 § 8.8.4 ; 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 § 8.8.5 « Représentant légal du patient »).
8.4.3.1.2.2 En cas d’erreur
En cas d’erreur de la transaction, un code et un message d’erreur sont renvoyés dans le
message.
8.4.4 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.
EX_1.3-1020
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.
139 / 254
8.4.3.1.2.1 En cas de succès
 accusé de réception du traitement « ok » (AA) ;
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 « email » et
« téléphone mobile » si le patient possède un compte internet patient. Le SI DMP retourne
une erreur « DMPInvalidData » dans ce cas.
8.4.4.1 Transaction
La transaction de modification des données administratives et de gestion est décrite au §
3.3.5 du [CI-GESTPAT] et utilise le message HL7 V3 « Patient Registry Revise Request »
(interaction PRPA_IN201314UV02) via un Web Service.
L’élément « reasonCode/@code » doit être positionné à « MODIF_DATA » (voir § 8.8.2.5).
8.4.4.1.1 Données en entrée


Ⓔ
les données administratives et de gestion sont définies au § 8.8.4 ;
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 § 8.8.5 « Représentant légal du patient »).
EX_1.3-1030
Le LPS doit suivre les règles de modification / effacement de données définies dans [CIGESTPAT] au § 3.3.5.2.1.4 « 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
Pour les dates de naissance
140 / 254
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.
réponse),
le
message
de
sortie
sera
englobé
dans
un
wrapper
<
PRPA_IN201314UV02_Response> (voir WSDL associé).
8.4.4.1.2.1 En cas de succès
8.4.4.1.2.2 En cas d’erreur
Voir annexe au § 11.4.
141 / 254
8.4.4.1.2 Données en sortie
Cette transaction permet de fermer un DMP.
8.5.1 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
8.5.2 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_1.4-1010
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_1.4-1020
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.
142 / 254
8.5 TD1.4 – Fermeture du DMP
Elle est décrite au § 3.3.6 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 « reasonCode/@code » doit être positionné à « FERM » (voir § 8.8.2.5).

l’INS du patient (patient/id) ;

le statut fermé du patient (patient/@statusCode="terminated") ;

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
Motif de la fermeture
[1..1]
codification du motif
code motif de fermeture
[1..1]
[1..1]
Remarques
reasonOf/detectedIssueEvent
Code
@code
Celui correspondant au motif
valeur fixe :
code de la nomenclature
[1..1]
@codeSystem
1.2.250.1.213.4.1.2.4
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).
réponse),
le
message
de
sortie
sera
englobé
dans
un
wrapper
143 / 254
8.5.3 Transaction
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.
8.6.1 Prérequis
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 ».
144 / 254
8.6 TD1.5 – Accès Internet du Patient
8.6.2 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
OUI
Le patient souhaite réinitialiser son compte
patient car il a perdu ses paramètres de
connexion
NON
NON
Plusieurs canaux OTP
OUI
OUI
TD1.5b - Gestion des canaux OTP (ajout)
Fin du
scénario
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
145 / 254
Ⓔ
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.
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).
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 ([email protected]) : [……………………………]
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.
Ⓔ
EX_1.5-1020
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.
Mode de réception du mot de passe à usage unique. [Modifier]
146 / 254
EX_1.5-1010
Ⓔ
EX_1.5-1030
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
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
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
http://www.dmp.gouv.fr/web/dmp/documents/param-formulaire-patient.
Le fichier XML contient les informations sur la dernière version du modèle :
Paramètre
Signification
version
Version du modèle du formulaire PDF
date_maj
Date de mise à jour du modèle du formulaire au format YYYYMMDDhhmmss
url
URL de téléchargement de la dernière version du modèle du formulaire
hash
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
147 / 254
Génération du « document des secrets du patient »
<?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="20130409093000" />
<parameter code="url" value="http://www.dmp.gouv.fr/web/dmp/documents/formulaire-acces-patient" />
<parameter code="hash" value="1419fcbeddf7246fd7568481a299b39c" />
</parameter-list>
</dmp-parameters>
Ⓔ
EX_1.5-1040
Ⓔ
EX_1.5-1050
Ⓡ
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.
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é.
REC_1.5-1060
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.
148 / 254
Exemple :
Ⓔ
EX_1.5-1070
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
Ⓔ
EX_1.5-1080
Ⓔ
EX_1.5-1090
Le LPS ne doit pas permettre à l’utilisateur de modifier les informations fournies dans le
formulaire contenant les paramètres de connexion du patient.
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.
149 / 254
Modalités de remplissage du formulaire avec les données du patient
8.6.3 Création du compte internet patient
Cette transaction TD1.5a permet de créer le compte internet patient.

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
Code du type de
canal OTP
Valeurs : SMS ou EMAIL
Données de création accès Patient : OTP principal
Type
Canal
Enum
A
-
50
[1..1]
[1..1]
Valeur du canal
OTP.
Représente soit
une adresse mél,
soit un numéro de
téléphone
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’email 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).
Les données en sortie de la fonction sont :

l’identifiant / mot de passe ;

l’accusé de réception du traitement.
150 / 254
Nom du champ
Type
Taille
Card
Description
status
A
50
[1..1]
context
A
text
[0..1]
Tableau 56 : TD1.5a – Accusé de réception de traitement
8.6.3.3 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
8.6.3.4 En cas d’erreur
Le champ statut de l’accusé de réception du traitement contient un code erreur et le champ
151 / 254
Fig. 55 : TD1.5a - Diagramme de classes des données en sortie
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.
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.
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
Code du type de canal
OTP
Valeurs : SMS ou EMAIL
OTP
Type
Enum
-
[1..1]
Si l’action est une
suppression, cette donnée
n’est pas vérifiée
Valeur du canal OTP :
Canal
A
50
[0..1]
- soit une adresse mél,
- soit un numéro de
téléphone
En fonction du type de canal,
le système vérifie si la valeur
du canal est au format
correspondant :
o
o
Code d’action à effectuer
Action
Enum
-
[1..1]
Uniquement des chiffres
pour un numéro de
téléphone
Un format d’email
standard
Valeurs :
o AJOUT
o MODIFICATION
o SUPPRESSION
Tableau 59 : TD1.5b – Données en entrée
152 / 254
8.6.4 Ajout 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.
Ⓡ
REC_1.5-1100
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.

l’accusé de réception du traitement.
Fig. 60 : TD1.5a - Diagramme de classes des données en sortie
Nom du champ
Type
Taille
Card
Description
status
A
50
[1..1]
context
A
text
[0..1]
Tableau 61 : TD1.5b – Accusé de réception de traitement
Voir annexe au § 11.4.
153 / 254
Pour un DMP, il ne peut y avoir qu’une seule valeur par type de canal OTP.
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 email 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.
8.6.6 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
154 / 254
8.6.5 Activation du compte internet par le patient
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
 l’identifiant / mot de passe ;
 l’accusé de réception du traitement.
Fig. 64 : TD1.5d - Diagramme de classes des données en sortie
Nom du champ
Type
Taille
Card
Description
status
A
50
[1..1]
context
A
text
[0..1]
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.
Tableau 66 : TD1.5d – Données en sortie
155 / 254
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 »).
8.7.1 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
8.7.2 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.
8.7.3 Transaction
Fig. 67 : Diagramme de classes en entrée
Note : L’INS du patient est passé dans le VIHF.
Nom du champ
Type
Card
Description
ACTIVE : PS autorisés
mode
Enum
[1..1]
INTERDITE : PS bloqués
TOUTE : PS autorisés et PS bloqués
156 / 254
8.7 TD1.6 - Liste des PS autorisés / bloqués sur
un DMP
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]
context
A
text
[0..1]
Tableau 70 : TD1.6 – Accusé de réception du traitement
157 / 254
Nom du champ
nationalId
Type
Taille
A
20
Card
[1..1]
Description
Identifiant National PS (ADELI, RPPS, …) ou
identifiant de la structure
OID de l’identifiant fourni afin de déterminer son type :
1.2.250.1.71.4.2.1 pour les PS
nationalIdType
A
20
[1..1]
1.2.250.1.71.4.2.2 pour les structures
Prénom (de personne physique)
firstName
A
60
[0..1]
Non renseigné pour une structure (STS)
lastName
A
80
[1..1]
Nom de personne physique (PS) ou morale (STS)
Date de la dernière action du PS sur le DMP du
patient
lastActionDate
A
14
[1..1]
Format YYYYMMDDhhmmss - la date est retournée
convertir dans sa date locale avant affichage à
l’utilisateur
ACTIVE : PS autorisé
mode
Enum
-
[1..1]
INTERDITE : PS bloqué
Date de début d’autorisation
startOfAuthorization
A
14
[1..1]
Format YYYYMMDDhhmmss - la date est retournée
convertir dans sa date locale avant affichage à
l’utilisateur
Code profession, et spécialité pour les médecins et
pharmaciens (séparé par « / » dans ce cas)
Codé dans la nomenclature authorSpecialty de l’ASIPSanté
Exemple pour médecin : G15_10/SM26
codeSpeciality
E
-
[0..1]
Libellé associé à codeSpeciality : « profession /
spécialité »
Exemple pour un médecin : Médecin - Qualifié en
Médecine Générale (SM)
libSpeciality
E
-
[0..1]
Rôle spécifique de l’acteur de santé :
MEDECIN_TRAITANT si le PS est Médecin traitant
specificRights
Enum
-
[0..n]
158 / 254
listOfAuthorizationByPatient (pour chaque autorisation retournée) :
8.8.1 Documentation et références
8.8.1.1 Documentation des Web Services
La liste des URL de Web Services par transaction et fonction, noms de méthodes, WSDL est
fournie en annexe au § 11.3 « WSDL des services ».
8.8.1.2 OID spécifiques aux messages de gestion du dossier patient
OID
Utilisation
1.2.250.1.213.4.1.2.2
codeSystem des codes d’erreur retournés par les messages
HL7 V3
1.2.250.1.213.4.1.2.3
codeSystem de la nomenclature
consentements du DMP
1.2.250.1.213.4.1.2.4
codeSystem de la nomenclature des motifs de fermeture d'un
DMP
1.2.250.1.213.4.1.2.5
nomenclatures d’institutions
1.2.250.1.213.4.1.2.6.1
codeSystem du concept d’autorisation d'un PS sur un DMP
1.2.250.1.213.4.1.2.6.2
codeSystem de la nomenclature des valeurs d'autorisation
d'un PS sur un DMP
1.2.250.1.213.4.1.2.6.3
codeSystem du concept de statut_médecin traitant d'un PS
sur un DMP
des
politiques
de
Tableau 72 : OID spécifiques aux messages de gestion administrative du dossier
8.8.2 Structure commune des messages HL7 V3
Ces fonctions de création et de gestion administrative utilisent majoritairement des
messages HL7 V3 du domaine « Patient Administration / Patient topic » de l’édition
normative 2009 HL7 V3, sur des Web Services SOAP. Les messages HL7 sont décrits en
détail dans le document [CI-GESTPAT].
Les transactions qui n’utilisent pas HL7 V3 utilisent des Web Services propriétaires au DMP.
Des exemples de message HL7 V3 de création sont fournis (voir annexe Erreur ! Source du
envoi introuvable.).
159 / 254
8.8 Spécifications techniques communes
Les messages HL7 v3 sont encapsulés dans le corps de la requête SOAP du Web Service
appelé.
Exemple d’encapsulation :
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
org:v3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
xmlns="urn:hl7-
<soap:Header>
...
</soap:Header>
<soap:Body>
<PRPA_IN201311UV02 ITSVersion="XML_1.0">
...
</PRPA_IN201311UV02>
</soap:Body>
</soap:Envelope>
Cette trame est fournie à titre d’exemple, des WSDL fournis en annexe décrivant ces Web
Services.
8.8.2.2 Notes de lecture
Dans les tableaux des chapitres suivant :

les lignes en italique correspondent à des éléments parents ne contenant pas de
valeur, mais des attributs et/ou des éléments fils ;

l’indentation de la première colonne correspond à la hiérarchisation des éléments ;

les éléments sont nommés en notation XPath par rapport à l’élément père ;

la cardinalité (colonne Card.) intègre la notion de champ obligatoire (card. [1..x]) ou
optionnel (card. [0..x]) ; un élément fils obligatoire ne doit être présent que si le père
est obligatoire.
Note : Les éléments suivants diffèrent d’un message à l’autre :

l’élément racine, qui correspond au nom de l’interaction HL7 v3 utilisée ;

les éléments fils de l’élément controlActProcess, qui correspond au corps de la
requête ; ces éléments sont spécifiques à chaque requête et ne sont pas décrits
ici (se reporter à la description de chaque message et aux exemples de messages
fournis).
160 / 254
8.8.2.1 Encapsulation dans les trames SOAP
Ⓔ
EX_1.X-1210
Les messages HL7 v3 envoyés en entrée des Web Services possèdent la structure
commune minimale décrite dans le tableau ci-après.
XPath HL7
Card.
Valeur / remarque
PRPA_XXXXXXXX
[1..1]
Le nom de l’élément prend le nom de l’interaction ; Exemple :
PRPA_IN201311UV02 pour le message de création
Identifiant unique du message HL7 (doit être mondialement unique)
OID racine des identifiants de messages HL7 produits par
l’instance du LPS
Identifiant du message produit par le LPS
date et à l’heure de la création du message au format
YYYYMMDDHHMMSS - la date doit être passée en UTC (universal
coordinated time) – le LPS doit traduire sa date locale en UTC
@ITSVersion
Id
@root
[1..1]
[1..1]
[1..1]
@extension
creationTime/@value
[1..1]
[1..1]
interactionId
@root
@extension
[1..1]
[1..1]
[1..1]
processingCode
@code
[1..1]
[1..1]
Valeur fixée à « 2.16.840.1.113883.1.6 »
Contient le nom de l’interaction HL7 V3 ; Exemple :
PRPA_IN201311UV02 pour le message de création
Les valeurs possibles pour cet élément sont : « P » (production –
valeur utilisée en fonctionnement nominal) « D » (test/validation) «
T » (formation)
Mode de traitement du message
Valeur fixée à « T »
processingModeCode
[1..1]
@code
[1..1]
acceptAckCode
[1..1]
@code
[1..1]
Valeur fixe ; pour les messages en entrée : « AL »
receiver
[1..1]
Destinataire du message : serveur DMP
@typeCode
[1..1]
Valeur fixée à « RCV »
device
[1..1]
@classCode
[1..1]
Valeur fixé à « DEV »
@determinerCode
[1..1]
Valeur fixé à « INSTANCE»
id/@root
[1..1]
OID du serveur DMP : fixé à « 1.2.250.1.213.4.1.1.1 »
softwareName
[1..1]
Fixé à « DMP »
sender
[1..1]
LPS émetteur du message
@typeCode
[1..1]
Valeur fixée à « SND »
device
[1..1]
@classCode
[1..1]
Valeur fixé à « DEV »
@determinerCode
[1..1]
Valeur fixé à « INSTANCE»
id/@root
[1..1]
OID de l’instance du LPS à renseigner par le LPS
softwareName
[1..1]
Nom du LPS (libre)
controlActProcess[…]
[1..1]
corps de la requête HL7 (voir le détail dans chaque message)
@classCode
[1..1]
@moodCode
[1..1]
Tableau 73 : Structure commune des messages HL7 en entrée
161 / 254
8.8.2.3 Messages envoyés en entrée des Web Services HL7 V3
Les messages HL7 v3 retournés par le DMP en sortie des Web Services possèdent la
structure commune minimale décrite dans le tableau suivant :
XPath HL7
PRPA_XXXXXXXX
@ITSVersion
Id
@root
@extension
creationTime/@value
interactionId
@root
@extension
processingCode
@code
processingModeCode
@code
acceptAckCode
@code
receiver
@typeCode
device
@classCode
@determinerCode
id/@root
softwareName
sender
@typeCode
device
@classCode
@determinerCode
id/@root
softwareName
Card. Valeur / remarque
Le nom de l’élément prend le nom de l’interaction ; Exemple :
[1..1] PRPA_IN201312UV02 pour le message d’acceptation de création
[1..1] Fixé à « XML_1.0 »
[1..1] Identifiant unique du message HL7 (doit être mondialement unique)
OID racine des identifiants de messages HL7 produits le DMP
[1..1] fixé à « 1.2.250.1.213.4.1.1.1.1 »
[1..1] Identifiant du message produit par le DMP
date et à l’heure de la création du message au format
[1..1] YYYYMMDDHHMMSS (UTC)
[1..1]
[1..1] Valeur fixée à « 2.16.840.1.113883.1.6 »
Contient le nom de l’interaction HL7 V3 ; Exemple :
[1..1] PRPA_IN201312UV02 pour le message d’acceptation de création
[1..1]
Les valeurs possibles pour cet élément sont : « P » (production –
valeur utilisée en fonctionnement nominal) « D » (test/validation) « T »
[1..1] (formation)
[1..1] Mode de traitement du message
[1..1] Valeur fixée à « T »
[1..1]
[1..1] Valeur fixe ; pour les messages en sortie : « NE »
Destinataire du message : LPS ayant fait la requête en entrée
[1..1] correspondante
[1..1] Valeur fixée à « RCV »
[1..1]
[1..1] Valeur fixé à « DEV »
[1..1] Valeur fixé à « INSTANCE»
OID de l’instance du LPS tel qu’il est présent dans le message en
[1..1] entrée correspondant
Nom du LPS tel qu’il est présent dans le message en entrée
[1..1] correspondant
[1..1] émetteur du message : DMP
[1..1] Valeur fixée à « SND »
[1..1]
[1..1] Valeur fixé à « DEV »
[1..1] Valeur fixé à « INSTANCE»
[1..1] OID du serveur DMP : fixé à « 1.2.250.1.213.4.1.1.1 »
[1..1] Fixé à « DMP »
162 / 254
8.8.2.4 Messages retournés en sortie des Web Services HL7 V3
[1..1]
Accusé de réception du message de réponse
type d’accusé de réception :

«AA» - « Acknowledgement Accept ». L'application destinatrice
a traité correctement le message.

@typeCode
targetMessage
[1..1]
[1..1]
«AE» - « Acknowledgement Error ». Une erreur s'est produite
lors du traitement du message.
Identifiant du message HL7 d’origine (message en entrée
correspondant).
Dans le cas où une erreur s’est produite avant l’analyse de la requête
empêchant ainsi de récupérer l’information id d'origine, le contenu de
l’élément extension aura la valeur « ID_MESSAGE_INCONNU » (root
Id
[1..1] sera vide)
@root
[1..1] OID fourni par le LPS dans le message d’origine
@extension
[1..1] Identifiant fourni par le LPS dans le message d’origine
Détail de l’erreur
Cardinalité à [1..1] en cas d’erreur (si
acknowledgementDetail
[0..1] acknowledgement/]@typeCode="AE")
code de l’erreur renvoyé
code
[0..1] Cardinalité à [1..1] en cas d’erreur
la valeur du code d’erreur
@code
le système de codage ; pour le DMP : fixé à 1.2.250.1.213.4.1.2.2
@codeSystem
message texte associé au code d’erreur
text
corps de la requête HL7 de réponse (voir le détail dans chaque
controlActProcess[…]
[1..1] message)
@classCode
[1..1] Valeur fixée à « CACT »
@moodCode
[1..1] Valeur fixée à « EVN »
Tableau 74 : Structure commune des messages HL7 en sortie
163 / 254
acknowledgement
Certaines transactions utilisant le même point d’entrée SOAP et le même message
(exemple : fermeture, réactivation, modification de données administratives…), il est
nécessaire de distinguer ces messages ; l’élément controlActProcess/reasonCode est donc
obligatoire sur l’ensemble des messages HL7 V3 de gestion administrative du dossier.
Cet élément est constitué des attributs suivants :



reasonCode@code : code spécifique à la transaction (les codes sont définis dans
[CI-ANX-HL7]) ;
reasonCode@codeSystem :
oid
de
la
nomenclature ;
valeur
fixe
=
1.2.250.1.213.1.1.4.11 ;
reasonCode@displayName : libellé associé au code.
Exemple :
<PRPA_IN201307UV02 …>
<controlActProcess classCode="CACT" moodCode="EVN">
<reasonCode
code="TEST_EXST"
displayName="Test d'existence de dossier"/>
codeSystem="1.2.250.1.213.1.1.4.11"
…
</PRPA_IN201307UV02>
8.8.2.6 Encodage de caractères
Ⓔ
EX_1.X-1220
Les messages doivent être encodés en UTF-8.
164 / 254
8.8.2.5 Elément « reasonCode »
8.8.3 PS (ou professionnel non PS) recueillant le consentement / auteur de l’action sur le dossier
Le PS (ou professionnel non PS) recueillant le consentement du patient (ou auteur de l’action sur le dossier) doit être fourni (lorsque
demandé) dans l’élément « registrationRequest/author/assignedEntity »
Nom du champ
Données d’identification du PS
identifiant
OID de l'id
valeur de l'id
rôle structurel (profession + spécialité)
OID de l'id
valeur de l'id
Cardinalité
Taille
Max
XPath HL7
[1..1]
[1..1]
[1..1]
author/assignedEntity
Id
@root
[1..1]
@extension
[0..1]
[1..1]
Remarques / contraintes
Valeur fixe 1.2.250.1.71.4.2.1
Identifiant du PS ; voir chapitre construction des identifiants des
PS (§ 5.1.4)
code
@code
[1..1]
@codeSystem
nom
[1..1]
80
assignedPerson/name/family
prénom
Structure liée au PS
identifiant de la structure
OID de l'id
[1..1]
[1..1]
[1..1]
[1..1]
60
assignedPerson/name/given
representedOrganisation
id
@root
valeur de l'id
nom de la structure
[1..1]
[1..1]
@extension
name
Code issu de la nomenclature authorSpecialty de l’ASIP-Santé
OID de la nomenclature utilisée (1.2.250.1.213.1.1.4.5 pour un
PS ou 1.2.250.1.213.1.1.4.6 pour un non PS)
Caractères accentués autorisés.
Pas de caractères spéciaux exceptés : [-’ ] (tiret apostrophe
espace)
Pas de caractères spéciaux exceptés : [-’ ] (tiret apostrophe
espace)
Valeur fixe : 1.2.250.1.71.4.2.2
Identifiant de la structure ; voir chapitre sur la construction des
identifiants des structures (§ 5.1.5)
165 / 254
istrative du DMP
Tableau 75 : Données du PS recueillant le consentement
8.8.4 Données patient
Les données administratives et de gestion du patient sont fournies dans un élément « patient ».
La colonne « modif » indique les données modifiables par les LPS.
patient
Identifiant patient : INS-C / INS-A
OID d'affectation de l'INS (C ou A)
valeur de l'INS
statut du DMP
état-civil du patient
Civilité
Card.
[1..1]
Taille
Max
[1..N] (1)
ou
[1..2] (2)
ou
[1..1] (3)
[1..1]
[1..1]
XPath HL7
contrainte
modif
patient
(1) en retour du test d’existence : 0 à
N INS-C et 0 à 1 INS-A peuvent
être retournés
(2) en création : au moins l’INS-C, ou
les deux (un INS-C et un INS-A)
(3) autres transactions : un seul
identifiant (C ou A)
id
22
[1..1]
OID de l’INS-C : 1.2.250.1.213.1.4.2
OID de l’INS-A : 1.2.250.1.213.1.4.1
@root
@extension
Fixé à 'active' pour la création et la
réactivation du DMP
Fixé à ‘terminated’ pour la fermeture du
DMP
statusCode/@code
patientPerson
name/prefix
[0..1]
5
Nom de naissance (légal)
[0..1]
80
name/family[@qualifier = 'BR']
Nom d’usage
[1..1]
80
name/family[@qualifier = 'SP']
prénom
[1..1]
60
name/given
Sexe (M,F,U)
[1..1]
1
administrativeGenderCode/@code
166 / 254
Valeur parmi : M, Mme, Mlle
Nom de naissance (nom de famille)
Doit être fourni s’il est présent dans la carte
Vitale (et que celle-ci est utilisée).
Pas de caractères spéciaux exceptés : [-’ ]
(tiret apostrophe espace)
Nom d’usage (ou « nom usuel »). Par
exemple : nom marital
Déductible du premier chiffre du NIR
bénéficiaire lu en carte
Valeur parmi M (Masculin), F (Féminin), U
istrative du DMP
Nom du champ
X
X
X
X
X
X
(Non connu)
[1..1]
[0..1]
[0..1]
[0..1]
[0..1]
[0..1]
8
38
10
10
64
birthTime/@value
birthPlace/addr/country
telecom[@use='MC']/@value
telecom[@use='HP']/@value
telecom/@value
addr
ligne d'adresse 1
[0..1]
38
streetAddressLine
complément d'adresse
[0..1]
38
additionalLocator
code postal
[0..1]
10
postalCode
commune
[0..1]
38
pays
[0..1]
38
Représentant légal
[0..1] *
Données de la carte Vitale
code du concept "carte Vitale"
OID du support "carte Vitale"
valeur fixe "carte Vitale"
[1..1] *
[1..1]
[1..1]
[1..1]
champ nom usuel bénéficiaire lu sur la
carte Vitale
[1..1]
champ nom patronymique lu sur la carte
Vitale (nom de famille bénéficiaire)
[0..1]
27
X
X
X
X
X
Valeur précédée de "tel:"
Valeur précédée de "mailto:"
Pas de caractères spéciaux exceptés : [-’,/ ]
(tiret apostrophe virgule slash espace)
X
X
X
city
country
personalRelationship […]
(détail du contenu dans le tableau du
§ 8.8.5)
* le représentant légal ne peut être
passé qu’en création ou modification de
données administratives
* données présentes uniquement pour
la création du DMP
contactParty
code
@code
@codeSystem
35
Format AAAAMMJJ
CARTE_SESAM_VITALE
1.2.250.1.213.4.1.2.5
contactPerson/name/family[@qualifier
= 'SP']
contactPerson/name/family[@qualifier
= 'BR']
167 / 254
La cardinalité de ce champ est positionnée
à « facultatif » mais le champ doit être
impérativement renseigné si la valeur
correspondante figure effectivement dans
les données de la puce de la carte Vitale (le
champ ne doit être fourni que si la donnée
est présente dans la carte Vitale)
istrative du DMP
Date de naissance
Pays de naissance
Téléphone portable
Téléphone fixe domicile
Email
adresse du patient
X
X
X
date de naissance lue sur la carte Vitale
recueil du consentement patient à
l'ouverture de son DMP
code du concept "consentement patient à
l'ouverture DMP"
code du concept
OID du système de codification du
concept
date du recueil du consentement patient
valeur du consentement patient
type de la valeur (fixé à "BL")
valeur du consentement ("true" si le
patient a donné son consentement)
recueil du consentement patient à la
réactivation de son DMP
code du concept "consentement patient à
l'ouverture DMP"
code du concept
concept
date du recueil du consentement patient
valeur du consentement patient
valeur du consentement ("true" si le
patient a donné son consentement)
[1..1]
[1..1]
35
6
[1..1] *
[1..1]
[1..1]
contactPerson/name/given
contactPerson/birthTime/@value
Format AAMMJJ (même format que pour le
calcul de l’INS-C, sans modification des
éventuels jours ou mois « lunaires »)
subjectOf/administrativeObservation
* données présentes uniquement pour la
création du DMP
code
@code
[1..1]
@codeSystem
[1..1]
[1..1]
[1..1]
value
@xsi:type
[1..1]
[1..1] *
[1..1]
[1..1]
Fixe : BL
Fixé à "true" si le patient a donné son
consentement ; une valeur "false" ne devrait
pas arriver, car le message de création ne
doit pas être envoyé si le patient ne donne
pas son consentement
code
@code
@codeSystem
[1..1]
[1..1]
[1..1]
value
@xsi:type
1.2.250.1.213.4.1.2.3
Format AAAAMMJJ - La date doit être
passée en UTC (universal coordinated time)
– le LPS doit traduire sa date locale en UTC
@value
[1..1]
[1..1]
CONSENTEMENT_OUVERTURE_DMP
* données présentes uniquement pour la
réactivation du DMP
CONSENTEMENT_REACTIVATION_DMP
1.2.250.1.213.4.1.2.3
Format AAAAMMJJ - La date doit être
passée en UTC (universal coordinated time)
– le LPS doit traduire sa date locale en UTC
Fixe : BL
Fixé à "true" si le patient a donné son
consentement
@value
168 / 254
istrative du DMP
champ prénom lu sur la carte Vitale
opposition du patient à l’utilisation du DMP en
mode « bris de glace »
code du concept "opposition au mode
bris de glace"
code du concept
concept
valeur
valeur de l'opposition
opposition du patient à l’utilisation du DMP en
mode « centre de régulation »
[1..1]
[1..1]
[1..1]
code
@code
[1..1]
[1..1]
[1..1]
[1..1]
@codeSystem
value
@xsi:type
@value
[1..1]
OPPOSITION_BRIS_DE_GLACE
1.2.250.1.213.4.1.2.3
Fixe : BL
true si opposition, false sinon
X
code du concept "opposition du patient au
mode centre de régulation"
code du concept
[1..1]
[1..1]
code
@code
concept
valeur
valeur de l'opposition
[1..1]
[1..1]
[1..1]
[1..1]
@codeSystem
value
@xsi:type
@value
OPPOSITION_ACCES_URGENCE
1.2.250.1.213.4.1.2.3
Fixe : BL
true si opposition, false sinon
X
169 / 254
istrative du DMP
Tableau 76 : Données administratives et de gestion du patient
8.8.5 Représentant légal du patient
Le représentant légal du patient peut être fourni :


au LPS, par la fonction de récupération des données administratives ;
par le LPS dans les fonctions de création de DMP ou de modification des données administratives ;
S’il est fourni, le représentant légal est positionné dans l’élément « patient ».
données du représentant légal
qualité du représentant légal
Card.
Taille
Max
[1..1]
[1..1]
personalRelationship
code
[1..1]
[1..1]
adresse du représentant légal
XPath HL7
@code
@codeSystem
[0..1]
[0..1]
38
streetAddressLine
complément d'adresse
code postal
[0..1]
[0..1]
38
10
additionalLocator
postalCode
commune
(père, mère, tuteur…)
Code à prendre dans le jeu de valeur des qualités du représentant légal
du CI-SIS
OID de la nomenclature utilisée, associé au code
addr
ligne d'adresse 1
[0..1]
38
10
10
64
civilité
[0..1]
[0..1]
[0..1]
[1..1]
[1..1]
[0..1]
nom
[1..1]
80
prénom
[1..1]
60
téléphone portable
téléphone fixe
email
conteneur HL7 pour l’identité
Remarques / contraintes
city
telecom[@use='MC']/@value
telecom[@use='HP']/@value
telecom/@value
relationshipHolder1
name
prefix
Pas de caractères spéciaux exceptés : [-’,/ ] (tiret apostrophe virgule slash
espace)
espace)
espace)
Valeur précédée de "mailto:"
Pas de caractères spéciaux exceptés : [-’ ] (tiret apostrophe espace)
given
Pas de caractères spéciaux exceptés : [-’ ] (tiret apostrophe espace)
Tableau 77 : Représentant légal du patient
family
170 / 254
istrative du DMP
Nom du champ
Le jeu de valeur à utiliser pour coder la qualité du représentant légal est défini dans le fichier « CI-SIS_jdv_qualiteRepresentantLegal.xml »
publié dans le CI-SIS.
Cette liste de codes est susceptible d’évoluer.
Il est recommandé que le LPS soit en capacité d’intégrer une valeur en provenance du DMP qui n’est pas encore connue du LPS et
l’ajouter à son référentiel de valeurs.
171 / 254
istrative du DMP
Ⓡ
REC_1.X-1230
9 Alimentation du DMP
La transaction TD2.1 permet au PS (hors authentification par CPE) :

d’ajouter un ou plusieurs documents de santé dans le DMP du patient, ces
documents pouvant les cas échéant être déposés masqués aux PS ou non visibles
du patient ;

de mettre à jour un document avec une nouvelle version (remplacement de
document). La cinématique spécifique à appliquer pour remplacer un document par
une nouvelle version est décrite au § 9.2.
La transaction TD2.2 permet la même fonctionnalité, mais par une CPE (directement ou
indirectement nominative), pour les secrétaires médicales du secteur libéral. Le SI DMP
contrôle que le secteur d’activité de la structure à laquelle est rattachée la CPE est bien dans
le « secteur libéral » ; A ce jour seuls les secteurs d’activité suivants sont autorisés à utilisés
la TD2.2 :







SA07 Cabinet individuel
SA08 Cabinet de groupe
SA09 Exercice en Société
SA25 Laboratoire de Biologie Médicale
SA29 Laboratoire d'Analyses et de Biologie Médicale
SA40 Secteur privé PH temps plein
SA52 Maison de santé, Pôle de santé
9.1.1 Prérequis
1. le PS est authentifié (TD0.1) ;
2. Dans le cas de la TD2.2 : le secteur d’activité de la structure à laquelle est rattachée
la CPE est autorisé à alimenter les DMP.
3. le PS est autorisé à accéder au DMP du patient.
9.1.2 Cinématique générale
1. Le PS constitue le document dans le LPS (corps et métadonnées);
2. Le LPS construit le document XDS/CDA ;
3. Le LPS réalise la signature du document (non obligatoire) ;
4. Le LPS constitue un lot de soumission XDS et réalise la signature XAdES du lot ;
5. Le LPS envoie la requête au DMP.
172 / 254
9.1 TD2.1/TD2.2 - Alimentation du DMP en
documents
9.1.3 Saisie du document dans le LPS
L’objectif de ce paragraphe n’est pas de décrire la solution à mettre en œuvre dans le LPS
pour récupérer les données ni d’édicter des règles ergonomiques qui sont laissées à
l’appréciation de l’éditeur. Ce paragraphe a par contre pour objectif de préciser certaines
exigences ou recommandations portant sur des données particulières, ces exigences ou
recommandations ayant ensuite un impact direct dans l’alimentation du DMP.
173 / 254
9.1.3.1 Types de documents
Les documents d’expression personnelle du patient ne peuvent pas être créés via l’interface
LPS (classCode = 90, et les typeCode associés).
9.1.3.2 Titre du document
Pour les documents, la taille maximale du champ "titre" est celle définie dans la norme
XDS.b (voir [IHE-TF3], dans "Table 4.1-5 Document Metadata Attribute Definition"), à savoir
128 caractères : "Max length, 128 bytes, UTF-8".
Ⓔ
EX_2.1-1020
Ⓔ
EX_2.1-1030
Ⓔ
EX_2.1-1040
Le titre du document doit être compréhensible et ne peut être arbitrairement tronqué à la
limite de taille (128 caractères).
Le titre d’un document doit en refléter le contenu médical (le titre est saisissable par le PS).
Le titre d’un document doit être modifiable.
9.1.3.3 Documents masqués aux PS / Documents non visibles du patient
Ⓔ
EX_2.1-1050
A chaque l’alimentation du DMP à partir d’un LPS, l’acteur doit indiquer, pour chaque
document :


Si le document doit être masqué aux PS ou pas
Si le document doit être visible du patient ou pas
174 / 254
Ⓔ
EX_2.1-1010
REC_2.1-1060
Exemple de mise-en-œuvre pour la confidentialité du document :
Pour le patient
Ⓡ
( ) Document non visible par le patient : vous souhaitez que ce document ne soit
pas visible par le patient car il nécessite une information préalable par un
professionnel de santé.
Pour les professionnels de santé
(x) Document visible par les professionnels de santé autorisés à accéder aux
documents du DMP du patient
( ) Document masqué aux professionnels de santé : document visible uniquement
par son auteur, les médecins traitants et le patient.
Le PS peut rendre le document visible du patient (voir TD3.3), suite à la consultation
d’annonce par exemple. Cette action est ensuite irréversible, c'est-à-dire qu’un document
visible du patient ne peut pas être rendu non visible du patient.
Dans le DMP, il n’est pas possible qu’un document soit à la fois non visible du patient et
masqué aux PS (sauf pour le document technique de signature du lot de soumission, comme
défini dans [CI-PARTAGE] au § 4.2.2).
Lorsque le document n’est pas visible du patient, il est visible pour les PS autorisés sur le
DMP.
Cette caractéristique est portée par la métadonnée XDS « confidentialityCode » du
document (cf. [CI-PARTAGE] au § 3.4.12).
175 / 254
Confidentialité du document
9.1.3.3.1 Documents masqués aux PS
Le patient a la possibilité de masquer des documents aux PS. Il peut demander au PS de le
faire pour lui. Un document masqué reste néanmoins visible à son auteur et aux médecins
traitants du patient et bien entendu au patient lui-même (ce filtrage est fait par le DMP).
Tout PS (médecin ou non) peut masquer un document.


le patient peut retirer le masquage d’un document aux PS ;
le démasquage peut être réalisé par les MT pour tous les documents et par les autres
PS pour les documents dont ils sont l'auteur.
Note : Par défaut (paramétrage DMP), les documents masqués aux PS sont visibles en
mode urgence. Le patient peut néanmoins, via son accès internet DMP uniquement, modifier
les modalités d’accès des PS aux documents masqués en mode urgence.
9.1.3.3.2 Documents non visibles du patient
Un PS a la possibilité de publier un document « non visible du patient » dans le DMP. Cela
permet de gérer les situations pour lesquelles une consultation d’annonce est nécessaire
avant de rendre ce document visible du patient.
9.1.4 Génération du document CDA et des métadonnées XDS
Données obligatoires et facultatives :
Les éditeurs doivent s’assurer que le logiciel gère l’ensemble des données obligatoires à
fournir dans les transactions, les documents CDA et les métadonnées XDS.
Il faut dans un premier temps bien distinguer les données à fournir :
•
dans un document CDA,
•
dans les métadonnées XDS du document,
•
dans les métadonnées XDS du lot de soumission.
Dans un document CDA, l’information est portée par la cardinalité indiquée pour
chaque donnée dans les documents [CI-STRU-ENTETE] et les volets des documents
structurés de la couche contenu publiés au CI-SIS :
•
Lorsque la cardinalité est du type [0..*], la donnée n’est pas obligatoire et peut ne pas
être fournie.
•
Lorsque la cardinalité est du type [1..*], la donnée est obligatoire et doit être fournie.
•
Lorsque la cardinalité est définie précisément comme dans [2..2], le nombre
d’occurrences (ici 2) doit être respecté.
Dans certains cas, lorsque la donnée n’est pas connue, le LPS doit permettre d’indiquer, au
moyen d’un attribut « nullFlavor », la raison de l’absence de l’information.
Dans d’autres cas, l’utilisation de « nullFlavor » est interdite.
176 / 254
Le masquage est réversible :
•
Lorsque la cardinalité est du type [0..*] et le code d’usage = ‘O’ (optionnel), la donnée
n’est pas obligatoire.
•
Lorsque la cardinalité est du type [0..*] et le code d’usage = ‘R2’ (requis si connu), la
donnée n’est pas obligatoire, mais lorsqu’elle est connue, elle doit être fournie.
•
Lorsque la cardinalité est du type [1..*], le code d’usage sera forcément = ‘R’
(Requis). Dans ce cas, la donnée est obligatoire et doit être fournie.
•
Lorsque la cardinalité est définie précisément comme dans [1..1], le nombre
d’occurrences (ici 1) doit être respecté.
Quelle différence y a-t-il entre les données « requises » et « requises si connues » ?
Cette différence n’existe que pour les métadonnées XDS ; dans le cas des données d’un
document CDA, cette subtilité n’existe pas et il faut se baser sur les cardinalités uniquement,
avec la possibilité éventuelle d’utiliser un nullFlavor.
•
•
Donnée requise (code d’usage R) : Le LPS doit obligatoirement gérer cette donnée
et elle doit être obligatoirement renseignée et transmise dans les métadonnées XDS.
Donnée requise si connue (code d’usage R2) : Le LPS doit aussi obligatoirement
gérer cette donnée et permettre à l’utilisateur de la saisir (ou au système de la
renseigner) dès lors qu’il la connait afin qu’elle puisse être transmise dans les
métadonnées XDS. L’utilisateur (ou le système) doit pouvoir déclarer qu’il ne connait
pas l’information via son interface de création du document (i.e. IHM pour un
utilisateur). Le cas échéant, l’élément d’entête CDA correspondant n’est pas intégré
dans le CDA et la métadonnée XDS correspondante n’est pas présente parmi les
métadonnées XDS du document. »
177 / 254
Pour les métadonnées XDS, il faut combiner cardinalités et code d’usage indiqués pour
chaque donnée dans le document [CI-PARTAGE] (en particulier le récapitulatif au § 3.7.2) :
En pratique, comment le LPS doit-il gérer les données R2 (du CI-SIS) ?
Structure de soins
Cette
donnée
étant
obligatoirement renseignée dans
le VIHF, il est fortement conseillé
de la renseigner dans le
document CDA et dans les
métadonnées XDS.
Rôle fonctionnel du PS
Cette donnée n’est pas dans le
VIHF,
optionnelle
dans
le
document CDA et [R2] dans les
métadonnées XDS.
Donnée CDA
Métadonnée XDS
[0..1]
[R2]
Donnée du VIHF
author/assignedAutho
r/representedOrganiz
ation
authorInstitution
author/functionCode
@displayName
authorRole
[Cette donnée n’existe pas
dans le VIHF]
r/code@code
authorSpeciality
Urn :oasis :names :tc :xac
ml :2.0 :subject:role
[Obligatoire]
L’éditeur est libre de gérer ou pas
cette donnée mais lorsqu’elle est
renseignée dans le CDA, alors il
faut mettre la même valeur dans
la métadonnée XDS.
Profession et Spécialité du PS
Dans le VIHF, la profession est
obligatoire et la spécialité est
conditionnelle (elle est obligatoire
pour
les
médecins
et
pharmaciens). Il est fortement
conseillé de les renseigner dans
le document CDA et dans les
métadonnées XDS.
Date de fin de l’acte
La date de fin de l’acte est
généralement
« considérée »
comme obligatoire. Il est donc
fortement
conseillé
de
la
renseigner. Dans certains cas,
elle est égale à la date de début
de l’acte.
[Profession : Obligatoire]
r/code@displayName
[Spécialité : Conditionnelle]
r/code@codeSystem
documentationOf/serv
iceEvent/effectiveTim
e/high@value
serviceStopTime
[Cette donnée n’existe pas
dans le VIHF]
Tableau 78 : Données R2 des documents CDA
178 / 254
Donnée
9.1.4.1 Les documents médicaux au format CDA R2
9.1.4.1.1 Principes généraux
Ⓔ
Ces documents médicaux doivent respecter les spécifications décrites dans les volets de la
couche « contenu » du CI-SIS. Chaque volet de contenu est basé sur un socle commun se
conformant au standard HL7 Clinical Document Architecture, Release 2.0 (CDA R2) publiés
dans l’Edition Normative HL7 v3 de mai 2005.
Le document [CI-STRU-ENTETE] définit la structuration minimale des documents à respecter
que ce soit pour les documents dit « non structurés » (document PDF, RTF…) ou pour les
documents « structurés » (CDA R2 de niveau 3).
Enfin, un document médical correspondant à un modèle structuré spécifié au CI-SIS doit être
conforme au volet de ce document publié dans le CI-SIS.
Les jeux de valeurs embarqués dans le standard CDA, les jeux de valeurs définis par le volet
« Structuration minimale des documents médicaux » et les jeux de valeurs définis par le volet
spécifique au document structuré doivent être utilisés dans le document.
La conformité des documents CDA R2 peut se contrôler à partir :


du schéma xml « CDA.xsd » pour la conformité au standard CDA. Tout écart détecté
se traduit par la déclaration de non-validité du document.
du schématron correspondant au volet du document mis en œuvre pour les
documents médicaux structurés spécifiés au CI-SIS ou à défaut du schématron «
CISIS_StructurationCommuneCDAr2 » pour les autres documents. Cette analyse
produit un rapport listant les éventuelles non-conformités détectées ; la présence
d’une seule non-conformité se traduit par la déclaration de non-conformité du
document.
Les jeux de valeurs sont exploités par la vérification de conformité, toute valeur étrangère
détectée se traduit par une non-conformité.
Ⓡ
REC_2.1-1080
Il est recommandé de prendre en compte dès la conception du LPS les tests à effectuer avec
les schématrons. Les schématrons sont disponibles sur le site de l'ASIP Santé :
http://esante.gouv.fr/services/referentiels/interoperabilite/cadre-d-interoperabilite-des-systemes-dinformation-de-sante- (télécharger le zip « Répertoire "Test contenus CDA" au JJ/MM/AAAA ».
EX_2.1-1090
Ⓔ
Les familles de produits contenant des LPS de type EAI doivent nécessairement réaliser des
contrôles sur les documents CDA avant envoi au DMP. Ces contrôles doivent porter sur la
conformité au schéma XML (CDA.xsd) et la conformité au volet « Structuration minimale des
documents médicaux » et aux volets des documents structurés du CI-SIS (contrôle par les
schématrons spécifiques aux volets lorsqu’ils existent, sinon par le schématron
« CISIS_StructurationCommuneCDAR2 »).
179 / 254
EX_2.1-1070
9.1.4.1.2 Niveau de confidentialité du document
Ⓡ
Ni le standard CDA ni le Cadre d'Interopérabilité des SIS ne précisent la manière dont
chaque valeur possible du confidentialityCode (Normal, Restreint, Très Restreint) doit être
interprétée. Un document ayant un niveau renforcé de confidentialité (restreint ou très
restreint), devrait être remis en mains propres, ou envoyé sous pli scellé ou par message
direct à son destinataire. Il ne devrait pas être mis en partage. En l’état, il est recommandé
de renseigner le confidentialityCode avec la valeur "N" (Normal).
9.1.4.1.3 Formats des champs date/heure
EX_2.1-1110
Ⓔ
Les champs de type date/heure sont codés dans une zone de temps différente entre les
métadonnées XDS et le CDA R2. Les champs date/heure XDS doivent être codés en UTC
(universal coordinated time) et ceux du CDA correspondant en date/heure locale du
producteur du document incluant le décalage par rapport à UTC (GMT).
Le LPS devra donc transformer les dates/heure du CDA de la date/heure locale en
date/heure UTC (ou inversement, de la date/heure UTC en date/heure locale dans le cas où
les dates sont transformées des métadonnées XDS vers le CDA). Par exemple l’heure locale
en France métropolitaine est égale à UTC + 0100 (1 heure) en hiver et à UTC +0200 (2
heures) en été.
9.1.4.1.4 CDA auto-présentables
Le CI-SIS 1.3 introduit la notion de CDA dit « auto-présentable ». Ce format est décrit dans
[CI-STRU-ENTETE-1.3].
L’usage de CDA auto-présentables est optionnel mais est néanmoins soumis aux exigences
décrites ci-après lorsqu’il est implémenté.
Impact sur les métadonnées XDS
L’usage de CDA auto-présentables en alimentation du DMP impose les spécificités
suivantes dans les métadonnées XDS du document, décrites dans [CI-PARTAGE-1.3] :
- le champ mimeType doit prendre la valeur « application/xslt+xml »
- s’il est signé électroniquement, le calcul des champs size et hash est spécifique et précisé
dans [CI-PARTAGE-1.3].
180 / 254
REC_2.1-1100
Ⓔ
Pour des raisons de sécurité, un LPS alimentant le DMP avec des CDA auto-présentables ne
doit pas inclure de script (balise HTML <script>) ni de lien vers des ressources externes
(styles css externes, import de scripts, iframes, fenêtres surgissantes, liens, images, vidéos,
etc.) dans la feuille de style couplée au document. Seuls sont autorisées des ressources
encapsulées dans la feuille de style (liens internes, styles css inclus dans le document,
images encapsulées,…). La feuille de style couplée au document doit être autonome en
termes de visualisation à l'utilisateur.
EX_2.1-1116
Ⓔ
Pour des raisons de sécurité, un LPS alimentant le DMP avec des documents CDA autoprésentables ne doit pas permettre à tous ses utilisateurs de modifier la feuille de style XSL
des documents qu'il produit. Si le LPS permet de modifier des feuilles de style "modèles"
utilisées par le LPS pour constituer les CDA auto-présentables envoyés au DMP, seuls des
acteurs autorisés (de type « administrateurs ») doivent pouvoir le faire. Le LPS doit mettre en
œuvre des moyens pour protéger et confiner en son sein les feuilles de style des documents
CDA auto-présentables qu’il produit.
181 / 254
EX_2.1-1115
9.1.4.2 Les métadonnées XDS
Le LPS doit être conforme à l’ensemble des spécifications décrites dans ce paragraphe.
9.1.4.2.1 Principes généraux
La mise en partage de ces documents nécessite la gestion de métadonnées (documents et
lots de soumission) via le profil IHE XDS.b.
Certaines métadonnées sont déductibles :



du document CDA (profession, spécialité…) : le document [CI-ANX-CDA] définit la
correspondance entre le CDA R2 et les métadonnées XDS,
de données éventuellement déjà stockées dans le LPS (titre du document, date de
l’acte médical documenté, type du document…) ou
du support d’authentification (carte CPS, certificat logiciel pour personne morale).
Le document [CI-PARTAGE] donne une indication sur l’origine possible de chaque
métadonnée.
Ⓔ
EX_2.1-1125
Le LPS doit assurer la cohérence entre les métadonnées XDS du document et celles de
l'entête du document HL7 CDA R2.
Les métadonnées XDS (ebXML) du document et du lot soumis sur l’entrepôt XDS sont
indexées dans le registre XDS : elles servent aux opérations de recherche, de sélection et
d’extraction de documents par les PS et permettent aussi d’organiser les documents selon
différents axes de classement.
Taille maximum des champs ebXML
La longueur des champs est spécifiée dans IHE XDS.b ou à défaut dans ebXML mais dans
certains cas, une longueur spécifique est précisée dans le présent document.
182 / 254
Ⓔ
EX_2.1-1120
Identifiants uniques des documents et des lots de soumission
Ⓔ
Chaque document et lot de document(s) produit par un LPS doit être identifié par un
identifiant universel (champ XDS « uniqueId » au format OID) :

soit le uniqueId est généré à partir d’un UUID (sous la branche OID 2.25), dans ce
cas cet OID doit être stocké dans le LPS pour les recherches / remplacements futurs
via ce même LPS ;

soit le uniqueId est généré à partir d’une racine propre à l’installation du LPS et d’un
élément stocké dans ce LPS (par exemple identifiant interne du document dans le
LPS, en général clé primaire) ; le uniqueId pourra donc être reconstruit
dynamiquement pour les recherches / remplacements futurs via ce même LPS.
Auteur et responsable légal d’un document
EX_2.1-1140
Ⓔ
L’association d’un document à son ou ses auteurs est assurée par la métadonnée XDS
authorPerson ou legalAuthenticator (le responsable légal est donc assimilé à l’un
des auteurs).
Seul l’un des auteurs d’un document peut ajouter un document ou le mettre à jour avec une
nouvelle version (remplacement du document) ; cette règle est appliquée comme suit :


en authentification directe (hors CPE), le PS authentifié doit faire partie des auteurs
(champ NameID du VIHF = composant « identifiant » de authorPerson ou de
legalAuthenticator) ;
en authentification indirecte (ou par CPE), la structure authentifiée (ou de laquelle
dépend la CPE) doit être égale à la métadonnée authorInstitution de l’un des
auteurs (champ Identifiant_Structure du VIHF = champ « identifiant » de
authorInstitution).
[DEROGATION SPECIFIQUE DMP]
Le CI-SIS impose que les métadonnées « authorPerson » et « legalAuthenticator »
correspondent à des personnes physiques (ou un dispositif médical pour "authorPerson").
"AuthorPerson" est aussi accompagné d'une métadonnée "authorInstitution" qui permet de
connaître la structure de soins auquel appartient l'auteur (ce n'est pas le cas pour
"legalAuthenticator").
Si le responsable du document fourni par la STS n’est pas significatif pour le lecteur, il est
accepté pour des problématiques d’affichage et de manière dérogatoire que certaines
données soient alimentées avec le nom d’une personne morale :

Le LPS d’une STS peut alimenter la métadonnée "authorPerson" du lot de
soumission avec les informations d’une personne morale (au lieu d'un nom de
personne physique) ;
183 / 254
EX_2.1-1130

Le LPS d’une STS peut alimenter la métadonnée "authorPerson" du document
avec les informations d’une personne morale (au lieu d'un nom de personne
physique) ;
Le LPS d’une STS peut alimenter la métadonnée "legalAuthenticator" du
document avec les informations d’une personne morale (au lieu d'un nom de
personne physique).
La personne morale fournie dans les métadonnées peut être la structure de soins elle-même
ou un sous-ensemble plus « parlant » pour le lecteur du DMP (service, unité fonctionnelle).
Ces dérogations sont provisoires. Tout document produit après la fin de la dérogation devra
fournir l’information d’une personne physique dans les métadonnées. La dérogation
continuera à s’appliquer pour les documents ayant alimenté le DMP avant la fin de la
dérogation.
Dans ce cadre dérogatoire, les données authorPerson et legalAuthenticator, doivent être
renseignées comme suit :
Composant
Donnée
Valeur
Composant 1
Identifiant
identifiant interne de la personne physique
impliquée (ex : 3 + FINESS/id interne)
Composant 2
Nom
libellé de la personne morale
Composant 3
Prénom
type de personne morale entre parenthèses :
(structure de
fonctionnelle)
soins),
(service)
ou
(unité
Composant 9
Autorité d’affectation
OID de l’organisation (comme pour une personne
physique, voir § 5.1.4 « Identifiant des PS »)
Composant 10
Type de nom
U (Undefined)
Composant 13
Type d’identifiant
EI (comme pour une personne physique)
Le comportement nominal décrit dans le CI-SIS reste bien évidement privilégié par le SI
DMP.
[FIN DEROGATION SPECIFIQUE DMP]
184 / 254

Cas spécifique de l’alimentation du DMP par CPE (TD2.2) :



authorPerson
o composant 1 : Identifiant du porteur de CPE, lu en carte (i.e. identifiant de la
structure + « / » + identifiant interne de l’employé dans la structure)
o composant 2 : Prénom du porteur de CPE, lu en carte
o composant 3 : Nom du porteur de CPE, lu en carte
o autres composants identique à l’authentification directe
authorInstitution
o composant 1 : Nom de la structure
o composant 10 : Identifiant de la structure
o autres composants identique à l’authentification directe
legalAuthenticator
o composant 1 : Identifiant du porteur de CPE, lu en carte (i.e. identifiant de la
structure + « / » + identifiant interne de l’employé dans la structure)
o composant 2 : Libellé de la personne morale
o composant 3 : Type de personne morale entre parenthèses : (structure de
soins), (service) ou (unité fonctionnelle)
o composant 9 : OID de l’organisation (comme pour une personne physique,
voir § 5.1.4 « Identifiant des PS »)
o composant 10 : U (Undefined)
o composant 13 : EI (comme pour une personne physique)
9.1.4.2.2 Les métadonnées d’un document
Les métadonnées du document à envoyer sont définies dans [CI-PARTAGE] § 3.4.
authorInstitution
La métadonnée authorInstitution a une optionalité conditionnelle (C) mais elle est à
renseigner obligatoirement dans le cas où le document est déposé dans le DMP par un PS /
une STS (les documents soumis par un patient ne comportent pas cette métadonnée).
comments
Le DMP limite les champs "commentaires" des documents à 1000 caractères.
hash
Le champ hash des métadonnées XDS est optionnel pour le producteur du document.
Toutefois, s'il est fourni, l'entrepôt XDS [le SI DMP] en vérifiera le calcul.
Il s'agit du hash XDS tel que défini dans les spécifications IHE XDS (voir IHE ITI TF Vol3 au
§ 4.1.7 : "SHA1 / Document hash calculated with SHA1 algorithm / See RFC 3174 US
Secure Hash Algorithm 1 (SHA1), September 2001. The encoding is the Lexical
Representation of hexBinary ([0-9a-fA-F])".
Si le document n'est pas signé, le hash doit être calculé sur le "binaire brut" de la pièce jointe
au message SOAP (part MTOM, dans le cadre du DMP il s'agit d'un CDA R2) et non sur le
XML CDA R2 canonisé.
185 / 254
Dans le cas d’une alimentation via CPE les métadonnées author et legalAuthenticator
doivent être renseignées de la manière suivante :
Si le document est signé, se référer au document [CI-PARTAGE] § 3.4.
practiceSettingCode
le
CI-SIS
(voir
le
fichier
ASIP-
Le document [CI-ANX-PS-STRU] indique au § 4.4 comment renseigner cette métadonnée.
Voir aussi le § 5.2.4 « Cadre d’exercice et situation d’exercice ».
sourcePatientId
Le champ sourcePatientId doit a minima contenir l'identifiant du patient dans le système
émetteur du document (identifiant patient interne dans l'instance du LPS, IPP pour un CH par
exemple). Il est inutile d’y mettre l’INS-C puisque celui-ci est transmis dans le champ
patientId. De plus, la version 1.3 du CI-SIS restreint le sourcePatientId à la cardinalité [1..1] :
il est donc recommandé de ne renseigner que l'identifiant patient local dans le LPS source
pour sourcePatientId.
sourcePatientInfo
Cette métadonnée contient les traits d’identité du patient qui sont fournis à travers plusieurs
champs PID. Seul le champ PID-5 « Patient Name » est requis et il est lui-même composé
de plusieurs composants dont :
o
o
Le composant 1 (requis) : Nom du patient
Le composant 7 (requis) : type de nom (L pour Nom de famille, D pour Nom d’usage)
186 / 254
Le jeu de valeurs associé est fourni dans
SANTE_practiceSettingCode_<aaaammjj>.jv).
9.1.4.2.3 Métadonnées d’un lot de soumission
Les métadonnées du lot de soumission à envoyer sont définies dans [CI-PARTAGE] § 3.5.
La date dans la métadonnée submissionTime doit être égale à la date du jour de la
soumission du lot vers le DMP (ceci permet d’effectuer des recherches par date de
soumission dans le DMP). Si la date ne correspond pas à la date du jour, une erreur du type
XDSRegistryMetadataError est renvoyée.
Les contrôles suivants sont effectués par le DMP lors de l’alimentation (extrait du § 4.2.2 de
[CI-PARTAGE]) :
o
o
La date de signature du lot (creationTime du doc DSG) est postérieure à la date de
création des documents constituant le lot et
La date de signature du lot (creationTime du doc DSG) est antérieure (ou égale) à la
date d'envoi du lot (submissionTime).
Dans la réalité, le document est créé par le PS (lors de la rédaction d'un compte rendu par
exemple) puis le LPS crée puis signe le lot avant de l'envoyer.
La chronologie des dates "techniques" est donc la suivante :
1) date de création du document (cohérence à assurer entre XDS et CDA),
2) date de signature du lot (= date creationTime du document DSG de signature du
lot, aussi égale à celle dans la pièce jointe XAdES sous <SigningTime>),
3) date de soumission du lot (submissionTime).
Si le lot est signé juste avant l'envoi (dans le même process), nous vous recommandons de
faire en sorte que les dates 2) et 3) soient égales (en créant une référence en début de
processus d'export par exemple, affectée à ces 2 dates).
Le submissionTime est utilisé pour les recherches de lots.
authorInstitution
La métadonnée authorInstitution a une optionalité conditionnelle (C) mais elle est à
renseigner obligatoirement dans le cas où le document est déposé dans le DMP par un PS /
une STS (les documents soumis par un patient ne comportent pas cette métadonnée).
title
La taille du champ "titre" des lots de soumission n'étant pas fixée dans XDS.b, c'est celle
d'un type "Name/LocalizedString.value" de la norme ebXML sous-jacente qui s'applique, à
savoir 256 caractères.
comments
Le DMP limite les champs "commentaires" des lots de soumission à 1000 caractères.
187 / 254
submissionTime
contentTypeCode
Le jeu de valeurs associé est fourni
SANTE_contentTypeCode_<aaaammjj>.jv).
dans
le
CI-SIS
(voir
le
fichier
ASIP-
Pour alimenter le contentTypeCode, il faut prendre la valeur la plus appropriée dans la
nomenclature par rapport au contexte métier du LPS : il s'agit du type d'activité de
l'évènement clinique ayant abouti à l'envoi du/des document(s) du lot de soumission.
Le document [CI-ANX-PS-STRU] indique au § 4.1 comment renseigner cette métadonnée.
En établissement, un rapprochement avec le service à l'origine du document de santé peut
être envisagé (paramétrage au niveau service/UF).
La nomenclature est issue des types d'activité de la SAE publiée par la DREES. Le PV1-21
des flux IHE PAM en établissement utilise cette nomenclature.
9.1.5 Signature du document (non obligatoire)
La signature des documents n’est pas obligatoire.
Les documents peuvent cependant être signés conformément aux mécanismes spécifiés
dans [CI-PARTAGE] au § 4.2.1 « Imputabilité du contenu des documents » (signature
XAdES).
L’annexe au § 11.5.3 décrit les contraintes de signature XAdES à mettre en œuvre pour le
DMP.
9.1.5.1 En authentification directe
Si le document est signé, le certificat utilisé pour signer le document doit correspondre au
responsable du document tel que présenté dans l’entête CDA et la métadonnée XDS
legalAuthenticator.
REC_2.1-1150
Ⓡ
La signature par carte CPS/CPE entrainant un temps de traitement supplémentaire variable
en fonction de la configuration matérielle (lecteur CPS), le LPS peut implémenter la
possibilité de signer ou non les documents (en plus des lots de soumission) en fonction d’un
paramètre au niveau du LPS, au niveau de l’utilisateur, ou encore laisser l’utilisateur décider
au cas par cas s’il souhaite signer tel ou tel document.
9.1.5.2 En authentification indirecte
Si le document est signé, il doit être signé avec le certificat de personne morale de la
structure de soins. Dans ce mode d’authentification, il n’y a pas de correspondance entre la
métadonnée XDS legalAuthenticator et le certificat.
188 / 254
Il n'y a pas d'équivalent à ce champ dans le CDA.
9.1.6 Constitution et signature du lot de soumission
Envoi de un ou plusieurs documents dans le DMP d’un même patient
REC_2.1-1160
Grouper les documents dans un même lot de soumission
(Illustré à travers l’exemple de la fiche RCP)
Il est recommandé que le LPS permette au PS de sélectionner plusieurs documents à
envoyer dans le DMP du patient, en indiquant pour chacun d’eux les paramètres de
masquage aux PS et de visibilité au patient (voir ci-dessous) et de constituer ainsi un lot de
soumission avec plusieurs documents médicaux d’un même patient en rapport avec un
événement de soins.
Ⓡ
Cela permettra notamment aux autres médecins de les identifier et d’y accéder beaucoup
plus simplement. A titre d’exemple, lorsqu’une fiche RCP, un CR-Opératoire et un CR-ACP
sont liés par le même lot de soumission, en accédant à la fiche RCP, le médecin peut voir
qu’il existe 2 « documents liés » (cette fonctionnalité existe déjà sur l’Accès web DMP).
Note : Un même document peut être référencé dans plusieurs lots de soumission.
Pour lier les documents entre eux dans un même lot de soumission, deux méthodes sont
possibles :
 Les envoyer dans le DMP en même temps dans le même lot de soumission. Par
exemple, il est recommandé d’envoyer dans le DMP, dans le même lot de
soumission, la fiche RCP, le CR-Opératoire, le CR-ACP et tout autre document que
le médecin peut juger utile à la coordination des soins.

Envoyer un nouveau document (par exemple la fiche RCP) et la référence des
autres documents déjà postés dans le DMP dans le même lot de soumission. Cela
implique que le LPS doit d’abord récupérer la référence des documents du DMP à
lier au nouveau document (via la transaction Recherche de document du DMP
TD3.1).
EX_2.1-1170
Ⓔ
Afin de garantir l’imputabilité de la transmission des documents au sein du DMP, les lots de
documents devront être signés conformément aux mécanismes spécifiés dans [CIPARTAGE] au § 4.2.2 « Imputabilité du dépôt des documents » (signature XAdES).
L’annexe au § 11.5.3 décrit les contraintes de signature XAdES à mettre en œuvre pour le
DMP.
189 / 254
Le LPS envoie dans le DMP du patient un lot de soumission contenant un ou plusieurs
documents.
Envoi de documents antérieurs à la date de création du DMP du patient
Message spécifique au premier envoi d’un document dans le DMP d’un patient
Ⓡ
Ⓔ
REC_2.1-1180
Afin de favoriser le déploiement du DMP, à l'occasion du premier envoi d'un document vers
le DMP pour un patient donné, il est recommandé que le LPS puisse sélectionner les
documents du dossier patient non présents dans le DMP pour proposer au professionnel de
santé de les envoyer dans le DMP.
EX_2.1-1190
Le LPS doit implémenter une solution permettant à l’utilisateur d’identifier visuellement si des
documents utiles à la coordination des soins peuvent être envoyés au DMP (message,
icônes dans une liste de documents, etc.).
9.1.6.1.1 Métadonnées du document portant la signature du lot de soumission
Le document comportant la signature du lot de soumission est un document XML auquel
sont associées des métadonnées permettant son indexation.
Le document [CI-PARTAGE] au § 4.2.2 « Imputabilité du dépôt des documents » précise
comment renseigner ces métadonnées et en particulier :
confidentialityCode
Pour l’alimentation du DMP, il y aura 3 occurrences de la métadonnée confidentialityCode
avec les valeurs « N », « MASQUE_PS » et « INVISIBLE_PATIENT ».
190 / 254
Il est possible d’alimenter le DMP d’un patient avec des documents utiles à la coordination
des soins et antérieurs à la date de création du DMP.
9.1.7 Transaction : Envoi de la requête au DMP
La transaction est décrite dans [CI-PARTAGE] § 3.3.1 (IHE ITI-41 : Provide and Register
Document Set-b).
Les données en entrées de la transaction doivent être respectées.
9.1.7.1.1 Identifiant des entités ebXML de la requête
La requête ProvideAndRegisterDocumentset-b nécessite que chaque « entité » ebXML de la
requête soit identifiée par un identifiant globalement unique (par exemple les champs
entryUUID des lots et documents) au format « uuid » (différent du format OID).
Le profil IHE XDS.b propose deux méthodes :
1. Méthode 1 : méthode à utiliser dans les LPS
EX_2.1-1200
Ⓔ
Générer des identifiants internes à la requête dont le format n’est pas « uuid ». Par exemple
en utilisant des "compteurs" internes : document01, submissionSet01, cla1, cla2, assoc1
assoc2, etc. (exemples d’identifiants nommés avec un préfixe représentatif du type d'entité
ebXML qu'ils identifient : permet de faciliter le débogage en phase de développement).
Ces identifiants internes seront régénérés en « uuid » par le serveur DMP lors du stockage
de l’entité (lot ou document).
2. Méthode 2 : cette méthode n’est pas autorisée pour le DMP
Générer des identifiants de type « uuid » par programmation (préfixés par « urn:uuid ») avec
un algorithme qui assure l'unicité de cet uuid (exemple : urn:uuid:ad211b35-0324-11e28d7a-00163e586487).
Cependant, cette méthode pose un problème dans le cadre d’un service comme le DMP.
Dans le cas où le LPS génèrerait les entryUUID des documents lui-même (format « uuid »),
et en cas de modification du statut de confidentialité (confidentialityCode) du document
(masquage/démasquage/visibilité) avec la TD3.3 par un autre PS (médecin traitant par
exemple) via un autre média (WebPS ou autre LPS), l'entryUUID de la version de
métadonnées (fiche) stockée au sein du Registre XDS changerait. Il s'agirait d'une nouvelle
instance des métadonnées du document (fiche) avec un nouvel identifiant de métadonnées
(entryUUID « B »). L’entryUUID « A » généré initialement (s’il est stocké comme référence
au sein du LPS) ne serait plus valable en cas de nouvelle requête TD3.3
(dépublication/masquage/archivage) par le LPS à partir de cet entryUUID « A ». Le DMP
renverrait une erreur, car la version de métadonnées du document correspondant à
l’entryUUID « A » est au statut « deprecated » et ne peut donc pas être modifiée.
La requête stockée XDS.b GetDocuments (TD3.1) permet de récupérer la référence unique
au sein du RegistreXDS (entryUUID) de la dernière version des métadonnées du document,
à partir du champ uniqueId du document (format OID).
191 / 254
L’alimentation se fait sur le Repository XDS.b.
En cas d’erreur lors de la dépose du lot de document(s), le Repository retourne un code
status=urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure, conformément au
profil XDS.b, ainsi qu’un code d’erreur et éventuellement un message de détail. Le retour
d’erreur est détaillé dans [IHE-TF3] § 4.1.13.
La table 4.1-11 du doc [IHE-TF3] récapitule les codes d’erreur standards de XDS.
Le tableau suivant décrit l’utilisation des codes d’erreur par le DMP : voir annexe au § 11.4.
Détection de virus
En cas de document contaminé par un virus, le service de gestion des documents retourne
une erreur de type DMPVirusFound. Au sein de l’erreur, un message à caractère informatif
indiquera quel est l’identifiant unique (uniqueId) du document infecté. Aucun document
n’est alors enregistré dans le DMP.
Vérification des signatures
La signature du lot de soumission et/ou celle des documents sont vérifiées lors de la dépose.
En cas d’erreur, une erreur DMPInvalidSignature est alors renvoyée.
192 / 254
En cas de succès de la dépose du lot de document(s), le Repository retourne un code
status=urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success, conformément au
profil XDS.b.
9.2 Remplacement d’un document existant dans
le DMP
Pour remplacer un document existant X dans le DMP par une nouvelle version Y, la
cinématique est la suivante :
1. Le PS modifie le document X dans le LPS (corps et/ou métadonnées) pour créer le
document Y;
2. Le LPS récupère l’entryUUID du document X dans le DMP avec la requête XDS
GetDocuments(uniqueId=1.2.3.X)
3. Le LPS construit le document XDS/CDA ;
a. XDS : Association RPLC sur l’entryUUID du document X ;
b. CDA : relatedDocument=1.2.3.X ;
4. Le LPS constitue un lot de soumission XDS et réalise la signature XAdES du lot ;
5. Le LPS envoie la requête au DMP ;
6. Le document X est remplacé par le document Y.
Ⓔ
EX_2.1-1210
Le LPS doit proposer au PS la fonctionnalité de remplacement d'un document qui doit être
conforme aux principes décrits ci-après.
D’un point de vue technique, le « remplacement de document » utilise la même transaction
que pour une « alimentation simple », aux différences exposées ci-après.
Pour remplacer un document (fiche métadonnées XDS + document CDA), il faut envoyer la
nouvelle version du document à l’entrepôt du DMP (repository XDS) pour remplacer dans le
registre (registry XDS) l’ancienne fiche du document par la nouvelle.
Dans la nouvelle fiche, la métadonnée availabilityStatus prend la valeur « approved ».
Dans l’ancienne fiche, la métadonnée availabilityStatus prend la valeur « deprecated ».
Ces deux fiches sont liées par une association de type « RPLC » (replace).
Le registre identifie les fiches par leur identifiant clé entryUUID. Dans les concepts XDS, un
document pourrait être envoyé à plusieurs « systèmes cibles », et donc être indexé dans
plusieurs registres, voire plusieurs fois par registre – non autorisé dans le DMP (« instance » de fiche différente dans chaque registre, mais pour un même document de
même uniqueId (de type OID, généré par le producteur de document)).
193 / 254
Soient X le document initial (uniqueId = 1.2.3.X) et Y la nouvelle version du document
(uniqueId 1.2.3.Y).
Etape 1 : Récupérer l’entryUUID du document.
Cas particulier de l’authentification indirecte ou par CPE qui ne donnent pas
accès à la Consultation : pour récupérer l’entryUUID d’un document à remplacer,
une structure de soins en authentification indirecte (ou une CPE) doit utiliser la
requête stockée GetDocuments en mode ObjectRef. Ce mode renvoi seulement la
référence entryUUID (sans autres métadonnées).
Cas particulier d’un LPS ne supportant pas le profil « Consultation de DMP » en
mode d’authentification directe : pour récupérer l’entryUUID d’un document à
remplacer à partir de son uniqueId, le LPS doit utiliser la requête GetDocuments en
mode ObjectRef.
Etape 2 : Alimenter le DMP avec le nouveau document.
Par rapport à une alimentation standard, un remplacement de document nécessite donc :


dans les métadonnées XDS : une association de type RPLC entre le document
remplaçant et le document remplacé (via le entryUUID du document remplacé) ; les
spécifications se trouvent dans [IHE-TF3] (chapitre 4.1.6 Document Relationships
and Associations),
dans
le
CDA
du
document
remplaçant
un
élément
relatedDocument/parentDocument/id référençant le uniqueId du document remplacé
(voir [CI-STRU-ENTETE] au chapitre 3.5.5.21 relatedDocument – Document
référencé à remplacer).
194 / 254
Afin de récupérer l’« entryUUID » du document à remplacer, le LPS utilisera la transaction
TD3.1 « Registry Stored Query », en utilisant la requête stockée « GetDocuments » avec en
paramètre d’entrée le « uniqueId » du document.
10 Consultation du DMP



de rechercher les documents contenus dans un DMP (TD3.1),
de consulter ces documents (TD3.2) ou
d’en modifier les attributs (TD3.3) :
o masquer / démasquer un document aux PS,
o rendre un document visible du patient
o archiver / désarchiver un document
o supprimer (ex dépublier) un document
Pour la consultation, il convient d’abord d’utiliser la transaction TD3.1 pour rechercher une
liste de documents à partir de critères de recherche (seules les métadonnées de ces
documents sont alors récupérées) puis d’utiliser ensuite la transaction TD3.2 pour récupérer
les documents à consulter.
Pour la modification des attributs d’un document, il convient d’abord d’utiliser la
transaction TD3.1 pour récupérer le document (et plus particulièrement les métadonnées de
ce document) puis d’utiliser ensuite la transaction TD3.3 pour en modifier les attributs.
Cas d’usage particulier de la TD3.1
L’accès à la transaction TD3.1 de recherche de document n’est pas autorisé dans les cas
suivants :


Authentification indirecte
Authentification directe sans le profil Consultation
Or pour permettre le remplacement et la suppression d’un document (avec le profil
Alimentation), il est nécessaire de pouvoir utiliser la TD3.1 pour récupérer les entryUUID de
ces documents.
L’accès à la TD3.1 est donc autorisé avec les restrictions suivantes :


Seules les références d’objets entryUUID peuvent être retournées
Seule la requête GetDocuments en mode ObjectRef peut être utilisée
Les détails sur la mise en œuvre de cette transaction dans ces cas particuliers sont décrits
au paragraphe § 9.2 pour le remplacement et au paragraphe § 10.3.2 pour la suppression.
Rappel : Les règles d’accès et les droits fonctionnels sont résumées au § 7.3.
195 / 254
Les transactions du profil Consultation permettent :
10.1 TD3.1 - Recherche de documents dans un
DMP
10.1.1
Prérequis
10.1.2
Cinématique
1. le PS saisit un ou plusieurs critères de recherches dans le LPS ;
2. le LPS envoie la requête au DMP ;
3. le DMP retourne les résultats au LPS.
10.1.2.1 Recherche de documents
La recherche se fait « patient par patient »
La transaction TD3.1 de recherche ne peut s’effectuer que sur un seul DMP. Lorsque le
paramètre patientId (contenant l’INS du patient) de la requête StoredQuery n’est pas fourni,
le DMP récupère l’INS du patient dans le VIHF et l’inclut automatiquement dans la requête.
Recherche sur le type de document et la date de soumission
Ⓔ
EX_3.1-1010
Le LPS doit permettre au PS de rechercher des documents :


sur le type du document (métadonnée typeCode) ;
sur la date de soumission du document dans le DMP.
Recherche de nouveaux documents depuis la dernière connexion
EX_3.1-1020
Ⓔ
Le LPS doit mettre en œuvre une fonction de recherche des documents depuis la dernière
connexion d’un PS au DMP du patient ou depuis la précédente recherche de documents de
ce PS sur le DMP du patient. Il doit donc stocker en interne la date de dernière connexion du
PS au DMP (ou date de dernière recherche des nouveaux documents), puis faire une
requête sur les lots de soumission en passant cette date à la requête
FindSubmissionSets dans le paramètre $XDSSubmissionSetSubmissionTimeFrom et
combiner une ou d’autres fonctions pour récupérer les documents associés (voir
« Recherche de document soumis dans un intervalle temporel » au § 10.1.3.1).
196 / 254
Filtres sur documents actifs, archivés, masqués, non visibles du patient, obsolètes
EX_3.1-1030
Par ailleurs, la recherche de document devra proposer au PS de pouvoir filtrer cette liste :
Ⓔ

avec ou sans les documents archivés (champ XDS availabilityStatus = « urn:asip:cisis:2010:StatusType:Archived »), l’activation pouvant se faire via une case à cocher
« afficher les documents archivés » ;

avec ou sans les documents masqués -fonctionnalité réservée au médecin traitant(champs XDS confidentialityCode= « MASQUE_PS » de la nomenclature d’OID
1.2.250.1.213.1.1.4.13) ;

avec ou sans les documents non visibles au patient (champs XDS
confidentialityCode= « INVISIBLE_PATIENT » de la nomenclature d’OID
1.2.250.1.213.1.1.4.13) ;

avec ou sans les documents obsolètes (champ XDS availabilityStatus =
« urn:oasis:names:tc:ebxml-regrep:StatusType:Deprecated »), l’activation pouvant se
faire via une case à cocher « afficher les anciennes versions des documents
(obsolète / remplacés) ».
Le LPS est libre de mettre en œuvre d’autres critères de recherche.
10.1.2.2 Affichage des résultats
Documents produits par le patient
Ⓔ
EX_3.1-1040
Certains documents peuvent être produits par le patient, via son accès Web. Lors de la
consultation du DMP, ces documents doivent être distingués des documents produits par des
PS (code couleur différent, pictogramme…). Le LPS devra se baser sur le classCode XDS
« 90 » (Expression du titulaire) pour distinguer les documents de « type patient ».
197 / 254
La recherche de document devra proposer systématiquement au PS la liste des documents
actifs du DMP (champ XDS availabilityStatus = « urn:oasis:names:tc:ebxmlregrep:StatusType:Approved »).
Documents de type inconnus
EX_3.1-1050
1. soit par un typeCode / classCode XDS non connu (type de document) ;
2. soit par un formatCode XDS non connu (nouveau volet de contenu structuré par
exemple).
Le LPS doit pouvoir afficher le document à l’utilisateur, par exemple à l’aide d’une feuille de
style XSL standard - une feuille de style minimale, non normative, est fournie dans le CI-SIS
(CI-SIS_Test contenus CDA, téléchargeable sur le site de l’ASIP, rubrique « CI-SIS :
Interopérabilité sémantique : Composants téléchargeables »).
Etat du document
REC_3.1-1060
Lors de l’affichage des résultats à la suite de recherches de document, il est recommandé
d’indiquer au PS l’état du document qui peut être :
Ⓡ
-
« masqué aux professionnels de santé »
« non visible par le patient »
« archivé »,
« ancienne version obsolète »
Il est recommandé d’utiliser les termes indiqués ci-dessus en gras. L’éditeur peut aussi
utiliser une icône représentant chacun de ces états.
Il n’y a pas de valeur spécifique pour un document « courant » (on ne précise pas d’état
particulier).
Un document masqué PS reste visible à son auteur et au médecin traitant. La visibilité à
l’auteur se base sur le contenu de la métadonnée XDS authorPerson ou
legalAuthenticator comparée aux données d’identification de l’utilisateur issues du
VIHF. Ce filtre est réalisé par le SI DMP et n’a donc pas à être implémenté dans les LPS.
Point d’attention sur les champs date/heure :
Les champs de type date/heure sont codés dans une zone de temps différente entre les
métadonnées XDS et le CDA R2. Les champs date/heure XDS sont être codés en UTC
(universal coordinated time) et ceux du CDA correspondant en heure locale incluant le
décalage par rapport à UTC (GMT).
198 / 254
Ⓔ
Le LPS ne doit pas refuser un type de document qu’il ne connait pas :
Ⓔ
Il est demandé d’afficher la date du document en heure locale :

dans le cas d’une recherche de documents (TD3.1 - IHE ITI-18 Registry Stored Query
XDS) : en se basant sur la métadonnée XDS, avec conversion dans la date locale
avant l’affichage à l’utilisateur.
EX_3.1-1080
Il est demandé d’afficher la date du document en heure locale :

dans le cas d’une consultation de documents (TD3.2 - IHE ITI-43
RetrieveDocumentSet XDS) : en se basant sur les données d’en-tête CDA et en
indiquant qu’il s’agit de l’heure locale du producteur du document.
10.1.3
Transaction
Le profil IHE XDS.b utilisé pour la consultation est décrit au § 5.1.2.
La transaction est décrite dans [CI-PARTAGE] § 3.3.2 (IHE ITI-18 : Stored Query).
La recherche se fait sur la Registry XDS.b.
Les requêtes « Stored Query » disponibles via le Web Service de la Registry, ainsi que les
critères de recherche de chaque requête, sont définis dans [IHE-TF2A] § 3.18.
Les données en entrée dépendent des critères de recherche disponibles pour la requête
appelée (voir [IHE-TF2A] § 3.18).
A titre d’information, le tableau ci-après liste les Stored Query XDS mis en œuvre par le SI
DMP (les « Folder » (Classeurs) n’étant pas mis en œuvre dans le cadre du DMP, les
méthodes grisées ne sont pas mises en œuvre). NB : ce tableau de synthèse se focalise sur
les paramètres d’entrée « requis » de type « référence uniqueId ou entryUUID », mais
d’autres paramètres peuvent éventuellement être passés à chaque query (voir
documentation IHE).
199 / 254
Ⓔ
EX_3.1-1070
Fonctionnalité
DMP
FindDocuments
Recherche multicritère de documents
X
FindSubmissionSets
Recherche multicritère de lots de soumission
X
FindFolders
Recherche multicritère de Classeurs
GetAll
Récupération de tout le contenu XDS d’un DMP X
(documents, lots et associations)
Note : peu recommandé car peut être lent sur des
DMP comportant beaucoup de documents. Peut
servir pour la mise au point du LPS
(développement).
GetDocuments
Récupération d’un ou plusieurs documents à partir X
de leurs uniqueId ou entryUUID en entrée
(paramètres exclusifs)
GetFolders
Récupération d’un ou plusieurs classeurs
GetAssociations
Récupération des associations liées à un ou X
plusieurs autres objets XDS (documents, lots,
classeurs) dont l’entryUUID est passé en entrée
GetDocumentsAndAssociations Récupération d’un ou plusieurs documents avec X
toutes leurs associations qui y sont liées, à partir de
leurs uniqueId ou entryUUID en entrée (paramètres
exclusifs)
GetSubmissionSets
Récupération d’un ou plusieurs lots de soumission X
à partir du entryUUID d’un ou plusieurs
document(s) (ou d’un ou plusieurs classeur(s))
contenu(s) dans le lot.
En d’autre terme, récupération des lots dans lequel
est référencé le document (ou classeur).
GetSubmissionSetAndContents Récupération d’un lot de soumission avec tout son X
contenu (documents, classeurs, associations), à
partir de son uniqueId ou entryUUID en entrée
(paramètres exclusifs)
GetFolderAndContents
Récupération d’un classeur avec tout son contenu
(documents, associations), à partir de son uniqueId
ou entryUUID en entrée (paramètres exclusifs)
GetFoldersForDocument
Récupération des classeurs dans lesquels est
inclus un document, à partir du uniqueId ou
entryUUID du document en entrée (paramètres
exclusifs)
GetRelatedDocuments
Retourne les documents qui sont liés par des X
associations à un document précis (seule
l’association XDS de remplacement RPLC est
autorisée dans le DMP), à partir du uniqueId ou
entryUUID du document en entrée (paramètres
exclusifs)
Tableau 79 : Stored Query XDS mises en œuvre par le DMP
200 / 254
Nom du query
Recherche de document « basique »
Recherche de document soumis dans un intervalle temporel
Dans XDS, il n’existe pas de requête « Stored Query » pour rechercher les documents
soumis au Repository dans un intervalle temporel donné.
Plusieurs approches permettent néanmoins de le faire, en combinant plusieurs requêtes :
1) combinaison de FindSubmissionSet / GetSubmissionSetAndContents (soit N+1
appels de fonctions, en fonction du nombre N de lots retournés) :
a. utilisation de la requête FindSubmissionSets pour rechercher les lots de
soumission en spécifiant un intervalle temporel de soumission (date de
soumission dans le DMP, critère
« $XDSSubmissionSetSubmissionTimeFrom » et
« $XDSSubmissionSetSubmissionTimeTo ») : retourne les lots de
soumission ;
b. pour chaque lot retourné, faire un GetSubmissionSetAndContents qui
retourne le lot et ses documents ;
2) combinaison de FindSubmissionSet / GetAssociations / GetDocuments (soit 3 appels
de fonctions) :
a. utilisation de la requête FindSubmissionSets pour rechercher les lots de
soumission en spécifiant un intervalle temporel de soumission (date de
soumission dans le DMP, critère
« $XDSSubmissionSetSubmissionTimeFrom » et
« $XDSSubmissionSetSubmissionTimeTo ») : retourne les lots de
soumission ;
b. récupérer l'ensemble des entryUUID des lots retournés ;
c. passer cette liste d'entryUUID à la fonction GetAssociations ;
d. filtrer les retours sur les Associations de type HasMember, et récupérer la liste
des targetObject (documents du lot) ;
e. appel de GetDocuments avec la liste des entryUUID des documents.
201 / 254
La requête adaptée à la recherche de document est FindDocuments.
Limitation de certains paramètres multivalués Et/Ou
Le DMP restreint l’utilisation multivalué Et/Ou des paramètres suivants :

requête : FindDocuments :
o
XDSDocumentEntry.eventCodeListCode ;
o
XDSDocumentEntry.confidentialityCode ;
requête : GetSubmissionSetAndContents :
o
XDSDocumentEntry.confidentialityCode.
Pour ces 2 requêtes et ces paramètres, Le DMP supporte la sémantique Et/Ou mais pour un
nombre fini de valeurs fixé à 5 pour les Et. En d’autres termes, un paramètre multi-valué peut
comporter un nombre infini de valeurs entre lesquelles un Ou doit être utilisé mais ne peut
supporter que 5 valeurs pour lesquelles un Et doit être utilisé. En cas de dépassement du
nombre de valeurs possible, un code d’erreur XDSStoredQueryParamNumber est
retourné. La valeur codeContext contient alors, en plus du nom du paramètre et de la
valeur associée, une entrée maxAND=5.
En cas de succès de la requête, la Registry retourne
o
o
un code status=urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success,
conformément au profil XDS.b,
les objets retournés par la requête (documents et/ou lots, et/ou association entre les
documents et les lots).
Matrice d’habilitation
Conformément au CI-SIS (voir [CI-PARTAGE] § 4.1), la recherche de document est soumise
à la restriction d’accès de la matrice d’habilitation du CI-SIS, en fonction de la profession du
PS connecté et des types de document. Les références des documents non accessibles à
l’utilisateur en fonction de son rôle ne sont pas retournées par le DMP en retour à la
transaction de recherche.
En cas de succès, la Registry retourne un code status=urn:oasis:names:tc:ebxmlregrep:ResponseStatusType:Failure, conformément au profil XDS.b. Le status
PartialSuccess n’est pas géré par le DMP.
202 / 254

10.2 TD3.2 - Consultation d’un document du
DMP
10.2.1
Prérequis
10.2.2
Cinématique
1. le PS recherche des documents via la fonction de recherche de document (TD3.1) ;
2. le LPS affiche les résultats de la recherche au PS (métadonnées de documents) ;
3. le PS sélectionne un ou plusieurs document(s) à consulter parmi les résultats
retournés ;
4. le LPS envoie une requête de demande de document au DMP (TD3.2) à partir du ou
des identifiants de document ;
5. le DMP retourne le document au LPS.
10.2.2.1 Téléchargement de documents
Ⓔ
EX_3.2-1010
Le LPS ne doit pas réaliser de téléchargement systématique du contenu des documents (i.e.
ne pas réaliser de TD3.1 suivi d'une TD3.2 systématique pour chaque document retourné par
la TD3.1).
10.2.2.2 Ne pas conserver les documents téléchargés à partir du DMP
Ⓡ
REC_3.2-1020
Il est fortement recommandé que le LPS n’enregistre pas et ne conserve pas les documents
téléchargés du DMP car les PS peuvent à tout moment, lorsqu’ils sont autorisés, consulter
les documents mis en partage dans le DMP. Ce principe permet de s’assurer que les PS ont
toujours accès à l’information la plus à jour (document modifié par son auteur) et permet
également de respecter les droits du patient (document supprimé à la demande du patient).
203 / 254
Cette fonction permet au PS de visualiser le contenu d’un document du DMP.
10.2.2.3 Affichage du résultat
Le LPS doit permettre l’affichage des données d’entête du document CDA R2.
Documents CDA R2 non structurés
EX_3.2-1040
Le LPS doit prendre en charge et réaliser l’affichage des documents CDA R2 dit « non
structurés ».
Un document non structuré peut être reconnu à l’aide du champ formatCode des
métadonnées XDS associées au document qui est égal à l’une des valeurs suivantes :
Ⓔ





urn:ihe:iti:xds-sd:pdf:2008,
urn:ihe:iti:xds-sd:text:2008,
urn:ihe:iti-fr:xds-sd:jpeg:2010,
urn:ihe:iti-fr:xds-sd:rtf:2010,
urn:ihe:iti-fr:xds-sd:tiff:2010.
Le LPS doit extraire du champ "nonXmlBody/text" le corps du document qui est encodé en
base 64, le décoder et en proposer l’affichage à l’utilisateur (les types mime autorisés sont
pris en charge nativement par la plupart des OS).
Il se peut que la longueur de ce champ ne soit pas un multiple de 4. En effet, certaines
librairies d’encodage base 64 ajoutent le padding de fin (le ou les caractère(s) « = » à la fin
de la chaine) et d'autres non. Il est donc important de savoir décoder des chaines base 64
« sans padding », car les LPS pouvant envoyer des documents dans le DMP sont
hétérogènes en terme de librairie d'encodage base 64. Il suffit de compléter avec la bonne
valeur de padding de fin si la librairie utilisée ne le réalise pas déjà, et si la longueur n'est pas
correcte.
204 / 254
Ⓔ
EX_3.2-1030
Documents CDA R2 structurés
EX_3.2-1050
Un document structuré peut être reconnu à l’aide du champ formatCode des métadonnées
XDS associées au document qui est différent des valeurs suivantes :





urn:ihe:iti:xds-sd:pdf:2008,
urn:ihe:iti:xds-sd:text:2008,
urn:ihe:iti-fr:xds-sd:jpeg:2010,
urn:ihe:iti-fr:xds-sd:rtf:2010,
urn:ihe:iti-fr:xds-sd:tiff:2010.
La différence entre un document structuré CDA R2 « classique » ou un document structuré
CDA R2 « auto-présentable » est signalée par le champ mimeType des métadonnées XDS
associées au document :
-
Ⓡ
Ⓡ
Ⓡ
« text/xml » pour les CDA R2 « classiques »
« application/xslt+xml » pour les CDA R2 « auto-présentables »
REC_3.2-1060
Pour afficher le corps du document (organisé en structures XML), le LPS peut appliquer une
feuille de style XSLT et afficher le résultat à l’utilisateur via un navigateur web,
éventuellement encapsulé.
REC_3.2-1065
Il est recommandé d’afficher les documents CDA auto-présentables à l’aide de la feuille de
style couplée au document. Pour visualiser un document CDA auto-présentable de manière
simple et rapide (et sans développement spécifique), le LPS peut l’ouvrir directement dans
un navigateur. Celui-ci réalise alors l’affichage automatiquement avec la feuille de style
intégrée au CDA.
REC_3.2-1070
Le LPS peut « exploiter » les données structurées pour proposer des affichages à valeur
ajoutée aux professionnels de santé (par exemple une courbe de résultat d’analyses
biologiques).
205 / 254
Ⓔ
Le LPS doit prendre en charge et réaliser l’affichage des documents CDA R2 niveau 3 dit
« structurés ».
Documents liés
Ⓡ
Plusieurs documents peuvent être liés entre eux car ils constituent un ensemble cohérent
pour un même épisode de soins. Lors de la consultation d’un document, il est conseillé
d’afficher les documents qui lui sont liés. Cela permet notamment au médecin qui consulte un
document d’identifier qu’il y a d’autres documents qui peuvent l’intéresser et d’y accéder
beaucoup plus simplement.
Dans le DMP, les documents sont considérés comme liés, dès lors qu’ils ont été groupés
dans le même lot de soumission lors de l’alimentation. Un même document peut être
référencé dans plusieurs lots de soumission.
Exemple de la fiche RCP :
Lors de la consultation de la fiche RCP, le médecin doit pouvoir facilement identifier qu’il
existe un CR-Opératoire et un CR-ACP liés. Ce lien existe dès lors que ces 3 documents ont
été groupés dans le même lot de soumission à l’alimentation du DMP.
10.2.3
Transaction
La transaction est décrite dans [CI-PARTAGE] § 3.3.3 (ITI-43 RetrieveDocumentSet).
La consultation se fait sur le repository XDS.b.
Identifiants des documents (XDSDocumentEntry.uniqueId) et les identifiants des
repository où sont stockés les documents (XDSDocumentEntry.repositoryUniqueId). Ce
dernier paramètre est toujours le même pour le DMP (il est récupéré dans la réponse fournie
par la requête StoredQuery).
En cas de succès de la requête, le Repository retourne un code
status=urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success, conformément au
profil XDS.b, ainsi que le ou les document(s) demandé(s).
En cas d’erreur, le Repository retourne un code status=urn:oasis:names:tc:ebxmlregrep:ResponseStatusType:Failure, conformément au profil XDS.b, ainsi qu’un code
d’erreur et éventuellement un message de détail. Le retour d’erreur est détaillé dans [IHETF3] § 4.1.13.
Le tableau suivant décrit l’utilisation des codes d’erreur par le DMP : voir annexe au § 11.4
206 / 254
REC_3.2-1080
10.3 TD3.3 –
document
Gestion
des
attributs
d’un




masquage / démasquage d’un document aux PS ;
visibilité d’un document au patient ;
archivage / désarchivage d’un document ;
suppression d’un document.
Note : La gestion de la visibilité et du masquage peut s’effectuer lors de la dépose du
document (voir § 9.1.3.3).
Il n’est pas possible qu’un document soit à la fois invisible au patient et masqué aux PS (sauf
document de signature du lot de soumission, comme défini dans [CI-PARTAGE] au § 4.2.2).
Lorsque le document n’est pas visible du patient, il est visible pour les PS autorisés sur le
DMP.
Rappel : Les règles d’accès et les droits fonctionnels sont décrits au § 7.3 mais sont
résumés ici pour la TD3.3 :
Authentification
Personnes
autorisées
En mode bris de
glace ou centre
de régulation
directe
indirecte
Masquer un document
O
N
PS
N
Démasquer un document
O
N
N
Rendre un document visible au patient
O
N
MT,
Auteur
PS
Archiver un document
O
N
N
Désarchiver un document PS
O
N
Archiver un document patient
O
N
PS médecins,
Auteur
PS médecins,
Auteur,
MT
MT
Désarchiver un document patient
O
N
MT
N
4
Supprimer un document PS
O
O pour
Auteur
Supprimer un document patient
O
N
PS médecins,
Auteur,
MT pour doc patient
MT
N
N
N
O pour Auteur
N
Tableau 80 : Résumé des règles d’accès et droits fonctionnels
10.3.1
Prérequis
2. le PS est autorisé à accéder au DMP du patient ;
4
Dans le cas d’une CPE, elle ne pourra supprimer que des documents alimentés par la structure à
laquelle elle est rattachée, par elle-même ou par d’autres CPE rattachées à cette même structure.
207 / 254
Cette transaction permet de mettre à jour les métadonnées suivantes d’un document, sans
soumettre une nouvelle version du document :
10.3.2
Cinématique
Pour la modification des attributs d’un document, il convient d’abord d’utiliser la
transaction TD3.1 pour récupérer le document (et plus particulièrement les métadonnées de
ce document) puis d’utiliser ensuite la transaction TD3.3 pour en modifier les attributs.
1. le PS recherche le document via la fonction TD3.1 « Recherche de documents
sur un DMP » ;
2. le LPS affiche les résultats de la recherche au PS (métadonnées de documents) ;
3. le PS sélectionne le document, indique l’action qu’il souhaite effectuer et confirme
la demande de mise à jour ;
4. le LPS envoie une requête XDS de mise à jour de métadonnée.
Pour le masquage PS, la visibilité patient et l’archivage
Ⓡ
REC_3.3-1010
Pour « masquer/démasquer un document aux PS », « archiver/désarchiver un document »
ou « rendre un document visible du patient », le LPS peut présenter une IHM dédiée
nommée « Modification des propriétés du document » à l’utilisateur.
Exemple de mise-en-œuvre possible :
Modification des propriétés du document
Confidentialité du document
Pour le patient
( ) Rendre le document visible par le patient : vous souhaitez que ce
document soit désormais visible par le patient car il a bien reçu une
information préalable par un professionnel de santé.
Pour les professionnels de santé
(x) Document visible par les professionnels de santé autorisés à accéder
aux documents du DMP du patient
( ) Document masqué aux professionnels de santé : document visible
uniquement par son auteur, les médecins traitants et le patient.
Archivage
(x) Non archivé (toujours visible dans la liste des documents)
( ) Archivé (visible seulement si critère d'affichage des documents archivés
sélectionné)
208 / 254
La cinématique fonctionnelle est la même pour chaque action spécifique sur un document,
définie au § 10.3 :
Ⓔ
EX_3.3-1020
Ⓔ
EX_3.3-1030
Ⓔ
EX_3.3-1040
Toute demande de masquage/démasquage doit donner lieu à une confirmation par le PS
effectuant l’action : le LPS doit proposer un message de confirmation du
masquage/démasquage.
La fonction « Rendre un document visible du patient » est irréversible et ne permet pas de
rendre invisible à nouveau un document visible. Le LPS doit afficher un message demandant
au PS de confirmer l’action.
Pour la suppression d’un document
Un document supprimé n’est plus accessible en consultation mais reste stocké dans le DMP
du patient.
Ⓔ
EX_3.3-1050
La fonction de suppression d’un document est irréversible et un PS ne peut pas annuler une
suppression. Le LPS doit afficher un message demandant au PS de confirmer la
suppression.
EX_3.3-1060
Suppression d’un document en authentification indirecte ou par CPE (qui ne donne pas
accès à la consultation) ou en authentification directe sans l’accès à la consultation.
Ⓔ
Une disposition spécifique permet de rechercher l’entryUUID d’un document avec la TD3.1
pour pouvoir ensuite le supprimer (voir « Etape 1 » dans le § 9.2).
1. l’utilisateur sélectionne en local dans le LPS le document à mettre à jour et
confirme la demande de suppression
2. le LPS récupère la référence entryUUID du document dans la Registry XDS du SI
DMP, à partir du uniqueId du document : utilisation de la requête stockées
GetDocuments (voir [IHE-TF2A] § 3.18.4.1.2.3.7.5 GetDocuments, en ObjectRef
requise)
3. le LPS envoie une requête XDS de mise à jour de métadonnée.
209 / 254
Lors de l’affichage des informations ci-dessus, le positionnement des boutons radios doit
refléter l’état actuel du document en cours de modification.
10.3.3
Transaction
La transaction utilisée est décrite dans [CI-PARTAGE] § 3.3.5 et les détails techniques
d’implémentation de cette transaction sont décrits dans [IHE-MU] (IHE ITI-57 Update
Document Set).
La mise à jour de métadonnée se fait directement sur la Registry XDS.b.
Les données en entrée diffèrent en fonction de l’action à réaliser :

Masquer / démasquer un document aux PS (TD3.3a) :
o la transaction est décrite dans ITI-57 § 3.57.4.1.3.3.1 Update DocumentEntry
Metadata ;
o toutes les métadonnées du document doivent être renvoyées à la Registry ;
o la métadonnée confidentialityCode :
 dans le cas du masquage aux PS, cette métadonnée doit contenir la
valeur : MASQUE_PS dans la nomenclature d’OID 1.2.250.1.213.1.1.4.13
 dans le cas du démasquage, la valeur correspondant au masquage à un
PS doit être retirée du champ.
 les deux valeurs « masqué au PS » et « invisible au patient » ne sont pas
possible simultanément.
o d’autres données en entrée sont spécifiées au chapitre « Update DocumentEntry
Metadata ».

Rendre un document visible au patient (TD3.3b) :
o la transaction est décrite dans ITI-57 § 3.57.4.1.3.3.1 Update DocumentEntry
Metadata ;
o toutes les métadonnées du document doivent être renvoyées à la Registry ;
o la métadonnée confidentialityCode :
 lorsque le document n’est pas visible du patient, cette métadonnée
contient la valeur : INVISIBLE_PATIENT dans la nomenclature d’OID
1.2.250.1.213.1.1.4.13 ;
 pour rendre un document visible au patient, la valeur correspondant à
l’invisibilité au patient doit être retirée des métadonnées XDS.
 les deux valeurs « masqué au PS » et « invisible au patient » ne sont pas
possible simultanément.
o d’autres données en entrée sont spécifiées au chapitre « Update DocumentEntry
Metadata ».
210 / 254
Limitation de la suppression en authentification indirecte ou par CPE (qui ne donne pas
accès à la consultation) ou en authentification directe sans accès à la consultation :
Un document qui aurait été archivé ou remplacé ne peut pas être supprimé en
authentification indirecte ou par CPE. En effet, la fonction GetDocuments en ObjectRef ne
retourne que les entryUUID de document au statut "Approved" (sinon le LPS récupérerai les
références entryUUID de toutes les versions de métadonnées éventuelles d'un même
document, sans pour autant pouvoir discriminer la version au statut "Approved", ce champ
n'étant pas retourné en mode ObjectRef).
Archiver / désarchiver un document (TD3.3d) :
o les données à envoyer sont décrites dans ITI-57 § 3.57.4.1.3.3.2 « Update
DocumentEntry AvailabilityStatus » ;
o pour archiver un document, la transaction doit envoyer la valeur « urn:asip:cisis:2010:StatusType:Archived » dans l’association « UpdateAvailabilityStatus »
pour mettre à jour le champ availabilityStatus du document ;
o Pour désarchiver un document, la transaction doit envoyer la valeur
« urn:oasis:names:tc:ebxml-regrep:StatusType:Approved » dans l’association
« UpdateAvailabilityStatus » pour mettre à jour le champ availabilityStatus
du document.
La notion « d’archivage » d’un document est une notion d’archivage fonctionnelle pour le PS
qui ne souhaite plus visualiser des documents qui ne sont plus utiles dans sa pratique
médicale courante, et non d'un archivage "technique" au niveau du repository XDS : la
métadonnée documentAvailability (décrite dans le supplément XDS MetadataUpdate) ne
rentre pas en ligne de compte pour l’archivage de document dans le DMP ;
Si dans le DMP il existe un document avec une version en cours active (statut « Approved »)
et des versions antérieures au statut « Deprecated », l'archivage de la version en cours du
document n’est pas propagé aux versions antérieures du document. La version du document
avec le statut « Approved » passe alors à l'état « Archived » mais les versions antérieures
restent au statut « Deprecated ».

Supprimer un document (TD3.3c) :
o les données à envoyer sont décrites dans ITI-57 § 3.57.4.1.3.3.2 « Update
DocumentEntry AvailabilityStatus » ;
o la transaction doit envoyer la valeur « urn:asip:ci-sis:2010:StatusType:Deleted »
dans l’association « UpdateAvailabilityStatus » pour mettre à jour le champ
availabilityStatus du document.
En cas de succès de la mise à jour, la registry retourne
status=urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success.
un
code
En cas d’erreur, la registry retourne un code status=urn:oasis:names:tc:ebxmlregrep:ResponseStatusType:Failure, conformément au profil XDS.b, ainsi qu’un code
d’erreur et éventuellement un message de détail. Le retour d’erreur est détaillé dans [IHETF3] § 4.1.13.
Voir également l’annexe sur les codes erreurs au § 11.4.
211 / 254

11 Annexes
11.1 Documents externes
N°
Documents applicables
Référence
Document
Documents du Cadre d’interopérabilité des Systèmes d’Information de Santé (CI-SIS)
(Documents accessibles sur le site de l’ASIP Santé http://esante.gouv.fr/)
Version 1.0.1
DA1
CI-CHAP
Document Chapeau du CI-SIS et Note de version
CI-SIS_Document_Chapeau_v1.0.1.pdf
Ce document est le chapitre introductif du Cadre d’Interopérabilité des
Systèmes d’Information de Santé (SIS). Il présente :
- La définition et le périmètre du cadre d’interopérabilité des SIS, ainsi
que sa structure modulaire sous forme de volets ;
- la structure générique d’un volet du cadre d’interopérabilité des SIS ;
- les règles de nommage d’un volet ;
- la trajectoire de ce référentiel ;
- une cartographie des volets disponibles dans la version initiale, et de
ceux qui viendront compléter le référentiel dans les versions
suivantes.
- Le glossaire des acronymes utilisés dans le référentiel
DA2
CIGESTPAT
Couche Service - Volet Gestion de dossier patient partagé
CI-SIS_Couche_Service_Volet_Gestion_Dossier_Patient_Partagé_v1.0.1.pdf
Ce volet spécifie la couche Service pour :
- un « système cible dossier » stockant, indexant et mettant à
disposition des documents de santé à caractère personnel sous forme
de dossier patient ;
- un « système initiateur » qui effectue les opérations d’ouverture et les
éventuelles opérations de modifications de données d'identification et
de fermeture des dossiers patients ;
- un « système cible identifiant » fournissant en période transitoire les
identifiants nécessaires à l’identification des patients pour l’ouverture,
l’alimentation et la consultation de dossier.
DA3
CIPARTAGE
Couche Service - Volet Partage de Documents de Santé
CI-SIS_Couche_Service_Volet_ Partage_Documents_Santé_v1.0.1. pdf
Ce volet spécifie la couche Service pour :
- un système cible stockant, indexant et mettant à disposition des
documents de santé à caractère personnel ;
- un système initiateur qui fournit des documents à un système cible, en
création comme en mise à jour ;
- un système initiateur qui accède à ces documents (recherche et
extraction) en s'adressant à un système cible.
212 / 254
11 Annexes
11.1.1
N°
Référence
Document
Version 1.0.1
DA4
Couche Service - Volet Partage de Documents de Santé, version 1.3
CIPARTAGE- CI-SIS_SERVICE_VOLET-PARTAGE-DOCUMENTS-SANTE_V1.3.1.pdf
1.3
Ce volet est la version plus récente de CI-PARTAGE, qui précise les valeurs
de certains champs (mimeType, size et hash) pour les documents au format
« CDA auto-présentable ».
CI-TR-CLILRD
Couche Transport - Volet Synchrone pour Client Lourd
CI-SIS_couche_Transport_Volet_Synchrone_client_lourd_v1.0.1.pdf
Ce volet spécifie la couche Transport pour :
- un système cible offrant un service auquel il est possible de se
connecter de façon synchrone ;
- un système initiateur bénéficiant d’un « client lourd » (c.à.d. un logiciel
spécialisé intégrant les interfaces décrites dans ce volet) se
connectant au service de façon synchrone.
DA6
CI-STRUENTETE
Couche Contenu - Volet Structuration Minimale de Documents Médicaux
CI-SIS_couche_Contenu_Volet_Structuration_Minimale_v1.0.1.0.pdf
Ce volet fait partie de la couche « Contenu » du CI-SIS.
Il spécifie la structuration minimale des documents médicaux persistants
partagés ou échangés dans ce contexte.
DA7
CI-STRUENTETE1.3
Couche Contenu - Volet Structuration Minimale de Documents Médicaux,
version 1.3.1
CI-SIS_CONTENU_VOLET-STRUCTURATION-MINIMALE_V1.3.1.1.pdf
Ce volet est la version plus récente de CI-STRU-ENTETE, qui introduit la
notion de CDA auto-présentable.
DA8
DA9
CI-ANXCDA
Annexe : Liens entre métadonnées et entête CDA
CI-ANXMHAB
Annexe : Matrice d'habilitations des professionnels de santé
CI-SIS_Annexes_Liens_entête_CDA_Métadonnées_v1.0.1.0.pdf
CI-SIS_ Matrice_Habilitations_PS_lecture.pdf (version 1.3.0)
Cette matrice définie les conditions d'accès en lecture aux types de
documents selon la profession ou la discipline.
DA10
CI-ANXNOMENCDOC
Annexe : Nomenclatures de Métadonnées Documents
CI-SIS_Annexes_Nomenclatures_Métadonnées_Documents_v1.0.1.pdf
Nomenclatures des métadonnées des Documents utilisées dans le cadre
d'interopérabilité.
DA11
CI-ANX-PSSTRU
Annexe : Sources des données métier pour les personnes et les
structures
CI-SIS_Annexe_Sources_Donnees_Personnes_et_Structures_v1.0.1.pdf
Annexe transversale du CI-SIS décrivant les données caractérisant les
professionnels et les structures de santé. Fournit également les règles de
renseignement ou de vérification de ces données provenant, pour certaines,
de jeux de valeurs.
213 / 254
11 Annexes
DA5
N°
Référence
Document
Version 1.0.1
DA12
CI-ANX-HL7 Annexe : Nomenclatures de codes HL7 V3
CI-SIS_Annexes_Nomenclatures_Message_HL7_v1.0.1.pdf
Nomenclatures utilisées dans les messages HL7 V3
DA13
Annexe : jeux de valeurs
CI-JEUXVALEURS
Fichiers contenant les jeux de valeurs des nomenclatures publiées par l’ASIP
Santé dans le CI-SIS, exploitables directement par les LPS.
DA14
Tables de transcodages des savoir-faire et secteurs d’activités ADELI
vers RPPS
TRANSADELIRPPS
Fichiers inclus dans Transco_ADELI_RPPS_20120412.zip :


N°
ASIP-SANTE_X01_20120412.tab : transcodages savoir-faire
ASIP-SANTE_X02_20120412.tab : transcodages secteur d’activité
Référence
Document
Dossier de conception Identifiant National de Santé INS-C
(Documents accessibles sur le site de l’ASIP Santé)
DA15
INSC-DOSS Dossier de conception
ASIP_ ProgrammeINS_Dossier_de_conception_INS-C_v1.0.0.pdf
Algorithme de calcul de l’INS-C
ASIP_ ProgrammeINS_Dossier_de_conception_INS-C_Algorithme de
calcul_v1.0.0.pdf
Echantillon de test
ASIP_ ProgrammeINS_Dossier_de_conception_INS-C_Echantillon_de_test_v1.0.0.pdf
ASIP_ ProgrammeINS_Dossier_de_conception_INS-C_Echantillon_de_test_v1.0.0.xls
Exemples de code pour calculer l’INS-C
ASIP_ ProgrammeINS_Dossier_de_conception_INS-C_Exemples_de code_v1.0.0.pdf
Lecture des données de calcul de l’INS-C
ASIP_ProgrammeINS_Dossier_de_conception_INSC_lecture_des_donnees_v1.0.0.pdf
Tableau 81 : Liste des documents applicables
214 / 254
11 Annexes
CI-SIS_Jeux_de_valeurs.zip
11.1.2
N°
Documents de référence
Référence
Document
Documentation IHE / HL7 France
Spécifications internationale sur http://www.ihe.net/Technical_Framework/index.cfm#IT
(cadre technique ITI)
DR1
IHE-TF1
Profils d’intégration IHE
IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1) –
http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Rev70_Vol1_FT_2010-08-10.pdf
IHE-TF2A
Transactions – Partie I
11 Annexes
DR2
IHE IT Infrastructure Technical Framework, Volume 2a (ITI TF-2a) –
http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Rev70_Vol2a_FT_2010-08-10.pdf
DR3
IHE-TF2B
Transactions IHE – Partie II
IHE IT Infrastructure Technical Framework, Volume 2b (ITI TF-2b) http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Rev70_Vol2b_FT_2010-08-10.pdf
DR4
IHE-TF3
Définition IHE des métadonnées XDS
IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3) http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Rev70_Vol3_FT_2010-08-10.pdf
DR5
IHE-PDQV3
Recherche de patient (patient Demographic Query)
http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Suppl_PIX_PDQ_HL7v3_R
ev2-1_TI_2010-08-10.pdf
DR6
IHE-DSG
Signature électronique pour le profil XDS
http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Supplement_Digital_S
ignature-2009-08-10.pdf
DR7
IHE-MU
Mise à jour de métadonnées XDS (supplément 2010)
http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Suppl_XDS_Metadata_U
pdate_Rev1-1_TI_2010-08-10.pdf
Documentation IHE / HL7 France
Extension nationale française en libre accès sur le site d'Interopsanté
DR8
IHE-PAMFR
Gestion administrative
mouvements, séjours …)
des
patients
(flux
de
gestion
d’identité,
http://www.interopsante.org/412_p_15688/documents-publics-de-reference.html
Contraintes applicables au profil d’intégration « Patient Administration
Management » (PAM) du cadre technique IT Infrastructure dans le périmètre
d’IHE France Version 2.4 (22/02/2012)
Contraintes sur les types de données HL7 v2.5 applicables aux profils
d’intégration du cadre technique IT Infrastructure dans le périmètre d’IHE
France Version 1.4 (22/02/2012)
Tableau 82 : liste des documents de référence
215 / 254
11.1.3
N°
DX2
DX3
Annexes externes
Référence
DMP1-OSNAVIGATE
URS
Document
Liste des configurations compatibles avec le DMP
http://www.dmp.gouv.fr/documentation/matrice-compatibilite-os_navigateur
ARCHI-DMP Architectures systèmes éligibles aux échanges avec le DMP
http://esante.gouv.fr/services/referentiels/architecture-et-urbanisation/referentielsd-architecture-et-d-urbanisation
PDVHOMOLOG
ATION
Plan de Vérification de l’homologation à la DMP Compatibilité
Version en vigueur disponible sur demande auprès de l’ASIP Santé.
Envoyé au candidat à la DMP Compatibilité dès la signature du contrat
éditeur.
DX6
Charte graphique à destination des éditeurs de logiciels DMPCHARTEDOC_SECR compatibles.
ETS
http://www.esante.gouv.fr/sites/default/files/DMP1_LPS_TEC_DSFT_Annexe_Princip
e_d_elaboration_du_document_des_secrets_DMP_130605.pdf
DX7
DMP1-ANX- Description détaillée du processus d’homologation à la DMP
Compatibilité et conditions d’accès à l’assistance technique optionnelle
HOM
évoquée à l’article 6.3 du contrat
http://www.esante.gouv.fr/sites/default/files/DMP1_LPS_FON_DSFT%20des%20inte
rfaces%20LPS_Annexe_Processus%20d'homologation_20130925_v1.0.0.pdf
DX8
DX9
GUIDEARR-CPS
Guide d’implémentation de la détection de l’arrachage de la carte CPS
http://integrateurs-cps.asipsante.fr/documents/Guide-impl-arrachage-CPS
GUIDE-CRL Guide de bonnes pratiques d’utilisation des listes de révocation des
certificats
http://esante.gouv.fr/sites/default/files/Guide_bonnes_pratiques_CRL.pdf
Tableau 83 : liste des annexes externes
216 / 254
11 Annexes
DX5
11.2 Terminologie et acronymes
Ce paragraphe a pour objectif de préciser la signification des termes et abréviations
spécifiques au système et utilisées dans ce document.
AC
ADELI
AFNOR
AS
ASIP
CDA
CI-SIS
CNDA
CPA
CPE
CPS
CRL
CV
DMP
DN
DPI
DRASS
EAI
ES
GAM
FINESS
HL7
IHE
IGC
INS
JVM
LDRM
LGC
LGO
LPS
MT
OID
OTP
PARM
PDQ
PS
RMESS
RIS/PACS
RNR
SAML
RPPS
SAMU
SGL
SI
SIH
Signification
Autorité de Certification
Automatisation des Listes (répertoire de professionnels de santé en cours de
remplacement par le RPPS)
Agence Française de Normalisation
Acteur de Santé au sens large (PS ou STS)
Agence des Systèmes d’Information Partagés (cf. ASIP Santé)
Clinical Document Architecture
Cadre d’interopérabilité des Systèmes d’Information de Santé de l’ASIP Santé
Centre National de Dépôt et d’Agrément
Carte de Personnel Autorisé
Carte de Professionnel d’Etablissement
Carte de Professionnel de Santé
Certificate Revocation List = liste de révocation des certificats, publiée par l’ASIP Santé.
Carte Vitale
Dossier Médical Personnel
Distinguished Name
Dossier Patient Informatisé
Direction Régionale des Affaires Sanitaires et Sociales
Enterprise Application Integration
Etablissement de santé : terme recouvrant les structures de soins publics et privés,
incluant les plateaux techniques en ville et en hôpital
Gestion Administrative des Malades
Fichier National des Etablissements Sanitaires et Sociaux
Health Level 7
Integrating the Healthcare Enterprise
Infrastructure de Gestion de Clés
Identifiant National de Santé
Java Virtual Machine
Logiciel De Régulation Médicale
Logiciel de Gestion de Cabinet
Logiciel de Gestion d’Officine
Logiciel de Professionnel de Santé (abréviation générique désignant une application
utilisée par un professionnel de santé, dans ou hors structure de soins)
Médecin traitant
Object Identifier (identifiant d’objets)
One Time Password = code d’accès à usage unique
Permanencier Auxiliaire de Régulation Médicale
Patient Demographic Query
Professionnel de Santé – Acteur de Santé humain
Répertoire Mutualisé des Entités Sanitaires et Sociales (qui succèdera à FINESS)
Système d’Information Radiologique
Répertoire National des Référentiels
Security Assertion Markup Language
Répertoire Partagé des Professionnels de Santé
Service d'Aide Médicale Urgente
Système de Gestion de Laboratoire
Système d’Information
Système d’Information Hospitalier
217 / 254
11 Annexes
Abrev.
SIS
SOAP
SSL
STS
TLS
UTC
VIHF
XDS
Système d’Information de Santé
Simple Object Access Protocol
Secure Sockets Layer
Structure de soins : établissements de santé, structures médico-sociales, centres de
santé et toute autre structure susceptible de créer/alimenter le DMP en authentification
indirecte avec un certificat serveur de personne morale.
Transport Layer Security
Universal Coordinated Time
Vecteur d’Identification et d'Habilitation Formelles
Cross enterprise Document Sharing
11 Annexes
Tableau 84 : Liste des abréviations
218 / 254
11.3 WSDL des services
TD0.2
Test d'existence d'un DMP et vérification de l'autorisation
TD0.3
TD0.4
TD0.5
Recherche de patient sur le DMP sans INS
TD0.9
Accès Web-PS contextuel
TD1.1
Création d'un DMP
TD1.2
TD1.3
TD1.3a
Consultation des données administratives
TD1.3b
Mise à jour des données administratives
TD1.4
Fermeture d'un DMP
TD1.5
TD1.5a
Initialisation de l'accès internet patient
TD1.5b
Ajout d'un canal OTP au compte d'accès internet patient
TD1.5d
Mise à jour du compte Internet patient
TD1.6
ALIMENTATION DU DMP
TD2.1
Alimentation du DMP d’un patient
TD2.2
Alimentation du DMP d’un patient par CPE
CONSULTATION DU DMP
TD3.1
Recherche de document sur le DMP d’un patient
TD3.2
Consultation d’un document sur le DMP d’un patient
TD3.3a
Masquage / démasquage d'un document sur le DMP d'un patient
TD3.3b
Visibilité d'un document au patient sur le DMP d'un patient
TD3.3c
Dé-publication d'un document sur le DMP d'un patient
TD3.3d
Archivage/désarchivage d'un document sur le DMP d'un patient
Standard Operation
URL WebService (1)
WSDL
HL7-V3
(ws)
(ws)
IHE-PDQ
n/a
/si-dmp-server/v1/services/patients
/si-dmp-server/v1/services/habilitations
/si-dmp-server/v1/services/patientsSpecific
/si-dmp-server/v1/services/patientsPDQ
n/a
GestionDossierPatientPartage.wsdl
habilitations.wsdl
patientSpecific.wsdl
PDQSupplier.wsdl
n/a
PatientAdd_PRPA_IN201311UV02
PatientRevise_PRPA_IN201314UV02
PatientGetDemographics_PRPA_IN201307UV02
createPatientAccess
patientOTPUpdate
updatePatientAccess
listAuthorizationByPatient
/si-dmp-server/v1/services/habilitations
habilitations.wsdl
DocumentRepository_ProvideAndRegisterDocumentSet-b
/si-dmp-server/v1/services/repository
/si-dmp-server/v1/services/repositoryCPE
XDS.b_DocumentRepository.wsdl
DocumentRegistry_RegistryStoredQuery
DocumentRepository_RetrieveDocumentSet
DocumentRegistry_UpdateDocumentSet
/si-dmp-server/v1/services/registry
/si-dmp-server/v1/services/repository
XDS.b_DocumentRegistry.wsdl
HL7-V3
(ws)
(ws)
IHE
XDS-b
setAutorization
patientList
PDSupplier_PRPA_IN201305UV02
(1) suffixe d'URL relative par rapport au nom de domaine du serveur
Tableau 85 : WSDL des services
219 / 254
11.4 Codes d’erreurs
11.4.1
Liste des codes d’erreurs
Libellé de l'erreur
DMPOk
(Pas d'erreur)
DMPSystemError
Erreur système
DMPFound
Le DMP existe déjà
DMPPatientNotFound
Patient inconnu (DMP non trouvé)
DMPClosed
DMP fermé
DMPLPSNotValidated
LPS en cours de validation
DMPErrorLPS
Le LPS n’a pas accès à ce service
DMPAccessForbidden
Accès interdit (le PS a été interdit d'accès par le patient)
DMPAuthorizationNotFound
Le PS n'a pas l'autorisation d'accès à ce DMP
DMPAuthorizationExpired
Autorisation d'accès expirée
DMPAccessDeniedByRightsService
Accès refusé par la matrice de droits fonctionnels
DMPInvalidData
Données non conformes au regard des règles de gestion
DMPInvalidRequest
Requête invalide au regard de la norme spécifiée
DMPConcurrentAccess
Accès concurrent sur une métadonnée
DMPInvalidSignature
Signature non valide
DMPInvalidCertificate
Certificat non valide
DMPVirusFound
Virus détecté
DMPDataAlreadyUsed
Données déjà utilisées
DMPOutOfExperimentalArea
DMP hors région expérimentale
DMPBadPassword
Mauvais mot de passe
DMPDeleteError
Suppression impossible
DMPTooManyResult
Trop de résultats, l'utilisateur doit affiner sa recherche
DMPActorNotFound
Acteur non trouvé
DMPDocumentFormatError
Le document n'est pas au bon format (CDA R2)
DMPPatientAccessNotFound
Acces patient pour le DMP non trouvé
DMPPatientAccessAlreadyExists
Acces patient déjà existant pour le DMP
DMPPatientAccessOTPNotFound
Pas de canal OTP configuré pour le DMP
DMPPatientAccessOTPAlreadyExists
Canal OTP du même type déjà créé pour le DMP
DMPPatientAccessOTPDeleteForbidden
Interdiction de supprimer le canal OTP
XDSMissingDocument
Le document n'existe plus ou n'est plus disponible.
XDSMissingDocumentMetadata
Métadonnées manquantes pour un document
XDSRegistryNotAvailable
Registry inaccessible
XDSRegistryError
Erreur interne au registre.
XDSRepositoryError
Erreur interne au dépôt.
Un identifiant unique est utilisé plusieurs fois au sein de la
requête
Un identifiant unique est utilisé plusieurs fois au sein de la
requête
XDSRegistryDuplicateUniqueIdInMessage
XDSRepositoryDuplicateUniqueIdInMessa
ge
11 Annexes
Code erreur
220 / 254
XDSRegistryBusy
n identifiant unique est déjà utilisé
Le hash d'un document envoyé ne correspond pas à celui reçu
dans les métadonnées
Registre occupé
XDSRepositoryBusy
Dépôt occupé
XDSRegistryOutOfResources
Le registre n'a plus assez de ressources
XDSRepositoryOutOfResources
Le dépôt n'a plus assez de ressources.
XDSRegistryMetadataError
Erreur dans les métadonnées
XDSReplaceFailed
Remplacement de document impossible
XDSRepositoryMetadataError
Erreur dans les métadonnées
XDSTooManyResults
Trop de résultats
XDSExtraMetadataNotSaved
Métadonnées inconnues non sauvegardées
XDSUnknownPatientId
Patient inconnu
XDSPatientIdDoesNotMatch
Des identifiants patients différent au sein de la requête
XDSUnknownStoredQuery
Identifiant de requête inconnu
XDSStoredQueryMissingParam
Un paramètre obligatoire est manquant
XDSStoredQueryParamNumber
Plusieurs valeurs affectées à un paramètre mono valué
XDSRegistryDeprecatedDocumentError
Un document référencé est déprécié
XDSUnknownRepositoryId
Identifiant de dépôt inconnu
XDSDocumentUniqueIdError
Document indisponible
XDSResultNotSinglePatient
code XDS non utilisé
PartialFolderContentNotProcessed
PartialReplaceContentNotProcessed
XDSMetadataUpdateError
Erreur lors de la mise à jour de métadonnées
XDSMetadataUpdateOperationError
Erreur de décodage de la requête
XDSMetadataVersionError
Erreur de version de document à mettre à jour
UnresolvedReferenceException
Métadonnées de document inexistantes
ReferencesExistException
Les métadonnées sont référencées par une association
XDSNonIdenticalHash
11 Annexes
XDSDuplicateUniqueIdInRegistry
Tableau 86 : Tableau des codes d’erreur et signification
221 / 254
Le tableau suivant liste les codes d’erreur par transaction.
TD1.6
TD0.3
TD1.1
TD1.3b
TD1.3a
TD0.5
TD0.4
TD0.2
TD1.4
TD1.2
TD1.5a
TD1.5d
TD1.5b
TD3.3
TD3.1
TD2.1
TD3.2
DMPOk
N
Y
Y
Y
Y
Y
N
Y
Y
Y
N
N
N
Y
Y
N
N
DMPSys temError
N
Y
N
N
N
N
N
N
N
N
N
N
N
Y
Y
N
N
DMPPa ti entNotFound
N
Y
Y
N
N
Y
N
N
N
N
N
Y
N
N
DMPCl os ed
N
Y
N
N
N
Y
N
N
N
N
N
N
N
N
N
DMPLPSNotVa l i da ted
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
DMPErrorLPS
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
DMPAcces s Forbi dden
Y
Y
Y
Y
Y
N
Y
Y
Y
Y
Y
N
N
N
N
DMPAuthori za ti onNotFound
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
DMPAuthori za ti onExpi red
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
DMPAcces s Deni edByRi ghts Servi ce
Y
Y
Y
Y
Y
Y
Y
Y
Y
DMPInva l i dDa ta
Y
Y
N
N
N
Y
Y
N
N
N
N
N
N
N
N
N
N
N
Code erreur
DMPFound
Y
DMPInva l i dReques t
N
N
N
DMPConcurrentAcces s
Y
Y
Y
Y
N
N
N
N
N
Y
DMPInva l i dSi gna ture
DMPInva l i dCerti fi ca te
N
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
DMPVi rus Found
DMPDa ta Al rea dyUs ed
N
N
N
Y
Y
N
N
Y
Y
N
DMPOutOfExperi menta l Area
N
N
N
DMPBa dPa s s word
DMPDel eteError
DMPTooMa nyRes ul t
DMPActorNotFound
N
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
DMPDocumentForma tError
N
DMPPa ti entAcces s NotFound
Y
DMPPa ti entAcces s Al rea dyExi s ts
N
N
N
DMPPa ti entAcces s OTPNotFound
N
DMPPa ti entAcces s OTPAl rea dyExi s ts
N
DMPPa ti entAcces s OTPDel eteForbi dden
N
XDSMi s s i ngDocument
N
XDSMi s s i ngDocumentMeta da ta
N
XDSRegi s tryNotAva i l a bl e
N
XDSRegi s tryError
N
N
N
N
XDSRepos i toryError
N
N
XDSRegi s tryDupl i ca teUni queIdInMes s a ge
N
XDSRepos i toryDupl i ca teUni queIdInMes s a ge
N
XDSDupl i ca teUni queIdInRegi s try
N
XDSNonIdenti ca l Ha s h
N
XDSRegi s tryBus y
N
N
XDSRepos i toryBus y
XDSRegi s tryOutOfRes ources
N
N
XDSRepos i toryOutOfRes ources
XDSRegi s tryMeta da ta Error
N
N
N
N
N
N
N
N
N
N
XDSRepl a ceFa i l ed
N
XDSRepos i toryMeta da ta Error
N
XDSTooMa nyRes ul ts
N
XDSExtra Meta da ta NotSa ved
N
XDSUnknownPa ti entId
N
XDSPa ti entIdDoes NotMa tch
N
N
N
N
XDSUnknownStoredQuery
N
XDSStoredQueryMi s s i ngPa ra m
N
XDSStoredQueryPa ra mNumber
N
XDSRegi s tryDepreca tedDocumentError
N
N
XDSUnknownRepos i toryId
N
XDSDocumentUni queIdError
N
XDSResultNotSinglePatient
PartialFolderContentNotProcessed
PartialReplaceContentNotProcessed
XDSMeta da ta Upda teError
N
XDSMeta da ta Upda teOpera ti onError
N
XDSMeta da ta Vers i onError
N
Unres ol vedReferenceExcepti on
N
References Exi s tExcepti on
N
Tableau 87 : Tableau des codes erreur par transactions
222 / 254
11 Annexes
DocumentRepository_RetrieveDocumentSet
TD3.2 - Consultation d'un document sur un DMP
TD2.1 - Alimentation en documents d'un DMP
DocumentRegistry_RegistryStoredQuery
TD3.1 - Recherche de documents sur le DMP
TD3.3 - Gestion des attributs d'un document
patientOTPUpdate
TD1.5b Ajout d'un canal OTP au compte d'accès internet
updatePatientAccess
TD1.5d Mise à jour des informations du compte Internet
createPatientAccess
TD1.5a Initialisation de l'accès internet du patient
TD1.2 Réactivation d'un DMP
TD1.4 Fermeture d'un DMP
TD0.2 Test d'existence d'un DMP et vérification de
l'autorisation
PatientList
TD0.4 Liste des DMP autorisés pour un A.S
PDSupplier_PRPA_IN201305UV02
TD0.5 : Recherche de patient sur le DMP sans INS
TD1.3a Consultation des données administratives
TD1.3 Mise à jour des données administratives d'un DMP
PatientAdd_PRPA_IN201311UV02
TD1.1 Création d'un DMP
setAutorization
TD0.3 Mise à jour de l'autorisation
N=code na ti f de l a foncti on
Y=code retourné pa r a ppel i nterne d'une
a utre foncti on
listAuthorizationByPatient
TD1.6 Liste des PS autorisés/interdits sur un DMP
L’éditeur doit prendre en compte les codes erreurs signalés par Y et N :
11.4.2
Erreurs spécifiques du processus d’authentification (« SOAP
Fault »)
Le processus d’authentification sur le SI DMP peut entrainer des retours d’erreur de
« premier niveau » de type « SOAP Fault ».
Le tableau ci-dessous fourni les cas d’erreur fréquemment rencontrés lors de la mise au
point du LPS (phase de développement) :
Cause
Le format du champ NameID ne se conforme pas aux règles définies
pour le VIHF (voir § 7.2.3).
Comme défini dans le CI-SIS v1.0.1, en authentification indirecte il y a
une codification spécifique du premier chiffre de l'identifiant de la
personne connectée (champ VIHF /Assertion/Subject/NameID) à
effectuer en fonction du type d'identifiant de la structure (champ VIHF
Identifiant_structure).
Voir
le
document
CISIS_Annexe_Sources_Donnees_Personnes_et_Structures_v1.0.1.pdf
qui donne les règles de codification du premier chiffre de chaque
identifiant (§ 5.4 PS_IdNat pour NameID et § 5.5 Struct_IdNat pour
Identifiant_structure).
DMPInvalidData : xxxxxx :
Structure introuvable
Profession non correspondante
Attention : si le candidat utilise un certificat de test contenant son
identifiant SIRET pour ses développements, le certificat de production
d'un établissement contient en général un FINESS (premier chiffre
différent), et il faut donc prendre en compte ces règles correctement.
La structure liée au certificat n’est pas présente dans l’annuaire
interne du SI DMP.
En phase de développement, il se peut que l’annuaire de
l’environnement de développement du candidat ne soit pas à jour. Le
candidat peut vérifier la date du certificat utilisé en allant sur le site
http://annuaire.gip-cps.fr en recherchant la structure par son numéro
(prendre la branche de test s’il s’agit d’une structure de test) et en
cliquant sur le lien figurant dans liste affichée.
En authentification directe, ce message d'erreur est remonté par le
DMP lorsque la profession fournie dans le VIHF n'est pas renseignée
correctement par rapport à la carte CPS utilisée (données de
l’annuaire ASIP-CPS).
Afin de renseigner correctement les différents champs du VIHF,
l'éditeur doit consulter les documents suivants :



Le présent DSFT,
CI-SIS_Couche_Transport_Volet_Synchrone_client_lourd_v1.0.1.pdf,
CI-SIS_Annexe_Sources_Donnees_Personnes_et_Structures_v1.0.1.pdf.
Certaines données doivent notamment être lues dans la carte CPS en
authentification directe. Les données des cartes CPS sont vérifiées
par le serveur DMP via l'annuaire ASIP-CPS.
aucune spécialité pour médecin
Cette erreur est remontée lorsque le champ spécialité du médecin
n'est pas fourni par le LPS. Pour les médecins et les pharmaciens, le
LPS doit fournir un second champ "role" (attribut SAML de nom
"urn:oasis:names:tc:xacml:2.0:subject:role") dans le VIHF comportant
la spécialité du PS connecté, en respectant la nomenclature des
"savoir faire RPPS". Il existe une particularité pour le transcodage du
code « spécialité ADELI » (lu dans la carte) vers le code « savoir faire
RPPS » (requis par le DMP)
223 / 254
11 Annexes
Message d’erreur type
retourné
DMPInvalidData;Le sujet de
l'assertion
(1234567890/013122) n'est pas
un descendant de l'identifiant de
structure du certificat :
1234567890
DMPInvalidData : Le PS n'a pas
les droits d'accéder à ce dossier
: PS et Structure non lies
En authentification directe, cette erreur est remontée lorsque le
champ Identifiant_Structure du VIHF n'est pas renseigné
correctement par rapport à la carte CPS utilisée (cohérence entre les
données de la carte et les données fournies dans le VIHF).
Afin de renseigner correctement les différents champs du VIHF,
l'éditeur doit consulter les documents suivants :



Le présent DSFT,
CI-SIS_Couche_Transport_Volet_Synchrone_client_lourd_v1.0.1.pdf,
CI-SIS_Annexe_Sources_Donnees_Personnes_et_Structures_v1.0.1.pdf.
DMPInvalidCertificate;Le
certificat ayant signé le VIHF
est invalide : Not a valid
signature certificate
Les données des cartes CPS sont vérifiées par le serveur DMP via
l'annuaire ASIP-CPS.
Il faut vérifier :

que le certificat ayant signé le VIHF est bien un certificat
CLASSE-4 (CLASSE-4-TEST pour les environnements de
tests) émis par l’IGC CPS, non révoqué et valide (date de
validité),
 que le certificat est bien un certificat de signature (la signature
du VIHF avec un certificat d'authentification n'est pas
autorisée)
Pour le vérifier, voici les différences entre les deux types de certificats
(usage du "keyUsage") :


Authentification : il faut avoir digitalSignature
Signature : il faut avoir nonREpudiation et digitalSignature
Les certificats fournis par l’ASIP Santé (branche CPS) :

SSL (authentification client/serveur) :
NetscapeCertType [
SSL client
SSL server
]
KeyUsage [
DigitalSignature
Key_Encipherment
]
 S/MIME (signature) :
NetscapeCertType [
S/MIME
]
KeyUsage [
DigitalSignature
Non_repudiation
Key_Encipherment
]
Secteur
d'activité
correspondant
non
Deux raisons possibles à cette erreur :


soit le champ Secteur_Activite du VIHF ne correspond pas à la
carte ou au certificat utilisé pour l'authentification,
soit le champ Identifiant_Structure du VIHF ne correspond pas à
la carte ou au certificat utilisé pour l'authentification (et par
extension le secteur d'activité ne correspond pas à cette
structure).
224 / 254
11 Annexes
Certaines données doivent notamment être lues dans la carte CPS en
authentification directe.
Dans le cas où le candidat utilise le code exemple, il doit l’adapter à
son usage et plus particulièrement dynamiser les champs liés au
contexte de ses utilisateurs (le secteur d'activité en est un) ; dans le
code exemple en Java, le secteur d'activité est codé dans la classe
com.dmp.security.vihf.handlers.VIHFClientHandler et dans les classes
du package com.dmp.kit_editeur.vihf (selon que le VIHF est signé ou
non).
11 Annexes
Le candidat doit envoyer dans le VIHF les données associées à la
structure représentée par le certificat présenté.
225 / 254
11.4.3
Erreurs fréquentes liées aux transactions XDS
(TD2.1 / TD2.2 / TD3.3 /
TD3.1)
Le tableau ci-dessous fourni les cas d’erreur fréquemment rencontrés lors de la mise au
point du LPS (phase de développement), pour les transactions d’alimentation :
DMPDocumentFormatError
codeContext : entryUUID=document01;
CDA incorrect.
RegistryResponse = "Failure" sans
autre code d'erreur
Cette erreur est remontée du serveur DMP lorsque le
document CDA n'est pas conforme au schéma XSD de
CDA (i.e. la validation du document par rapport au schéma
« CDA.xsd » a retourné une non-conformité).
Ce problème survient lorsque plusieurs documents au sein
de
la
même
requête
XDS
ProvideAndRegisterDocumentSet-B ont le même uniqueId
(par exemple : le document médical et le document de
signature DSG) : ceci n'est pas autorisé (un uniqueId doit
être mondialement unique par document).
Exemple :
<ns3:RegistryResponse
xmlns:ns2="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
xmlns:ns3="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
xmlns:ns4="urn:oasis:names:tc:ebxmlregrep:xsd:query:3.0"
xmlns:ns5="urn:ihe:iti:xds-b:2007"
xmlns:ns6="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0"
status="urn:oasis:names:tc:ebxmlregrep:ResponseStatusType:Failure" />
XDSRegistryMetadataError
codeContext :
entryUUID=SubmissionSet01
Le code ""SAxxx"" ne fait pas partie du
domaine d'affinité (contentTypeCode)
XDSMissingDocumentMetadata
codeContext="DMPInvalidRequestId
document :Document01"
XDSRepositoryMetadataError /
context=Aucun lot de soumission
détecté dans la requête
Il faut vérifier que le secteur d'activité est bien présent dans
Le jeux de valeur fourni par le CI-SIS pour le champ
contentTypecode.
Le document [CI-ANX-PS-STRU] spécifie la méthode pour
renseigner le champ contentTypeCode au paragraphe
4.1.1.
Cette erreur est remontée dans le cas où les métadonnées
d'un document manquent mais le document est référencé
dans le lot
Cette erreur se produit lorsque le lot de soumission n'est
pas
envoyé
dans
la
requête
ProvideAndRegisterDocumentsetB, conformément au profil
XDS.b :


soit la requête ne comporte pas du tout de lot de
soumission,
soit la classification RegistryPackage en tant que
lot est appliquée sur un classificationScheme au
lieu de classificationNode.
Exemple :

correct :
<ns2:Classification
classificationNode="urn:uuid:a54d6aa5-d40d43f9-88c5-b4633d873bdd"
classifiedObject="SubmissionSet01".../>
226 / 254
11 Annexes
Message d’erreur type retourné
Cause
Transactions TD2.1/TD2.2 IHE ProvideAndRegisterDocumentset-b

incorrect :
<ns7:Classification
classificationScheme="urn:uuid:a54d6aa5d40d-43f9-88c5-b4633d873bdd"
classifiedObject="SubmissionSet01" .../>
Deux causes peuvent expliquer cette erreur :


soit un document strictement identique existe
déjà (même hash), ce qui est interdit (ce cas
pourrait correspondre à une anomalie du LPS
qui tenterait d'envoyer 2 fois le même
document),
soit un document strictement identique existe
et a été dépublié - actuellement il n'y a pas de
possibilité de renvoyer un document identique
dépublié par erreur.
Exemple :
codeContext="uniqueId=1.2.250.1.999.1.1.789
8.3.20110506142825.1;Un document avec un
champ hash identique existe déjà"
errorCode="XDSDuplicateUniqueIdInRegistry"
location="AffinityDomainImpl.checkDocumentE
ntryUnicity"
severity="urn:oasis:names:tc:ebxmlregrep:ErrorSeverityType:Error"
XDSRepositoryError
codeContext="entryUUID=8.1234.1;
Impossible de parser le document."
Cette erreur est remontée lorsque l'une des pièces
jointes attendues dans la requête XDS (CDA ou
Signature XAdES) n'est pas en XML ou ne peut pas
être parsée du fait d'une non-conformité au format
XML, ou n'est pas présente dans la requête (cela peut
par exemple être dû à l'absence de la signature
XAdES du lot de soumission).
Il est nécessaire de respecter le profil IHE DSG de
signature de lot de soumission, décrit dans [IHE-DSG]
XDSRepositoryError
codeContext = "Une erreur systeme
est survenue"
Le DMP renvoie un code XDSRepositoryError avec le
message texte "Une erreur système est survenue".
En général il s'agit d'un problème non géré par le
DMP dans les métadonnées ; par exemple :


taille de champ trop grande par rapport aux
normes XDS.b / ebXML,
le LPS génère les entryUUID et cet entryUUID
est déjà utilisé pour un autre document
(potentiellement pour un autre patient) ; les
entryUUID générés par les LPS sont censés
être uniques via un algorithme de génération
d'uuid.
227 / 254
11 Annexes
XDSDuplicateUniqueIdInRegistry
codeContext="uniqueId=1.2.250.1.999.
1.1.7898.3.20110506142825.1;Un
document avec un champ hash
identique existe déjà"
DMPInvalidData
codeContext = L'analyse du XML de la
signature du lot de soumission a
échoué :
org.xml.sax.SAXParseException:
Premature end of file
Transaction TD3.1 XDS StoredQuery
La transaction TD3.3 (IHE XDS MetadataUpdate) est
à soumettre directement sur le Registry XDS et non
sur le Repository, tel qu’il est indiqué aux § 10.3.3 et
11.3).
Suite à un « GetDocuments »
En authentification indirecte, la requête stockée
« GetDocuments » en mode « ObjectRef » permet d'obtenir
l'UUID d'un document en passant l'OID en paramètre.
DMPAccessDeniedByRightsService
codeContext = Accès refusé;Vous
n'avez pas ce droit fonctionnel,
L'erreur vient du fait que la requête « StoredQuery »
utilisée n’est pas la bonne ; il faut utiliser une requête
GetDocuments et non pas une requête FindDocuments.
Le chapitre 3.18 Registry Stored Query du [IHE-TF2A]
donne la liste des StoredQuery supportées par le profil
XDS.b ainsi que leurs paramètres associés. Le souschapitre 3.18.4.1.2.4 Stored Query IDs indique les ID
identifiants les types de requêtes StoredQuery.
Note : le uuid du Query GetDocuments est :
urn:uuid:5c4f972b-d56b-40ac-a5fcc8ca9b40b9d4
et non :
urn:uuid:5c4f972b-d56b-40aca5fcc8ca9b40b9d4
L’utilisation du copier/coller de la valeur de cet uuid depuis
le document PDF d'IHE au § "3.18.4.1.2.4 Stored Query
IDs" supprime un tiret à cet uuid et n’est donc pas
recommandée (Acrobat Reader supprime abusivement ce
tiret comme s’il s’agissait de la continuation d'un mot...).
228 / 254
11 Annexes
Transaction TD3.3 XDS MetadataUpdate
11.4.4
Autres erreurs fréquentes
Problème
de
connexion
« [3636]
Exception
in
the
HttpWebRequest#44415434:: - Le délai d'attente de l'opération a
expiré » lors de l’exécution du code exemple fourni.



Le serveur testé est-il le bon (vérification des URL – dont le numéro de l’environnement
de test) ?
L'adresse IP à partir de laquelle l’accès est réalisé est-elle bien celle déclarée à l’ASIP
Santé? (vérification de l’adresse IP utilisée à effectuer (à l’aide du site
www.whatismyip.com par exemple)),
En cas d’utilisation du code exemple fourni par l’ASIP Santé : vérifier les paramètres de
proxy paramétré dans le Kit éditeur (voir à ce sujet la documentation du kit éditeur).
Problème de connexion « Handshake
l'établissement du tunnel TLS.
failure
» au tout début lors de
Les paramètres techniques à supporter pour l'établissement de la connexion TLS Mutuelle
entre le LPS et le SI DMP sont explicités dans le DSFT au chapitre 7.1.1 « Connexion au
DMP ». Vous pouvez mettre votre connexion TLS en mode debug pour avoir plus
d'information sur l'origine du refus de connexion de la part du serveur (exemple en java :
variable d'environnement javax.net.debug=all).
Erreur "Missing or invalid WS-Security Header”
Cette erreur peut survenir lors de l’usage du code exemple C# sous Visual Studio 2010. En
effet le code exemple C# a été initialement conçu pour Visual Studio 2008. Si le candidat
souhaite utiliser VSS 2010, il doit réaliser la migration du projet. Cette migration regénère
certaines classes qui ont été modifiées à la main. Le § 11.1 de la documentation fournie
avec le code exemple C# indique le nom du fichier et les modifications à reporter (faire un
différentiel entre celui régénéré par VSS 2010 et le fichier originel du code exemple C#).
229 / 254
11 Annexes
Il s'agit vraisemblablement d'un problème de connexion réseau. Les pistes d’investigations
sont les suivantes :
11.5 Signature XAdES
Cette annexe définit les contraintes de signature XAdES à mettre en œuvre pour
l’alimentation du DMP lors de la signature d’un lot de soumission (requise) et de la signature
d’un document (optionnelle). La signature d’un lot de soumission utilise, en plus de ces
contraintes, le profil IHE DSG, dont une aide à l’implémentation est fournie en annexe 11.6.
Principes généraux de XAdES
XML Advanced Electronic Signatures (XAdES) est une norme conçue par l’European
Telecommunications Standards Institute (ETSI) pour permettre une mise en conformité des
signatures électroniques avec la « Directive 1999/93/EC du Parlement Européen et du
Conseil du 13 décembre 1999 sur le cadre communautaire des signatures électroniques ».
Cette norme offre une boite à outils permettant la mise en œuvre de signatures électroniques
valables sur de longues durées.
XAdES est appliquée comme une surcouche à XML-DSIG.
La référence à utiliser dans le cadre du DMP est définie dans une note du W3C (voir
[XADES-W3C]) expliquant les différents niveaux de signature XAdES (XAdES, XAdES-T,
XAdES-C). Le premier niveau (XAdES) est requis, avec horodatage auto-généré de la
signature (SigningTime). Les autres niveaux (XAdES-T, XAdES-C, etc.) ne sont pas
supportés dans la version actuelle du SI DMP.
11.5.2
Rappel des principes de la signature électronique
Les principes de la signature électronique à maîtriser pour pouvoir s'engager dans la DMP
Compatibilité sont :
1) les grands concepts de cryptage et de condensat (fonction de hachage,
http://fr.wikipedia.org/wiki/Fonction_de_hachage) et leur application dans le domaine
des signatures électroniques,
2) le concept d'indirection via condensat (voir la relation entre les balises Reference
(http://www.w3.org/TR/xmldsig-core/#sec-Reference)
et
SignatureValue
(http://www.w3.org/TR/xmldsig-core/#sec-SignatureValue)) et le concept de
canonisation XML, qui sont des concepts fondamentaux de la norme XMLDSig
(http://www.w3.org/TR/xmldsig-core/) utilisée pour le VIHF et la signature des lots de
soumission en alimentation de documents,
3) la librairie métier utilisée pour la mise en œuvre du code DMP-compatible. L’éditeur
doit pouvoir émettre des signatures électroniques, mais également les valider et
effectuer une analyse initiale en cas d’anomalie de signature (généralement liée à un
mésusage de la canonisation XML, des condensats ou de l’indirection via
condensat). Il n’est pas forcément nécessaire d'utiliser la même librairie pour la
génération et le contrôle (l’éditeur peut par exemple générer la signature en C et la
contrôler en Java
(http://java.sun.com/developer/technicalArticles/xml/dig_signatures/)).
230 / 254
11 Annexes
11.5.1
11.5.3
Structure « XAdES W3C »
11.5.3.1 Structure XAdES de premier niveau applicable au DMP

un élément //ds:Signature/ds:object/xades:QualifyingProperties ;
o (Voir § 11.5.3.2 ci-après)

une référence //ds:Signature/ds:SignedInfos/ds:Reference portant sur le
<SignedProperties> du <xades:QualifyingProperties> ci-dessus;

une référence explicite et signée sur le certificat de signature.
Ceci peut être effectué de plusieurs façons parmi lesquelles :
o
o
ajout d’un nœud
//xades:SignedSignatureProperties/SigningCertificate à
l’ensemble de nœuds défini ci-dessus (voir également § 11.5.2.1.1 ci-après
<xades:SigningCertificate>);
ajout d’un nœud //ds:Signature/ds:KeyInfo/ds:X509Data portant le
certificat
utilisé
pour
la
signature
et
ajout
d’un
nœud
//ds:Signature/ds:SignedInfos/ds:Reference portant sur ce nœud
<ds:X509Data>.
Note : le préfixe "ds:" indique que les éléments XML sont définis dans [XML-DSIG] et le
préfixe indique "xades:" les éléments définis dans [XADES-W3C].
231 / 254
11 Annexes
Dans sa forme de premier niveau, XAdES ajoute à une signature XML-DSIG
<ds:Signature>, l’ensemble d’informations suivant :
11.5.3.2 Description du <xades:QualifyingProperties>
<ds:Object>
<xades:QualifyingProperties>
11 Annexes
<SignedProperties>
<SignedSignatureProperties>
<SigningTime>
…
</SigningTime>
<SigningCertificate>
…
</SigningCertificate>
<SignaturePolicyIdentifier>
<SignaturePolicyImplied/>
</SignaturePolicyIdentifier>
</SignedSignatureProperties>
<SignedDataObjectProperties>
</SignedDataObjectProperties>
</SignedProperties>
<UnsignedProperties>
<UnsignedSignatureProperties>
</UnsignedSignatureProperties>
</UnsignedProperties>
</xades:QualifyingProperties>
</ds:Object>

SignedProperties :
 SigningTime (obligatoire) : date de signature (déclarative, renseignée par le LPS)
prend pour valeur la date et l’heure à laquelle la signature XML-DSIG a été générée.
Dans ce contexte, il est donc pertinent de prévoir une synchronisation NTP de
l’horloge matérielle de la machine et / ou l’utilisation d’un serveur NTP par
l’application gérant la signature. Au format xsd:dateTime, avec composant offset
préconisé : soit en UTC (avec Z) ou en heure locale avec décalage horaire par
rapport à GMT.

SigningCertificate (obligatoire) : référence des certificats
Le noeud <SigningCertificate> contient une liste de plusieurs éléments
<Cert> dont
 le premier <Cert> (requis) pointe obligatoirement le certificat utilisé pour la
signature XML-DSIG.
 Les autres <Cert> pointent les certificats qui composent la chaine de
certification et ce jusqu’à la racine, mais ils sont facultatifs.

Le noeud <Cert> contient deux nœuds fils :
 le premier, <CertDigest>, contient le condensat encodé au format
base64 du certificat dans sa forme binaire DER ainsi que la méthode
utilisée pour générer ce condensat ;
232 / 254

le second nœud <IssuerSerial> est de type
ds:X509IssuerSerialType et contient l’identifiant de l’émetteur du
certificat et le numéro de série du certificat.




sur le site de l’annuaire ASIP-CPS : http://annuaire.gip-cps.fr/, onglet
« Autorités de Certification »)
sur l’espace intégrateur ASIP-CPS : http://integrateurs-cps.asipsante.fr, lien
« Certificats racine PROD » (TEST pour la mise au point du LPS)
dans le dossier « coffre » de la CryptoLib 5
dynamiquement, dans le magasin de certificat de l’OS (après installation de
la CryptoLib)
Pour le DMP, les AC utiles pour la signature XAdES sont :
1) pour l’authentification directe (carte CPS)
 AC Racine : GIP-CPS PROFESSIONNEL (avec rôle signature du
certificat), racine des cartes CPS « professionnel » (fichier IGC-CPS2ter2020.CERTSIGN.EXPL.PROFESSIONNEL.RACINE.cer dans la CryptoLib)
 AC Intermédiaire : GIP-CPS CLASSE-1 (avec rôle signature du certificat)
(fichier IGC-CPS2ter-2020.CERTSIGN.EXPL.PROFESSIONNEL.CL01.cer
dans la CryptoLib)
2) pour l’authentification indirecte (certificat de personne morale "structure de
soins")
 AC Racine : GIP-CPS, Racine des certificats logiciels (fichier
2008_03_17_IGC_CPS2bis_Exploit_Racine_CertSign_Fin_2020.cer dans
la CryptoLib)
 AC Intermédiaire : AC-CLASSE-4 des « certificats de personne morale »
(fichier
2008_03_17_IGC_CPS2bis_Exploit_Classe4_CertSign_CrlSign_Fin_2020.
cer dans la CryptoLib)
Pour information, les autres fichiers installés dans le dossier "coffre" de la
CryptoLib ne sont pas pour le moment utiles dans le processus d'alimentation du
DMP.


SignaturePolicyIdentifier (obligatoire) : référence à une politique de
signature. Pour le DMP, ce champ sera laissé « implicite » avec l’ajout d’un élément
fils <SignaturePolicyImplied/>.

SignedDataObjectProperties (obligatoire) : nœud vide.
UnsignedProperties :

UnsignedSignatureProperties (obligatoire) : nœud vide.
5
L’éditeur est invité à consulter les documentations d’installation de la CryptoLib disponibles sur
http://integrateurs-cps.asipsante.fr pour connaitre l’emplacement du dossier « coffre », en fonction du
ou des OS supporté(s).
233 / 254
11 Annexes
Les Autorités de Certification (AC) composant la chaine de certification à intégrer
peuvent être récupérées :
Exemple :
<QualifyingProperties xmlns="http://uri.etsi.org/01903/v1.1.1#" Target="#OID_sign">
<SignedProperties Id="S0-SignedProperties" xmlns="http://uri.etsi.org/01903/v1.1.1#">
// Références et empreintes du certificat de signature et de ses certificats parents jusqu’à
la racine
<Cert xmlns="http://uri.etsi.org/01903/v1.1.1#">
<CertDigest>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></DigestMethod>
<DigestValue>asifcL78Fhkv1TLUczwwxnTi6RY=</DigestValue>
</CertDigest>
<IssuerSerial>
<X509IssuerName
xmlns="http://www.w3.org/2000/09/xmldsig#">CN=TEST
CLASSE1,OU=TEST PROFESSIONNEL,O=TEST,C=FR</X509IssuerName>
<X509SerialNumber
xmlns="http://www.w3.org/2000/09/xmldsig#">1509588</X509SerialNumber>
</IssuerSerial>
</Cert>
<CertDigest>
<DigestValue> JDjPyPJ1bLsmhQJz96DkfFeyIz4=</DigestValue>
</CertDigest>
<IssuerSerial>
<X509IssuerName
xmlns="http://www.w3.org/2000/09/xmldsig#">OU=TEST
PROFESSIONNEL,O=TEST,C=FR</X509IssuerName>
<X509SerialNumber
xmlns="http://www.w3.org/2000/09/xmldsig#">
4370</X509SerialNumber>
</IssuerSerial>
</Cert>
<CertDigest>
<DigestValue> cemsA/zjMXcHx/XV1CnqIJ7KIwU=</DigestValue>
</CertDigest>
<IssuerSerial>
<X509IssuerName
xmlns="http://www.w3.org/2000/09/xmldsig#">OU=TEST
PROFESSIONNEL,O=TEST,C=FR</X509IssuerName>
<X509SerialNumber
xmlns="http://www.w3.org/2000/09/xmldsig#">
</IssuerSerial>
</Cert>
// politique de signature positionnée à « implicite » en attente de la définition
d’une politique de signature
<SignedDataObjectProperties></SignedDataObjectProperties>
</SignedProperties>
<UnsignedSignatureProperties></UnsignedSignatureProperties>
</QualifyingProperties>
234 / 254
11 Annexes
<SigningTime>2010-11-14T14:14:39.281+01:00</SigningTime> // date/heure de signature
11.5.4
Erreurs fréquentes lors de la mise en œuvre









corruption des données référencées (balise Reference),
mauvaise canonisation des données référencées dans une balise Reference le cas
échéant,
mauvais calcul du condensat sur une donnée référencée,
mauvaise conversion du condensat binaire en base 64 dans une balise Reference,
erreur dans la référence à une donnée « référencée » (la librairie effectue les calculs
de la pièce jointe A mais les range sous l'intitulé B),
mauvaise canonisation de la balise Reference,
mauvais calcul du condensat sur la balise Reference,
mauvaise signature RSA sur le condensat de la balise Reference,
mauvaise conversion de la signature RSA binaire en base 64 dans la balise
SignatureValue.
La liste ci-dessous recense les erreurs les plus fréquemment rencontrées lors de la mise en
œuvre dans le LPS :
 En cas d’erreur DMPInvalidSignature il peut être utile de vérifier :
 que la signature du lot de soumission n'est pas intervertie avec la pièce jointe
CDA R2 dans le corps du message MTOM,
 qu’il n’y a pas de problème de canonisation des éléments signés
 que les hash sont correctement calculés.

Différentes erreurs DMPInvalidSignature sont possibles :

DMPInvalidSignature : « Le controle de la signature du lot a
échoué: Invalid signature : invalid reference hashes on :
[#S0-SignedProperties] » :
o il peut s'agir d'un problème de canonisation sur certains sous-éléments de
l'élément SignedProperties : les éléments SignedProperties et
ses éléments fils (sauf X509IssuerName et X509SerialNumber) ne
respectent pas les bons namespaces par rapport au schéma XAdES :
 SignedProperties et ses éléments fils doivent être dans le
namespace XAdES (http://uri.etsi.org/01903/v1.1.1#),
 sauf X509IssuerName et X509SerialNumber qui sont des
éléments standards XmlDSig, et qui par conséquent doivent être
dans
le
namespace
XmlDSig
(http://www.w3.org/2000/09/xmldsig#),
o la Signature XAdES présente dans les messages d'exemples
TD2.1/TD2.2 reflète cela.

DMPInvalidSignature : « Le controle de la signature du lot a
échoué : Invalid signature : invalid SignedInfos » :
o en général il faut débuguer le code : les hash des éléments Reference
de SignedInfo sont faux (mal calculés), éventuellement suite à une
mauvaise canonisation,
235 / 254
11 Annexes
Une anomalie de signature peut être notamment due aux facteurs suivants :
DMPInvalidSignature : « Le contrôle de la signature du lot a
échoué : Le contrôle de cohérence des condensats de la
signature
de
la
pièce
jointe
a
échoué
pour
:
urn:oid:1.2.250.1.59.905.20111001.1.2011101012.17090717^CR17
090717 » :
o le message renvoyé signifie que le condensat (hash) calculé pour le
document
de
uniqueId
=
urn:oid:1.2.250.1.59.905.20111001.1.2011101012.17090717^CR17090717 n'est
pas correct. Le DMP recalcule le condensat du fichier CDA et le compare
avec la valeur fournie dans la signature XAdES (c'est ce condensat qui est
ensuite signé par le certificat CPS du PS). Il est nécessaire de respecter le
profil IHE DSG de signature de lot de soumission. Voir également la note
en § 11.6.2.2 concernant la construction des OID et leur compatibilité avec
IHE DSG.
236 / 254
11 Annexes

11.6 Aide à l’implémentation du profil IHE DSG pour le
DMP
Cette aide se veut didactique comme un tutoriel « pas à pas ». L’organisation de cette
annexe (chronologie des paragraphes) suit la logique de construction d’une requête XDS.b
et l’ordre de programmation des opérations à réaliser par l’éditeur pour la signature XAdES
(voir [XADES-W3C]) du lot de soumission.
Cette annexe ne constitue pas une spécification et ne saurait remplacer la lecture du CI-SIS,
des profils IHE XDS.b et DSG (pas de description des métadonnées XDS par exemple, ni
d’un CDA) et s’attache à décrire les références entre les identifiants des parties de la requête
XDS.b pour la construction d’une signature de lot de soumission.
Cette aide présente :
-
des exemples commentés de XML de signature DSG de lot de soumission et de
requête d’alimentation XDS.b (hors signature de document) au format MTOM ;
une vulgarisation en français et résumée de la partie utile aux spécifications DMP du
profil IHE DSG (voir [IHE-DSG]), pour sa partie signature d’un lot.
Cette aide ne traite pas de la signature des documents.
237 / 254
11 Annexes
Cette annexe constitue une aide à l’implémentation du profil IHE DSG (voir [IHE-DSG]) pour
la signature des lots de soumission envoyés au DMP via les transactions TD2.1/TD2.2
d’alimentation en documents.
11.6.1
Structure d’une soumission XDS.b
La soumission de documents au DMP est effectuée par la transaction IHE ITI-41
ProvideAndRegisterDocumentSet-b (profil XDS.b) associée obligatoirement à la signature de
lot de soumission IHE DSG (ref. [IHE-DSG] Chapitre “5.3.8.2 - Signature of a whole XDS
Submission Set”).
Représentation schématique d’une soumission XDS.b
11 Annexes
La requête envoyée au serveur est constituée des éléments suivants, dans un paquet mimemultipart respectant MTOM/XOP :
<SOAP:Envelope>
<SOAP:HEADER>
WS addressing
wsse:Security / VIHF (saml:Assertion)
<SOAP:BODY>
< ProvideAndRegisterDocumentSetRequest >
< SubmitObjectsRequest>
Métadonnées XDS.b
Métadonnées lot de soumission - id=lot1 - uniqueID = « OID_lot »
Métadonnées document 1 – id=doc1 - uniqueID = « OID_doc1 »
…
Métadonnées document N – id=docN - uniqueID = « OID_docN »
Métadonnées XDS du document de signature IHE DSG
id=sign uniqueID = « OID_signature »
+ Associations entre les objets…
…
<Document id=doc1> / xop:Include href=cid1
<Document id=docN> / xop:Include href=cidN
<Document id=sign> / xop:Include href=cidsign
Part MIME du document 1
Content-ID : <cid1>
Pièce jointe document 1 – CDA R2
…
Part MIME du document N
Content-ID : <cidN>
Pièce jointe document N – CDA R2
Part MIME de la signature du lot
Content-ID : <cidsign>
Pièce jointe XAdES – Signature du lot de soumission
Fig. 88 : contenu d’une requête de soumission XDS.b
238 / 254
Relation entre les métadonnées XDS.b et le reste de la requête
Les métadonnées XDS.b regroupent :


Les métadonnées du lot de soumission (RegistryPackage ebXML)
o Identifié au sein de la requête par un identifiant interne à la requête noté « lot1 »
dans les exemples de ce document
o
Identifié par un uniqueId au format OID, noté « OID_lot » dans la suite du document
o
Cet OID_lot doit se retrouver en référence dans le Manifest IHE de la signature
XAdES.
Les métadonnées des documents du lot (1 à N) (ExtrincicObject ebXML)
o Identifiés chacun au sein de la requête par un identifiant interne à la requête noté «
doc1 » à « docN » dans les exemples de ce document
o
Identifiés chacun par un uniqueId au format OID noté « OID_doc1 » à « OID_docN »
dans la suite du document
o
Ces OID_docN doivent se retrouver en référence dans le Manifest IHE de la signature
XAdES.
Les métadonnées d’un document de signature DSG (ExtrincicObject ebXML) ; le contenu de
ces métadonnées est défini dans [CI-PARTAGE] au § 4.2.2 « Imputabilité du dépôt des
documents » :
o Identifié par un uniqueId au format OID noté « OID_sign » dans la suite du document
o
Cet OID_sign doit se retrouver dans l’élément Signature/@Id de pièce jointe
signature XAdES.
Les codes couleurs utilisés ci-dessus pour représenter les divers identifiants sont repris dans
les exemples dans la suite de cette aide.
Chronologie possible pour la construction de la requête XDS.b :
1) Construire ou ajouter le(s) document(s) CDA (les documents CDA peuvent être
préexistants) et calculer les hashs des documents.
2) Créer les métadonnées XDS du lot de soumission et son identifiant unique.
3) Créer les métadonnées XDS des documents (éventuellement à partir des CDA) et
les identifiants uniques référençant les parties MTOM dans lesquels sont écrits les
CDA.
4) Créer les métadonnées XDS du document de signature et son identifiant unique.
5) Créer les associations entre le lot de soumission et les documents.
6) Créer la pièce jointe XAdES de signature du lot de soumission (voir détail au
paragraphe suivant). Elle reprend dans son Manifest les différents identifiants
uniques précédents (celui du lot de soumission et ceux des documents) et les hash
de chaque document. La pièce jointe XAdES de signature du lot de soumission est
donc nécessairement créée en dernier.
239 / 254
11 Annexes

11.6.2
Construction de la pièce jointe XAdES de signature du lot de
soumission
Une chronologie possible de construction de la pièce jointe XAdES de signature du lot de
soumission est la suivante :
2) Construction du QualifiyingProperties inclus dans ds:Object, dont
l’élément SignedProperties sera signé.
3) Construction du SignedInfo à partir des Références et de leurs Hashs calculés
suivant l’algorithme indiqué.
4) Canonisation et signature du SignedInfo (apposée dans SignatureValue)
En pratique, il est recommandé de se baser sur une bibliothèque existante gérant a minima
XML-DSIG pour effectuer la construction de la signature XAdES (ex : API XMLSignature de
Java), celle-ci gérant les problématiques de transformation, canonisation, calcul des digest et
de la signature finale.
240 / 254
11 Annexes
1) Construction du Manifest inclus dans ds:Object et qui sera signé.
11.6.2.1 Structure de base
La structure de base de la pièce jointe XAdES d’un lot de soumission est représentée ciaprès :
<?xml version="1.0" encoding="UTF-8"?>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#" Id="OID_sign">
<SignedInfo>
[informations signées]
</SignedInfo>
<KeyInfo>
<X509Data>
<X509Certificate> [certificat X509 signataire] </X509Certificate>
</X509Data>
</KeyInfo>
<Object>
<SignatureProperties>
// purposeOfSignature imposée par DSG ; le contenu dans SignatureProperty est fixe
<SignatureProperty Id="purposeOfSignature" Target="#OID_sign"> 1.2.840.10065.1.12.1.14
</SignatureProperty>
</SignatureProperties>
</Object>
<Object>
<Manifest Id="IHEManifest">
[Manifest IHE DSG : références du lot à signer]
</Manifest>
</Object>
<Object>
// propriété spécifiques XAdES
[propriété XAdES à signer]
</SignedProperties>
</Object>
</Signature>
Il
est
possible
de
mettre
SignatureProperties,
Manifest
et
QualifyingProperties dans le même nœud Object, ou dans des nœuds Object
différents (les deux constructions sont tolérées).
Un élément SignatureProperties est imposé par IHE DSG et doit faire référence à
l’OID du document de signature. La valeur 1.2.840.10065.1.12.1.14 est positionnée
par le CI-SIS (but de la signature : signature par la « Source » des données).
L’élément KeyInfo/X509Data/X509Certificate doit contenir le certificat X509 utilisé
pour la signature.
L’ordre des chapitres suivants suit l’ordre logique de programmation dans lequel les
différents éléments doivent être construits.
241 / 254
11 Annexes
<SignatureValue> [valeur de la signature] </SignatureValue>
11.6.2.2 Construction du Manifest
Un Manifest XML doit être construit afin de référencer le lot de soumission et l’ensemble des
documents le composant.
Ajout de la référence au lot de soumission :
<Reference URI="urn:oid:OID_lot">
<DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>AA==</DigestValue>
</Reference>
</Manifest>
Ajout de la référence à chaque document :
Pour chaque document du lot6 :
 Si le document est XML (CDA R2, en pratique toujours le cas dans le DMP),
appliquer l’algorithme de transformation « http://www.w3.org/TR/2001/REC-xml-c14n20010315#WithComment » (canonisation) ;

Calculer le hash sha1 de la pièce jointe ainsi transformée ;

Insérer une référence dans le Manifest, avec le uniqueId du document (précédé de
« urn:oid: ») dans un élément Reference/@URI et le hash dans DigestValue.
Note : Le format d’un uniqueId de document peut être OID^Extension en XDS. Or la
version actuelle du DMP ne supporte pas le format OID^Extension pour cette
référence dans le manifest. Il est donc demandé de n’utiliser pour les uniqueId de
document
que
le
format
OID
sans
extension
(ex
:
urn:oid:1.2.850.2345.3245.13.58132).
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>AA==</DigestValue>
</Reference>
<Reference URI="urn:oid:OID_docN">
<Transforms>
<Transform
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n20010315#WithComments"/>
// transformation à appliquer à la pièce jointe CDA R2 avant hachage
</Transforms>
<DigestValue> [digest (hash) de la pièce jointe du document N] </DigestValue>
</Reference>
</Manifest>
6
Un document fait partie d’un lot s’il y a une relation de type « has member » qui le lie au lot. Aucun
autre type d’association ne doit être pris en considération pour déterminer si un document fait partie
d’un lot de soumission.
242 / 254
11 Annexes
Ajouter la référence au lot de soumission (son OID précédé de « urn:oid: ») dans un élément
Reference/@URI, ainsi que son « hash null » (0 en base64).
11.6.2.3 Construction du QualifiyingProperties
Voir Annexe 11.5.3.2
11.6.2.4 Construction du SignedInfo
L’élément SignedInfos doit contenir les éléments à faire signer par le certificat.
Structure de base :
11 Annexes
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n20010315#WithComments"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
</SignedInfo>
Ajouter les Reference :

au nœud Manifest, incluant le digest sha-1 de celui-ci

au nœud SignedProperties, incluant le digest sha-1 de celui-ci
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n20010315#WithComments"/>
<Reference Type="http://www.w3.org/2000/09/xmldsig#Manifest" URI="#IHEManifest">
<DigestValue> [digest du manifest] </DigestValue>
</Reference>
<Reference Type="http://uri.etsi.org/01903/v1.1.1#SignedProperties" URI="#S0SignedProperties">
<DigestValue> [digest des SignedProperties] </DigestValue>
</Reference>
</SignedInfo>
11.6.2.5 Canonisation et signature du SignedInfo
La signature finale doit être apposée dans l’élément <SignatureValue>
 Canonization du SignedInfo suivant l’algorithme
http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments

Signature rsa-sha1 du résultat de la canonization par le certificat de signature

Injection du résultat dans SignatureValue.
243 / 254
11.6.3
Requête d’alimentation XDS.b commentée
Pour plus de lisibilité, les identifiants utilisés dans la requête commentée ci-après sont
volontairement non signifiants. L’éditeur doit respecter le format approprié, OID ou identifiant
interne à la requête.
------=_Part_0_18075465.1289232799781 // Part MIME du message SOAP
Content-Type:
application/xop+xml;
charset=UTF-8;
type="application/soap+xml";
action="urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b";
Content-Transfer-Encoding: binary
Content-ID: <root.message@xyz>
<soap:Header>
[WS-adressing]
[wsse:Security / VIHF]
</soap:Header>
<soap:Body>
<ProvideAndRegisterDocumentSetRequest...>
<lcm:SubmitObjectsRequest>
<rim:RegistryObjectList>
<rim:RegistryPackage id="lot1">
[métadonnées du lot de soumission]
[uniqueId = OID_lot]
</rim:RegistryPackage>
<rim:ExtrinsicObject id="doc1" ...>
[métadonnées du document 1]
[uniqueId = OID_doc1]
</rim:ExtrinsicObject>
<rim:ExtrinsicObject id="docN" ...>
[métadonnées du document N]
[uniqueId = OID_docN]
<rim:ExtrinsicObject id="sign1" ...>
[métadonnées du document de signature]
[uniqueId = OID_sign1]
<rim:Association ... sourceObject="lot1" targetObject="doc1">
[association (de type "HasMember") du doc1 dans le lot]
</rim:Association>
<rim:Association ... sourceObject="lot1" targetObject="docN">
[association (de type "HasMember") du docN dans le lot]
</rim:Association>
<rim:Association ... sourceObject="lot1" targetObject="sign1">
[association (de type "HasMember") du document de signature sign1 dans le lot]
</rim:Association>
<rim:Association ... sourceObject="sign1" targetObject="lot1">
[association (de type "signs") du document de signature sign1 dans le lot]
</rim:Association>
</rim:RegistryObjectList>
</lcm:SubmitObjectsRequest>
<Document id="sign1">
<xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:cidsign"/>
</Document>
<Document id="doc1">
<xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:cid1"/>
</Document>
<Document id="docN">
<xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:cidN"/>
</Document>
</ProvideAndRegisterDocumentSetRequest>
</soap:Body>
</soap:Envelope>
244 / 254
11 Annexes
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
------=_Part_0_18075465.1289232799781 // Part MIME de la pièce jointe XAdES de signature du
lot
Content-Type: application/octet-stream
Content-ID: <cidsign>
<?xml version="1.0" encoding="UTF-8"?>
<SignedInfo>
<CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"/>
<Reference Type="http://www.w3.org/2000/09/xmldsig#Manifest" URI="#IHEManifest">
<DigestValue> [digest du manifest] </DigestValue>
</Reference>
<Reference
Type="http://uri.etsi.org/01903/v1.1.1#SignedProperties"
URI="#S0SignedProperties">
<DigestValue> [digest des SignedProperties] </DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>NXejuzBMd1ZPm...</SignatureValue> // valeur de la signature
<KeyInfo>
<X509Data>
<X509Certificate>MIIFVzCCBD+gAwIBA...</X509Certificate> // certificat X509 signataire
</X509Data>
</KeyInfo>
<Object>
<SignatureProperties>
// purposeOfSignature imposée par DSG ; le contenu dans SignatureProperty est fixe
<SignatureProperty Id="purposeOfSignature"
Target="#OID_sign">1.2.840.10065.1.12.1.14</SignatureProperty>
</SignatureProperties>
</Object>
<Object>
<Manifest Id="IHEManifest"> // Manifest IHE DSG : références du lot à signer
<DigestValue>AA==</DigestValue> //« Hash du lot », doit être égal à 0 en base64
</Reference>
<Reference URI="urn:oid:OID_doc1">
<Transforms>
<Transform
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n20010315#WithComments"/> // transformation à appliquer à la pièce jointe CDA R2 avant hachage
</Transforms>
<DigestValue> [digest (hash) de la pièce jointe du document 1] </DigestValue>
</Reference>
[...]
<Reference URI="urn:oid:OID_docN">
<Transforms>
<Transform
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n20010315#WithComments"/> // transformation à appliquer à la pièce jointe CDA R2 avant hachage
</Transforms>
<DigestValue> [digest (hash) de la pièce jointe du document N] </DigestValue>
</Reference>
</Manifest>
</Object>
245 / 254
11 Annexes
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#" Id="OID_sign">
<Object>
// Références et empreintes du certificat de signature et de ses certificats parents
jusqu’à la racine
<CertDigest>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1">
</DigestMethod>
<DigestValue>asifcL78Fhkv1TLUczwwxnTi6RY=</DigestValue>
</CertDigest>
<IssuerSerial>
<X509IssuerName xmlns="http://www.w3.org/2000/09/xmldsig#">
CN=TEST CLASSE-1,OU=TEST PROFESSIONNEL,O=TEST,C=FR</X509IssuerName>
<X509SerialNumber xmlns="http://www.w3.org/2000/09/xmldsig#">
</IssuerSerial>
</Cert>
<CertDigest>
</DigestMethod>
<DigestValue> JDjPyPJ1bLsmhQJz96DkfFeyIz4=</DigestValue>
</CertDigest>
<IssuerSerial>
OU=TEST PROFESSIONNEL,O=TEST,C=FR</X509IssuerName>
</IssuerSerial>
</Cert>
<CertDigest>
</DigestMethod>
<DigestValue> cemsA/zjMXcHx/XV1CnqIJ7KIwU=</DigestValue>
</CertDigest>
<IssuerSerial>
OU=TEST PROFESSIONNEL,O=TEST,C=FR</X509IssuerName>
</IssuerSerial>
</Cert>
// politique de signature positionnée à « implicite » en attente de la définition
d’une politique de signature
<SignedDataObjectProperties></SignedDataObjectProperties>
</SignedProperties>
</Object>
</Signature>
246 / 254
11 Annexes
<SigningTime>2010-11-14T14:14:39.281+01:00</SigningTime> // date/heure de signature
<ClinicalDocument
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:hl7org:v3">
<realmCode code="FR"/>
<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
<templateId root="2.16.840.1.113883.2.8.2.1" assigningAuthorityName="HL7 France"/>
<templateId root="1.2.250.1.213.1.1.1.1" assigningAuthorityName="Cadre InteropASIP"/>
<templateId root="1.3.6.1.4.1.19376.1.2.20" assigningAuthorityName="IHE XDS-SD"/>
<id root="OID_doc1"/>
...
</ClinicalDocument>
[...]
------=_Part_0_18075465.1289232799781 // Part MIME de la pièce jointe du doc N
Content-ID: <cidN>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ClinicalDocument
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:hl7org:v3">
<realmCode code="FR"/>
<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
<templateId root="2.16.840.1.113883.2.8.2.1" assigningAuthorityName="HL7 France"/>
<templateId root="1.2.250.1.213.1.1.1.1" assigningAuthorityName="Cadre InteropASIP"/>
<templateId root="1.3.6.1.4.1.19376.1.2.20" assigningAuthorityName="IHE XDS-SD"/>
<id root="OID_docN"/>
...
</ClinicalDocument>
247 / 254
11 Annexes
------=_Part_0_18075465.1289232799781 // Part MIME de la pièce jointe du doc 1
Content-ID: <cid1>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
11.7 Code exemple
Des exemples de messages et trames SOAP d'échange avec le système DMP sont mis à
disposition par l’ASIP Santé à titre indicatif.
Ils sont téléchargeables sur le site :
Les exemples mis à disposition sont :
•
des messages HL7 V3 (gestion administrative du dossier)
o sans_SOAP : messages HL7 V3 non encapsulés dans un message SOAP complète la description de chaque message
o avec_SOAP : messages HL7 V3 encapsulés dans un message SOAP
•
des trames SOAP de web-services spécifiques
•
des trames SOAP XDS.b
Attention :
- Les exemples et les trames SOAP ne constituent ni une référence, ni une spécification.
- certaines trames ont été volontairement reformatées (XML indenté) pour plus de lisibilité
- la cohérence fonctionnelle des valeurs d'exemples renseignées n'est pas garantie : l‘éditeur
devra s'assurer que les valeurs produites dans les champs des messages correspondent
bien à un cas fonctionnel possible pour le DMP
- les valeurs de signatures peuvent être non significatives (trames reformatées)
248 / 254
11 Annexes
http://www.esante.gouv.fr/services/espace-dmp/specifications-fonctionnelles-et-techniques-de-la-dmp-compatibilite.
11.8 Règles sur les dates de naissance lues en
carte Vitale
11.8.1
Règle AM_DLU : date de naissance « lunaire »
La règle décrite ci-après, issue du GIE Sesam-Vitale, permet de transformer une date lunaire
en date « standard ».
Note : Cette règle est utilisée pour la détermination du siècle de la date de naissance.
Règle :
Si le mois est supérieur à 12, prendre la valeur 12 pour le mois.
Si le jour est supérieur au dernier jour du mois, prendre la valeur du dernier jour valide du
mois (Cf. § 11.8.2 Règle AM_BISSEX : détermination d'une année bissextile ).
Exemple :
Date lunaire
Date après traitement
35/03/1999
31/03/1999
23/15/1999
23/12/1999
36/02/1999
28/02/1999
Tableau 89 : exemple de résultat de la règle AM_DLU
11.8.2
Règle AM_BISSEX : détermination d'une année bissextile
Si l'année est un multiple de 4
L’année est bissextile (par exemple 2000)
Sinon (l’année n’est pas un multiple de 400)
L’année n’est pas bissextile (par exemple 1900)
L’année est bissextile (par exemple 2016)
L’année n’est pas bissextile (par exemple 2015)
Il y a 28 jours dans une année non bissextile et 29 jours dans une année bissextile.
249 / 254
11 Annexes
Les dates de naissance des bénéficiaires nés à l'étranger peuvent contenir un mois dont la
valeur est supérieure à 12 et un jour dont la valeur est supérieure au dernier jour du mois
valide. Ces dates sont dites "lunaires".
11.8.3
Règle AM_DNA_SIECLE : détermination du siècle d’une date
de naissance
La règle décrite ci-après, issue de la règle AM_DNA du GIE Sesam-Vitale, permet de
déterminer le siècle de la date de naissance lorsque celui est absent de la carte Vitale.
Lorsque la date de naissance lue en carte vitale possède le siècle, cette règle ne doit pas
être utilisée.



En carte Vitale 1, le siècle peut être renseigné en carte, ou non.
Les API de Lecture Vitale retournent pour la date de naissance, un champ et un
format différent 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)).
Cette règle n’est pas utile si le LPS utilise les « API FSE », celles-ci effectuant ellesmêmes le calcul du siècle (format retourné par ces API = AAAAMMJJ0000)
Pour déterminer le siècle de naissance, on utilise une date D (équivalente à la date du jour).
Description du traitement effectué pour déterminer le siècle de naissance :
Si la date du jour est antérieure à l'an 2000 :
On considère que l'année de naissance est 19AA. Si on obtient une date de naissance
supérieure ou égale à la date du jour, il s'agit d'une incohérence : l'année de naissance
est donc 18AA. Si par contre, on obtient une date de naissance inférieure à la date du
jour, le résultat est cohérent. Pour affiner la détermination du siècle, on s'assure que les
personnes de moins de 16 ans ont bien une qualité enfant. Sinon, il s'agit en fait de
personnes adultes nées en 18AA.
Si la date du jour est postérieure à l'an 2000 :
On considère que l'année de naissance est 20AA. Si on obtient une date de naissance
supérieure ou égale à la date du jour, il s'agit d'une incohérence : l'année de naissance
est donc 19AA. On affine le résultat en s'assurant que les personnes de moins de 16
ans ont bien une qualité enfant. Sinon, ce sont en fait des adultes nés en 18AA.
Si l'année de naissance 20AA est strictement inférieure à la date du jour : on considère
que si la personne n'est pas un enfant, c'est qu'elle est née en 19AA (car elle a plus de
16 ans).
Limites de ce traitement :
Ce principe permet de gérer les centenaires jusqu'à 116 ans. Un centenaire âgé de 117 ans
est vu comme un adulte de 17 ans.
La qualité en carte d'un neveu ou d'un petit fils étant différente de "enfant", le siècle de
naissance déterminé est erroné : ils sont vus comme des adultes de plus de cent ans.
250 / 254
11 Annexes
Rappels :
Exemples :
Centenaire âgé de 117 ans au 01/06/2001 : la carte contient 840101 pour une date de
naissance 01/01/1884. On se positionne à une date du jour égale à 01/06/2001. On
considère dans un premier temps que l'année de naissance est 2084, ce qui est incohérent.
On considère donc que l'année de naissance est 1984, ce qui correspond à une personne
âgée de 17 ans. Cette personne n'a pas la qualité enfant, le résultat est donc cohérent.
L'année de naissance déterminée est donc 1984 au lieu de 1884.
Neveu âgé de 14 ans au 01/06/2001 : la carte contient 870101 pour une date de naissance
01/01/1987. On se positionne à une date du jour égale à 01/06/2001. On considère dans un
premier temps que l'année de naissance est 2087, ce qui est incohérent. On considère donc
que l'année de naissance est 1987, ce correspond à une personne âgée de 14 ans. Cette
personne n'a pas la qualité enfant, le résultat est donc encore incohérent : elle est donc née
1887. L'année de naissance déterminée est donc 1887 au lieu de 1987.
Règle : Cette règle détermine le siècle en fonction :


d'une date D (passée en paramètre) et,
de la qualité du bénéficiaire.
Si la date D est strictement inférieure à 01/01/2000 :
 Par défaut, le siècle de naissance est 19.
Traitement de cette date de naissance (siècle = 19) en date lunaire (Cf. § 11.8.1
AM_DLU : Dates lunaires) pour les comparaisons de dates.
Si la date de naissance est supérieure ou égale à la date D, le siècle de naissance
est 18.
Sinon (c'est à dire si la date de naissance est strictement inférieure à la date D),
Si la date de naissance est supérieure ou égale à (la date D-16 ans) et si la
qualité du bénéficiaire est différente de "enfant", le siècle de naissance est 18.
Sinon (c'est à dire si la date D est supérieure ou égale à 01/01/2000)
 Par défaut, le siècle de naissance est 20.
Traitement de cette date de naissance (siècle = 20) en date lunaire (Cf. § 11.8.1
AM_DLU : Dates lunaires) pour les comparaisons de date.
Si la date de naissance est supérieure ou égale à la date D,
Par défaut, le siècle de naissance est 19.
Si la date de naissance est supérieure ou égale à (la date D-16 ans) et si la
qualité du bénéficiaire est différente de "enfant", le siècle de naissance est 18.
Sinon (c'est à dire si la date de naissance est strictement inférieure à la date D),
Si la qualité du bénéficiaire n'est pas enfant, le siècle de naissance est 19.
251 / 254
11 Annexes
Centenaire âgé de 116 ans au 01/06/2001 : la carte contient 850101 pour une date de
naissance 01/01/1885. On se positionne à une date du jour égale à 01/06/2001. On
considère dans un premier temps que l'année de naissance est 2085, ce qui est incohérent.
On considère donc que l'année de naissance est 1985, ce correspond à une personne âgée
de 16 ans. Cette personne n'a pas la qualité enfant, le résultat est donc encore incohérent :
elle est donc née 1885.
Note :



11 Annexes

Ce principe permet de gérer les centenaires jusqu'à 116 ans.
Ce mode de gestion est valable jusqu'en 2016.
La qualité inscrite en carte est identique pour un arrière-grand-père et pour un petitfils, voire pour un neveu, ils sont tous deux "ascendant ou collatéraux" de l'assuré et
seront donc selon ce mode de gestion vu comme des centenaires.
La date de naissance peut être une date "lunaire".
252 / 254
11 Annexes
*** FIN DU DOCUMENT ***
253 / 254
11 Annexes
254 / 254

Dossier de spécifications fonctionnelles et techniques des interfaces

Transcription

Documents pareils

montage pour ext 114

WinDbg : outil d`analyse d`écran bleu sous Windows

CH Jacques Coeur de Bourges

Un aperçu des prix indicatifs se trouve ici

Le projet Languedoc-Roussillon Fiche signalétique

Pleingaz FERRARI F12

INFINIMENT GRAND (SOL)

Dossier Médical Personnel / Partagé - Clinique Lyon-Nord

modele de note d`information des usagers relative au consentement

Informatiser le bordel