Source: http://www.d-m-p.org/actus/dmp/faq-dmp-compatibilite-actualise
Timestamp: 2013-05-25 19:34:54+00:00
Document Index: 195287494

Matched Legal Cases: ['§ 3', '§ 2', '§ 2', '§6', '§ 4', '§ 5', '§ 5', '§ 7', '§ 7', '§ 7', '§ 4', '§ 4']

FAQ DMP Compatibilité (actualisé) | esante.gouv.fr, le portail de l'ASIP Santé
AccueilDMPFAQ DMP Compatibilité (actualisé) Agrandir le texte
FAQ DMP Compatibilité (actualisé) English version
DMP | 09 avr. 2013
4 QUESTIONS RELATIVES AUX FONCTIONS DE CRÉATION ET GESTION ADMINISTRATIVE DU DOSSIER
6 QUESTIONS RELATIVES À LA RECHERCHE ET CONSULTATION DE DOCUMENTS
7 QUESTIONS RELATIVES AU PASSAGE DE CONTEXTE ET À L’ACCÈS WEB PS La lecture des FAQ "professionnel de santé" et "Patients" est également recommandée aux candidats à l’homologation de la DMP Compatibilité.
1	Questions relatives au processus d’homologation Un logiciel de professionnel de santé (LPS) intégrant les services DMP doit-il faire l'objet d'une validation spécifique de l'ASIP Santé ? Oui : l'ASIP Santé a défini une procédure d'homologation, décrite dans le contrat éditeur. L'homologation consiste à vérifier le bon fonctionnement des LPS à l'interface avec le système d'information DMP. Elle porte sur des profils de DMP Compatibilité, qui regroupent de façon cohérence les différents services exposés par le SI DMP. Ces profils sont : création et gestion administrative de dossier ; alimentation en documents médicaux ; consultation de documents médicaux. Un LPS peut être homologué pour un ou plusieurs profils. Note : la transaction TD0.9 (Accès Web-PS contextuel) peut être implémentée en dehors de tout profil de DMP Compatibilité et ne fait pas dans ce cas l'objet d'une homologation par l'ASIP Santé. Comment puis-je prendre connaissance du processus d'homologation de la DMP Compatibilité ? Le processus d’homologation de la DMP Compatibilité est décrit sur le site de l’ASIP Santé : http://esante.gouv.fr/actus/dmp/processus-d-homologation-a-la-dmp-compatibilite-actualise
Nous vous conseillons également la lecture détaillée du contrat éditeur de l'ASIP Santé pour la DMP Compatibilité.
Quelles sont les transactions qu'un logiciel de professionnel de santé doit implémenter pour pouvoir être homologué DMP-compatible ?
L’homologation de la DMP Compatibilité est accordée selon les modes d'authentification (cf. § 3.1 du DSFT) et les profils choisis par le candidat ; ces notions sont décrites aux § 2.5.3 et 3.4 du DSFT des interfaces DMP des LPS. Un « Profil LPS » est constitué d’un ensemble de transactions fonctionnellement liées entre elles et devant être implémentées conjointement. Pour chacun des profils de DMP Compatibilité, certaines transactions sont requises pour l'homologation, d'autres sont optionnelles. L'homologation porte sur l'ensemble des transactions requises du profil ainsi que sur les transactions optionnelles que le candidat a décidé d'intégrer le cas échéant. Le candidat peut intégrer les différents profils à son rythme, en passant plusieurs homologations pour des profils différents. A chaque nouvelle homologation la totalité des transactions fait l'objet de vérifications par l'ASIP Santé. Mon LPS peut fonctionner sous différents systèmes d’exploitation : dois-je passer une homologation spécifique pour chaque environnement ? La constitution d’une famille de produits (voir l’article 3 du contrat éditeur pour la DMP Compatibilité), qui peut par exemple comporter plusieurs logiciels s’exécutant chacun sous un système d’exploitation différent, est laissée à la libre appréciation du candidat, en fonction de l’homogénéité du code utilisé dans les différents logiciels pour assurer l’interfaçage avec le SI DMP. Le contrat éditeur pour la DMP Compatibilité ne contraint pas à passer une homologation spécifique pour couvrir l’ensemble des systèmes d’exploitation supportés par les logiciels de la famille de produits. Cependant, dans la mesure où pour une famille de produits comportant plusieurs logiciels les tests sont en pratique réalisés avec un seul d’entre eux, l’ASIP Santé recommande aux candidats se situant dans ce cas de figure de réaliser eux-mêmes des tests spécifiques pour chacun des systèmes d’exploitation supportés, voire de passer une homologation spécifique pour chacun des logiciels.
Quelles sont les modalités de nouveau passage en homologation en cas d’ajout de transactions optionnelles à un profil déjà homologué ? Le candidat devra exécuter les tests spécifiques aux nouvelles transactions et décrire la manière dont il assure le respect des exigences de DMP Compatibilité non vérifiées par des tests pour ces transactions ; il sera également demandé au candidat d’exécuter des tests de vérification de non régression pour les transactions déjà homologuées. Quelles sont les modalités de nouveau passage en homologation en cas d’ajout d’un deuxième mode d'authentification pour un LPS déjà homologué ? Le candidat devra exécuter les tests spécifiques au nouveau mode d’authentification et décrire la manière dont il assure le respect des exigences de DMP Compatibilité non vérifiées par des tests pour le ou les profils de DMP Compatibilité choisis et le nouveau mode d’authentification mis en œuvre ; il sera également demandé au candidat d’exécuter des tests de vérification de non régression pour les transactions déjà homologuées et le mode d’authentification précédemment développé. Quelles sont les modalités de nouveau passage en homologation en cas de modification du LPS ? Le contrat éditeur pour la DMP Compatibilité précise dans son article 3 que dans le cas où l’un des produits (ou plusieurs produits) qui constitue la famille évolue, il est laissé à la libre appréciation du candidat de présenter une nouvelle version de la même famille de produits au processus d‘homologation de la DMP Compatibilité.
Est-il possible de se faire homologuer en implémentant dans le LPS uniquement la transaction TD0.9 d'accès Web PS contextuel ? Non : l'implémentation de la seule transaction TD0.9 ne permet pas de bénéficier d'une homologation à la DMP Compatibilité. La transaction TD0.9 est proposée pour accéder : à des fonctions non implémentées dans le LPS sous forme de Web Services, à certaines fonctionnalités accessibles uniquement en mode Web PS (exemples : blocage d'un PS sur un dossier ; consultation des traces). Elle permet aux éditeurs de cadencer leur développement, par exemple en n'intégrant dans un premier temps que les transactions requises d'un profil. Pour tester l’intégration des services DMP décrits dans le Dossier des Spécifications Fonctionnelles et Techniques des interfaces DMP des LPS, existe-t-il une plateforme de tests DMP ?
Un environnement de tests à l'image du système d'information DMP est prévu pour les candidats ayant signé le contrat éditeur de l'ASIP Santé pour la DMP Compatibilité ; voir à ce sujet le § 2.5.1 du DSFT des interfaces DMP des LPS et le §6.2 du contrat éditeur pour la DMP Compatibilité.
Alimentation de DMP : point de vigilance sur les données de tests et les données réelles en production. Le candidat à la DMP Compatibilité doit être vigilant sur le peuplement des champs relatifs à « l’organisation pour le compte de laquelle le document a été produit » (structure dans laquelle exerce le professionnel de santé : Identifiant_Structure, Issuer du VIHF par exemple, authorInstitution du XDS, Custodian du CDA, etc.). Notamment le candidat doit s'assurer que ces données ne sont pas codées en dur et sont correctement variabilisées. 2	Questions relatives aux environnements de tests Afin d’accéder à la plateforme de test du SI DMP, il m’est nécessaire d’utiliser un certificat émis par l'IGC CPS (CPS ou certificat serveur) :
pour l’authentification directe, quelle est la procédure pour obtenir des cartes CPS de Test ? pour l’authentification indirecte, quelle est la procédure pour obtenir et utiliser des certificats serveurs émis par l'IGC CPS (certificat AC-Classe-4) ?
Vous trouverez l’essentiel de la démarche et les documents téléchargeables sur http://integrateurs-cps.asipsante.fr/
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) », commander pour la toute première fois, un kit CPS de référence. Pour cela :
1)	Téléchargez :
o	le Contrat éditeurs, o	le Bon de commande kit CPS. 2)	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 API-CPS», accompagnés de l'Annexe 3 remplie, o	le «Bon de commande kit CPS» complété et signé, o	le règlement de la commande. En retour l’ASIP Santé :
1)	vous adresse par courrier un exemplaire du « Contrat de diffusion des logiciels API-CPS (éditeurs) » signé par les deux parties, 2)	vous envoie un courrier recommandé ou un mail (au(x) correspondant(s) désigné(s) sur le bon de commande) : un identifiant/mot de passe qui donne un accès aux services contrôlés du serveur et permet plus spécifiquement de télécharger les bibliothèques d'API-CPS ainsi que les documents d'aide à l'intégration des services CPS ; vous pourrez ainsi télécharger les diverses bibliothèques d'API-CPS dans les environnements d'exploitation que vous désirez intégrer et obtenir leurs versions successives ; les évolutions du système CPS vous seront régulièrement communiquées,
3)	vous livre le(s) matériel(s) correspondant(s) à votre commande (jeu de cartes de test, dispositif de lecture),
4)	à réception des matériels et des API-CPS, vous retournerez à ASIP Santé/Service Editeurs le procès verbal de remise du kit CPS.
L'utilisation des cartes et certificats CPS de production sur les environnements de tests DVx est-elle autorisée ? Non, ces éléments ne peuvent pas être utilisés sur les environnements de tests de la DMP Compatibilité. Nous vous recommandons de vous munir d'un jeu de cartes CPS de test à commander auprès de l'ASIP-CPS : vous aurez en effet besoin de plusieurs cartes CPS de test pour passer l'homologation en authentification directe.
Si vous ne mettez en œuvre que l'authentification indirecte, il faut vous équiper d’un certificat classe-4 de test lié à votre carte CPA de test (procédure décrite par ailleurs dans cette FAQ). Nous possédons déjà des cartes CPA rattachées à notre organisation ; l’utilisation de cartes CPA est-elle autorisée sur le SI DMP ? Non, ces cartes ne sont pas autorisées sur le SI DMP (seules les CPS et les CPE le sont). Quelle autorité de certification faut-il importer dans le LPS ? L'autorité de certification à importer dans le magasin de certificats pour un LPS est l'AC-CLASSE-4 de l’IGC CPS : il s’agit de l'autorité de certification du certificat des serveurs de développements/validation éditeurs et de production des interfaces LPS. Voir : http://annuaire.gip-cps.fr onglet « Autorités de certification », menu « GIP-CPS », sous menu « AC-CLASSE-4 ». Comment valider le certificat du serveur DMP ? Le certificat serveur des interfaces DMP pour les LPS doit être validé conformément au DSFT (chapitre 6.1.2).
L'ajout du certificat du serveur DMP comme autorité de confiance dans le LPS (ou dans le système d’exploitation) constitue une mauvaise pratique - même sur les serveurs de tests DVx - car, à terme lors du renouvellement du certificat du serveur DMP, cette mesure obligerait à mettre à jour tous les LPS ou postes de PS (voir entrée précédente de cette FAQ sur l'autorité de certification à importer dans le LPS). Errata du DSFT au chapitre 6.1.2 (empreinte AC Classe-4 erronée)
Le DSFT 1.0.1 indique une empreinte numérique erronée pour l'AC Classe-4 : "04 ea fc 58 d5 09 a9 4c 52 10 b2 a0 d1 20 97 d4 db be 33 65" (il s'agit pour mémoire de l'empreinte de "l'ancienne" AC Classe-4 expirée fin 2008) ; or dans l'annuaire ASIP-CPS, onglet « Autorités de certification », menu « GIP-CPS », sous menu « AC-CLASSE-4 », l'empreinte du certificat téléchargé est la suivante : "‎31 82 46 2f 18 0a e8 80 b6 f4 3f a0 40 ce c0 25 dc 2f 20 42" (ceci est l’empreinte correcte).
Lorsque cela est possible, nous conseillons de ne pas utiliser les valeurs des empreintes directement, mais d'intégrer les fichiers "cer" (ou autre format) de l'AC Classe-4 directement en paramètre de la librairie de connexion TLS, ou dans le magasin de certificat des autorités de certification autorisées du système d'exploitation si cette librairie l'utilise (solution plus simple pour les API .Net de Microsoft par exemple). En java il est possible d'importer les autorités de certification autorisées dans un magasin dit "truststore" (fichier .jks), sous certaines librairies C (CUrl par exemple) il est possible de passer ce fichier en paramètre, etc...
Comment vérifier la révocation du certificat du serveur DMP et où trouver les CRLs ASIP-CPS ?
Il est rappelé que 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, car les CRLs GIP-CPS sont mises à jours en totalité une fois par jour - des delta CRLs existent néanmoins pour les services souhaitant plus de précision - ) , 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).
Les CRLs ASIP-CPS sont disponibles via le protocole LDAP sur l'annuaire ASIP-CPS (annuaire.gip-cps.fr) ou via HTTP à l'adresse suivante (mises à jour toutes les nuits) : http://annuaire.gip-cps.fr/crl/ (CRL réelle) et http://annuaire.gip-cps.fr/crl/test/ (CRL test)
Modalités de tests avant mise en production
Pour les candidats dont une ou plusieurs familles de produits sont homologuées, l’ASIP Santé met à disposition des environnements de formation afin de leur permettre de tester le raccordement au DMP depuis un environnement de test de leurs clients (par exemple : réalisation de tests fonctionnels suite à l'implémentation d'une version DMP Compatible dans un établissement). Quatre environnements sont disponibles ; ils reproduisent strictement le service DMP et ses mécanismes de sécurité, pour les accès PS (par LPS et navigateur) et patients. Les caractéristiques de ces environnements (notamment la fréquence de réinitialisation des données de tests) sont décrites sur la page www.dmp.gouv.fr/professionnel-de-sante/utiliser-le-dmp/vous-former-au-dmp/utiliser-le-dmp-avec-la-base-ecole ; il n’y a pas besoin de déclaration préalable d’adresses IP pour y accéder et le n° d’homologation (champ LPS_ID_HOMOLOGATION_DMP du VIHF) fourni pour les tests peut y être utilisé. Seules des données de tests doivent être utilisées sur les environnements de formation. Il est rappelé ici que des cartes Vitale de tests ou de démonstration ne doivent pas être utilisées sur l’environnement DMP de production, exclusivement destiné au traitement de données réelles. Carte Vitale : comment se procurer une carte vitale de démonstration ?
Pour se procurer une carte Vitale de démonstration, il faut en faire la demande auprès du GIE SESAM- Vitale, à l'adresse mail suivante : diffusion@sesam-vitale.fr Tous les détails se trouvent sur cette page :
http://www.sesam-vitale.fr/offre/industriel/sesam-vitale/facturation-sv_developper_carte-demo.asp 3	Questions techniques d’ordre général (toutes transactions)
A qui puis-je m'adresser pour obtenir une racine d'OID ? Vous pouvez par exemple vous adresser à l'AFNOR, qui gère une branche d'OID identifiée ""1.2.250.1"" (voir DSFT des interfaces DMP des LPS au § 4.1.1). Il existe par ailleurs une branche d’OID « 2.25 » permettant de générer des OID à partir d’UUID ; il est possible d'utiliser la procédure d'enregistrement sur le repository oid-info, afin de vous assurer que l'identifiant généré est bien unique (certains algorithmes permettent des collisions d'UUID - avec des probabilités cependant très faibles). A titre d'information complémentaire, l’AFNOR nous indique que : Le code OID peut revêtir les formes suivantes:
numérique : 571.38 EUR HT, soit 683.38 EUR TTC (TVA 19 ,6%), numérique et alphanumérique : 734.02 EUR HT, soit 877.88 EUR TTC (TVA 19,6%) qui permet d’ajouter, en complément, la valeur de l’attribut « nom d’organisation ».
note : la valeur alphanumérique pour une racine d’OID n’est pas acceptée dans les normes HL7 et XDS, et par conséquent pas non plus par le DMP.
(les tarifs sont indiqués à titre indicatif et valables en 2011, ils pourront être réévalués à partir du 1er janvier 2012)
Les demandes peuvent être adressées à la personne en charge des enregistrements et de gestion de registre d'OIDs pour la France : AFNOR -DTEC
L'exigence de la DMP Compatibilité porte sur l'unicité des identifiants uniques d'objets générés par le LPS : chaque identifiant généré doit être mondialement unique. Un exemple de méthode de génération d'OID est proposé dans le DSFT des interfaces DMP des LPS, mais 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 (nous ne connaissons ni le nombre d'objets gérés dans les logiciels des candidats à la DMP Compatibilité, ni leur cycle de vie). Pourquoi certaines données renvoyées par le SI DMP comportent-elles la chaine de caractères "&amp;" (le mot de passe patient par exemple) ?
Les interfaces LPS utilisent des messages SOAP (donc XML) ; les caractères spéciaux du XML devraient donc être automatiquement décodés par la librairie SOAP utilisée (il est nécessaire de gérer correctement les caractères spéciaux XML) ; par exemple dans le message de retour de la transaction de création du compte internet patient, le mot de passe fourni est susceptible de comporter un caractère & (encodé &amp; dans le XML) qui doit être décodé pour l'alimentation du formulaire PDF contenant les paramètres d'accès du patient à son compte internet. Ce décodage doit être fait notamment pour les caractères : & : &amp;
Note : le site https://testssl.asipsante.fr/ de l'ASIP Santé ne fait pas mention de l'opposition du certificat d'authentification de la carte. Quels sont les grands principes de la signature numérique à maîtriser (VIHF et lots de soumission) ? Le candidat doit s'assurer de la maîtrise du processus de signature électronique pour pouvoir s'engager dans la DMP Compatibilité. Il est notamment nécessaire de comprendre :
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 et de la maîtriser ; il est attendu du candidat à la DMP Compatibilité qu’il soit en capacité à émettre des signatures électroniques, mais également à les valider et à effectuer lui-même 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 (le candidat 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/ )).
Une anomalie de signature peut être notamment due aux facteurs suivants :
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. Nous souhaitons afficher dans l’IHM du LPS plus d’informations sur les PS (auteurs des documents médicaux, ou PS retournés par la transaction « TD1.6 : Liste des PS autorisés / bloqués »), comme par exemple les différentes situations d'exercice d'un PS (nom structure, adresse, code postal, téléphone, ...). Le Web PS affiche ces informations (menu : Gestion DMP -> Gestion des autorisations -> Fiche Professionnel de santé) : est-il possible de récupérer ces informations supplémentaires via la requête TD1.6 ou via une autre requête sur le SI DMP ? Le Web PS réalise une requête sur l'annuaire ASIP-CPS pour afficher ces informations complémentaires sur le PS. L'interface LPS du DMP ne propose pas cette fonctionnalité. L’information peut toutefois être récupérée par le LPS en interrogeant directement l'annuaire ASIP-CPS. Il est à noter que le futur Référentiel des Acteurs Santé Sociaux (RASS) va permettre à terme l'accès à l’information sur l'ensemble des professionnels de santé (l'annuaire ASIP-CPS actuel ne fournit que les informations sur les porteurs de cartes CPx) et leurs structures associées.
Identification des PS : comment réaliser le transcodage ADELI -> RPPS ? La procédure de transcodage est décrite dans le document CI-SIS_Annexe_Sources_Donnees_Personnes_et_Structures_v1.0.1.pdf au chapitre 6.6.3 et précise que la notation d’un caractère hexadécimal est entre quotes, pour ne pas confondre ‘39’ (hexadécimal) et la valeur décimale 39 : 1 caractère ASCII = 1 octet hexadécimal.
Pour corriger le code G12 en le codant sur 3 caractères, X est un octet hexadécimal contenant une valeur ≥ '0A' (donc ≥ 10 décimal) qu'il faut convertir en ‘3x 3y’.
La conversion peut donc s’effectuer de la manière suivante :
X, x et y sont des octets hexadécimaux
y = (X) mod 10
x = (x - y) / 10
'3x' = '30' + x (= 1 caractère ASCII avec la valeur '31' ou '32')
la valeur d'origine du code G12 étant entre 0 et 255 et la conversion ne se faisant que si la valeur du code est entre 100 et 255
'3y' = '30' + y (= 1 caractère ASCII avec une valeur entre '30' et '39')
Connexion : lors de l’exécution du code de test fourni (code exemple), l’erreur suivante est remontée : « [3636] Exception in the HttpWebRequest#44415434:: - Le délai d'attente de l'opération a expiré » Il s'agit vraisemblablement d'un problème de connexion réseau ; les pistes d’investigations sont les suivantes :
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).
Connexion TLS Mutuelle : problème de connexion au tout début lors de l'établissement du tunnel TLS, la réponse du serveur est « Handshake failure » 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 6.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). VIHF : le DMP renvoie une SOAP:Fault avec le message d’erreur suivant : « Erreur : DMPInvalidData;Le sujet de l'assertion (3/00B1022322) n'est pas un descendant de l'identifiant de structure du certificat : 10B0011797 »
Exemple d’erreur : DMPInvalidData;Le sujet de l'assertion (3/00B1022322) n'est pas un descendant de l'identifiant de structure du certificat : 10B0011797
DMPInvalidData;Le sujet de l'assertion (1420784878/01312235) n'est pas un descendant de l'identifiant de structure du certificat : 1420784878
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). Le candidat doit consulter le document CI-SIS_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).
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. Le SI DMP contrôle la cohérence entre l'identifiant structure et le NameID du VIHF : si l'identifiant commence par 0,2,8,9 (numéro de personne pris en carte CPx ou annuaire national) : contrôle du bon format de l'identifiant fourni, si l'identifiant commence par 1,3,4,5,6 : contrôle que l'identifiant dans NameID est bien "inclus" dans celui de la structure (« descendant » de la structure) ; attention au premier chiffre qui change :
structure commençant par 1 (FINESS) => 3 pour id de personne (FINESS+id interne), structure commençant par 2 (SIREN) => 4 pour id de personne (SIREN+id interne), structure commençant par 3 (SIRET) => 5 pour id de personne (SIRET+id interne).
VIHF : le DMP renvoie l’erreur « DMPInvalidData : xxxxxx : Structure introuvable »
Le candidat doit 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. VIHF : le DMP renvoie l’erreur « Secteur d'activité non correspondant » 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). 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).
Le candidat doit envoyer dans le VIHF les données associées à la structure représentée par le certificat présenté. VIHF : le DMP renvoie l’erreur : « DMPInvalidData : xxxxxx : Profession non correspondante » Exemple d’erreur :
Code Erreur: DMPInvalidData
Message Erreur: Impossible d'effectuer un test d'existence : Profession non correspondante 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. Afin de renseigner correctement les différents champs du VIHF, l'éditeur doit consulter les documentations s'y rapportant : DSFT chapitre 6, 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. VIHF : le DMP renvoie l’erreur « DMPInvalidData : xxxxxx : aucune spécialité pour médecin » Exemple d'erreur :
Message Erreur: impossible d'effectuer un test d'existence : aucune spécialité pour médecin
Cette erreur provient du fait que 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) : l'éditeur pourra consulter à ce titre l'entrée suivante de cette FAQ : « Identification des PS : comment réaliser le transcodage ADELI -> RPPS ? ». VIHF : le DMP renvoie l’erreur « DMPInvalidData : Le PS n'a pas les droits d'accéder à ce dossier : PS et Structure non lies ». Cette erreur survient lorsque le champ Identifiant_Structure du VIHF n'est pas renseigné correctement par rapport à la carte CPS utilisée. Afin de renseigner correctement les différents champs du VIHF, l'éditeur doit consulter les documentations s'y rapportant : DSFT chapitre 6, CI-SIS_Couche_Transport_Volet_Synchrone_client_lourd_v1.0.1.pdf, CI-SIS_Annexe_Sources_Donnees_Personnes_et_Structures_v1.0.1.pdf.
Les données des cartes CPS sont vérifiées par le serveur DMP via l'annuaire ASIP-CPS. VIHF : le DMP renvoie l’erreur « DMPInvalidCertificate »
Si l'erreur suivante est remontée par le SI DMP (dans une SOAP:Fault) :
DMPInvalidCertificate;Le certificat ayant signé le VIHF est invalide : Not a valid signature certificate 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 DVx) é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 [
S/MIME (signature) : NetscapeCertType [
4	Questions relatives aux fonctions de création et gestion administrative du dossier Quel est le rôle des médecins traitants dans le DMP ?
Les médecins traitants participent à la mise en place et la gestion du DMP. Le patient peut déclarer plusieurs médecins traitants dans son DMP. La notion de médecin traitant dans le DMP n'a pas de lien avec le niveau de remboursement des soins. Le statut de médecin traitant dans le DMP confère au médecin concerné des fonctions spécifiques : bloquer l'accès d'un professionnel de santé au DMP d'un de ses patients ; accéder aux documents masqués dans le DMP de ses patients et, le cas échéant, être en capacité de les assister en cas d'éventuelle volonté de démasquage d'un document masqué ; consulter l'historique des actions menées dans le DMP de ses patients. Note : les informations qui figurent dans le DMP ne valent pas déclaration de médecin traitant auprès de l’assurance maladie et ne dispensent pas le patient d’effectuer les démarches habituelles pour déclarer un médecin traitant. Lorsque le LPS lit les données de la puce de la carte Vitale du patient, il calcule et stocke l'INS-C du patient dans sa base de données. Est-il possible de créer le DMP du patient avec l'INS-C calculé et stocké par le LPS ou faut-il calculer à nouveau l’INS-C (par exemple cas d'un patient qui a initialement refusé la création de son DMP à l’admission mais qui change d'avis une fois hospitalisé) ?
Il est fortement recommandé de réaliser la lecture de la carte Vitale du Patient au moment de la création de son DMP (voir les règles de bonne pratique figurant au § 7.1.2.4 du DSFT). 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).
Comment renseigner dans la transaction de création de DMP les autorisations d’accès en mode « bris de glace » et en mode « urgence » ? Le DSFT précise au § 7.2.4 que message HL7 de création de DMP permet de manipuler les concepts « d’opposition au mode bris de glace » et « d’opposition du patient au mode centre de régulation ». Attention : 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 la trame envoyée au SI DMP ; en effet la question posée ans l’IHM peut parler d’autorisation alors que la trame parle d’opposition, il faut donc s’assurer que la réponse à la question posée dans l’IHM est fidèlement retranscrite dans la trame) ; par exemple :
si la question posée dans le LPS est : « Si vous appelez le SAMU (ou tout médecin régulateur de centre 15), autorisez-vous le médecin à accéder à votre DMP ? » et que la réponse est positive alors dans la trame OPPOSITION_ACCES_URGENCE est à « false »,
si la question posée dans le LPS est : « Si vous êtes dans un état comportant un risque immédiat pour votre santé, autorisez-vous tout professionnel de santé à accéder à votre DMP ? » et que la réponse est négative alors dans la trame OPPOSITION_BRIS_DE_GLACE est à « true ».
Cette remarque est également valable pour les transactions de réactivation de DMP et de mise à jour des données administratives du DMP d’un patient.
Les dates de naissance au format « lunaire » sont-elles acceptées (champs date de naissance administrative et champ date de naissance lue en carte Vitale) ? Une date lunaire est possible en carte Vitale (mois > 12 et/ou jour > 31). Il est possible de corriger la date lunaire passée dans patientPerson/birthTime/@value en proposant aux utilisateurs de corriger cette date de naissance lorsqu'ils créent le patient dans le LPS) ; en revanche il ne faut surtout pas permettre la modification de la date de naissance lue en carte Vitale (contactParty/contactPerson/birthTime/@value) : celle-ci doit être transmise au DMP sous sa forme « lunaire », telle que lue dans la carte Vitale (comme d’ailleurs dans le cas d‘une date de naissance au format non « lunaire »), au bon format AAMMJJ. Comment renseigner la date de naissance des données administratives dans le cas d'une date "lunaire" lue dans les données de la puce de la carte Vitale ? Dans le cas où la date de naissance lue dans les données de la puce de la carte Vitale est au format lunaire (par exemple un mois > 12 ou un jour > 31) et que cette date de naissance sert également dans le LPS à pré-remplir la date de naissance des données administratives, l'ASIP Santé recommande d'afficher un message à l'utilisateur lui proposant de convertir la date administrative dans un format de date « standard ». L'adresse du patient est-elle obligatoire dans le DMP ? L'adresse du patient n'est pas obligatoire dans le DMP, dans le sens où "le patient n'est pas obligé de la donner" ; le LPS doit donc la gérer, mais elle peut être laissée vide par le PS. Errata du DSFT 1.0.1 aux chapitres 7.2.4 « données patient » et 7.2.5 « représentant légal » :
Le DSFT comporte les anomalies documentaires suivantes :
au chapitre 7.2.4 :
- les valeurs correctes pour le champ civilité sont « M, Mme ou Mlle »
-	la taille maximale du complément d’adresse du patient est de 38 au lieu de 100
au chapitre 7.2.5 :
- la taille maximale de l’email du représentant légal est de 64 au lieu de 20
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
Désignation : nom usuel ou nom d’usage
Carte Vitale V1ter
Désignation : nom de famille ou nom patronymique
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'
Composant 1 de PID-5 lorsque composant 7 de PID-5 = 'D'
Accès web patient DMP
Facultatif Désignation : Nom de naissance
Désignation : Nom d’usage
Accès web PS DMP
Désignation : Nom de naissance
Obligatoire Désignation : Nom d’usage
Le nom patronymique lu sur la carte Vitale doit-il être transmis dans la transaction de création de DMP ? En création de DMP, le nom patronymique - ou nom de famille du bénéficiaire - (contactPerson/name/family[@qualifier=’BR’] dans le message HL7) doit impérativement être fourni si et seulement s’il est présent dans les données de la carte Vitale (d’où sa cardinalité à [0..1], voir § 7.2.4 du DSFT des interfaces DMP des LPS). Les OTP email et téléphone portable semblent maintenant liés aux champs du même nom des données administratives, notamment lors d’une transaction de mise à jour des données administratives (TD1.3b ) ?
En effet, les données email et téléphone portable des données administratives sont liées aux canaux OTP email et téléphone portable, s’ils existent. Il s’agit d’une évolution du SI DMP, qui permet la synchronisation de ces deux champs avec les valeurs d’OTP, afin que les données du patient soient cohérentes. Lors d’une mise à jour des données administratives (TD1.3b), une modification de l’email ou du téléphone portable est répercutée sur l’OTP correspondant s’il existe. De même, une modification du canal OTP (TD1.5b) email ou téléphone portable est répercutée sur la donnée administrative correspondante.
Comment traiter des problèmes de génération d’objets à partir du WSDL GestionDossierPatientPartage.wsdl sous Java ? Nous ne fournissons pas de support concernant le code source du LPS, néanmoins voici à titre d'exemple une script exécuté avec wsdl2java sous JDK 1.6 permettant de générer les objets JAXB : setLocal set PROJECT_HOME=c:\workspace\kit-editeur set CXF_HOME=c:\applications\apache-cxf-2.2.5\ set PACKAGE_BASE=com.package.exemple set PATH=%PATH%;%CXF_HOME%\bin set WSDL_HOME=%PROJECT_HOME%\src\main\resources\wsdl call wsdl2java -exsh true -autoNameResolution -p "urn:hl7-org:v3"=%PACKAGE_BASE%.hl7v3.NE2009 -p "asip:ci-sis:gdp:2010"=%PACKAGE_BASE%.hl7v3.NE2009 -p "asip:ci-sis:gdp:2010:choice"=%PACKAGE_BASE%.hl7v3.NE2009 -d %PROJECT_HOME%\src\main\java\ %WSDL_HOME%\GestionDossierPatientPartage.wsdl endLocal
5	Questions sur les fonctions d’alimentation
Comment appréhender les principaux concepts du profil Xds.b ?
L’ASIP Santé a produit un complément pédagogique du volet « Service de partage de documents de santé » du cadre d’interopérabilité des systèmes d’information de santé visant à uniformiser les niveaux de compréhension du profil XDS.b entre les équipes de maîtrise d’ouvrage et les équipes de maîtrise d’œuvre des projets de systèmes d’information de santé partagés en France. Ce document présente les concepts associés aux transactions d’alimentation et de mise à jour d’un système de gestion de documents partagés de santé. Il est accessible dans la liste des documents associés de la page dédiée sur le site esante.gouv.fr
Comment générer des identifiants uniques d'objet (OID / uniqueId) ? Un identifiant unique doit être mondialement unique par instance d'objet, c'est-à-dire que pour chaque type d'objet (document, lot, patient...) il est nécessaire de pouvoir générer un identifiant unique. Une méthode possible consiste à utiliser un OID racine et à le décliner par instance de LPS, puis par type d'objets, puis par instance d'objets). Le respect d’une exigence sur l'unicité des uniqueId est demandé dans le cadre de l'homologation. Que doit-on mettre dans les identifiants des objets ebXML (ExtrincicObject, RegistryPackage, Classification, Association) ? Il faut respecter le profil IHE XDS.b pour les identifiants des objets ebXML de la requête ProvideAndRegisterDocumentset-b : soit en générant des uuid par vous-même (préfixés par urn:uuid) avec un algorithme qui assure l'unicité de cet uuid, soit en générant des identifiants internes à la requête avec des "compteurs" internes, comme nous l'avons fait dans notre exemple : document01, submissionSet01, cla1, cla2, assoc1 assoc2, etc. ; ces identifiants - s'ils ne sont pas au format uuid - seront regénérés en uuid par le serveur lors du stockage des objets ebXML ; nous avons dans notre exemple nommé les identifiants internes avec un préfixe représentatif du type d'objet ebXML qu'ils identifient (permet de faciliter le débogage). Limitation : dans le cas où vous souhaitez générer l'entryUUID vous-même (format uuid), il faut savoir qu'en cas de masquage / démasquage / mise en visibilité du document par un autre PS (médecin traitant par exemple), l'entryUUID de la version de métadonnées change : il s'agit d'une nouvelle instance des métadonnées du document, donc avec un nouvel identifiant de métadonnées (entryUUID) ; en conséquence de quoi votre uuid généré dans votre LPS (si vous l'avez stocké comme référence) ne serait plus valable en cas de dépublication/masquage/archivage à partir de celui-ci (le DMP renverrait une erreur). Un Query GetDocuments (TD3.1) permet de récupérer la référence (entryUUID) de la dernière version des métadonnées du document.
Quel format de date est attendu dans les différentes transactions avec le DMP (GMT ou heure locale) ?
Alimentation en documents : 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 (champs XDS creationTime, serviceStartTime, serviceStopTime et les éléments correspondant dans le CDA). Les champs date/heure XDS doivent être codés en UTC (Universal Coordinated Time) et ceux du CDA correspondant en heure locale (incluant le décalage horaire (timezone) par rapport à UTC (GMT) dans le cas où le LPS gère des heures sur ces champs dates - cf chapitre 3.2.3 Représentation du temps du document CI-SIS_Couche_Contenu_Volet_Structuration_Minimale_v1_0_1_1.pdf). Le LPS devra donc translater les dates du CDA en UTC dans le cas où il les utilise pour alimenter les métadonnées XDS. Dates de naissance : les dates de naissance sont au format AAAAMMJJ ou AAMMJJ, sans précision de timezone (date du lieu de naissance). Quels sont les contrôles effectués par le SI DMP au niveau des dates lors de l'alimentation d'un document ? Les contrôles suivants sont effectués côté DMP : la date de signature du lot (creationTime du doc DSG) est postérieure à la création des documents constituant le lot et antérieure (ou égale) à la date d'envoi du lot (submissionTime) (extrait du CI-SIS volet Partage de Document § 4.2.2). 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 le lot puis le signe 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). Comment calculer le champ hash d'un document ? Pourquoi le SI DMP trouve un résultat différent du mien ?
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]).". Le LPS doit appliquer la méthode indiquée dans le CI-SIS : dans le cas où 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é ; si le document est signé, se référer au CI-SIS.
Comment alimenter les champs AuthorRole XDS et author/functionCode CDA ? Les champs authorRole XDS et functionCode CDA sont liés, mais l'un ne porte qu'un libellé libre (authorRole XDS) et l'autre (functionCode CDA) nécessite un codage code/libellé (dans une nomenclature) : le CI-SIS n'impose pas de nomenclature pour functionCode, celle-ci peut-être locale. Ces deux champs sont optionnels ; nous recommandons pour le moment de ne pas les utiliser.
Comment alimenter le champ 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). Dans le cas d'un LPS, il ne faut pas mettre uniquement l'INS-C : l'INS-C est déjà renseigné dans le champ patientId et ne doit être ajouté dans sourcePatientId que dans le cas où patientId contiendrait l'INS-A (voir le chapitre 3.4.29 « sourcePatientId » du CI-SIS Volet Partage de documents de santé v1.0.1).
Attention : ceci n'est pas valable pour le champ sourcePatientId des métadonnées du document de Signature DSG (voir le chapitre 4.2.2 du CI-SIS Volet Partage de documents de santé v1.0.1 pour le remplissage de ce champ dans ce cas). Si patientId contient un INS-C, il n'est pas nécessaire de l'ajouter également dans sourcePatientId ; nous attirons l'attention sur le fait qu'un "change proposal" sur IHE XDS.b restreint le sourcePatientId à la cardinalité [1..1] dans la future version 1.2 du CI-SIS : il est prudent de ne renseigner que l'identifiant patient local dans le LPS source pour sourcePatientId.
Si le champ sourcePatientId comporte l'identifiant du patient local dans le LPS source (voir remarque ci-dessus), il doit être spécifié dans le CDA en plus de l'INS-C avec comme root l'OID de la racine des identifiants du patient dans l'instance du LPS source. Comment alimenter le champ sourcePatientInfo ?
Dans la documentation du Cadre d’Interopérabilité des Systèmes d’Information de Santé (CI-SIS), le composant 7 du PID-5 peut prendre les valeurs « D » et « U », mais également « L » dans l’exemple : que signifie cette valeur « L » ?
Le « L » signifie « Nom de naissance » (Legal name) ; cette information est présente dans le document IHE France ITI annexe N (ITI TF-2:N.FR: Constraints on common HL7 data types for ITI Integration Profiles in France, disponible sur le site d'Interop’Santé (http://www.interopsante.org ) au § N.10.5XPN-7. Une mise à jour future du CI-SIS clarifiera ce point :
PID-5 Composant 7, requis : Type de nom.
« L (legal name) » : nom de famille,
« D (Display name)» : nom d'usage,
« U (Unspecified)» : non spécifié, la source ne sait pas typer le nom.
Plusieurs occurrences peuvent être présentes, notamment pour véhiculer le nom d'usage et le nom de famille du patient.
Comment alimenter le champ contentTypeCode et que représente cette balise ? Le CI-SIS, dans le Volet Partage au paragraphe 3.5.8 indique qu’il s'agit d'un champ du lot de soumission. Le jeu de valeurs associé est fourni dans le CI-SIS (voir le fichier ASIP-SANTE_contentTypeCode_20101104.jv). Il n'y a pas d'équivalent à ce champ dans le CDA.
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-SIS_Annexe_Sources_Donnees_Personnes_et_Structures_v1.0.1.pdf au chapitre 4.1 « contentTypeCode » donne une indication pour 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.
Comment alimenter le champ practiceSettingCode et que représente cette balise ? Est-il possible de l’alimenter à partir des données de la carte CPS ? Le document CI-SIS_Annexe_Sources_Donnees_Personnes_et_Structures_v1.0.1.pdf, au chapitre "4.4 practiceSettingCode", fournit les directives pour renseigner ce champ et le fichier ASIP-SANTE_practiceSettingCode_20101104.jv indique les valeurs possibles ainsi que le libellé associé à chaque code. Il est nécessaire d’adapter les valeurs des champs aux cas d'usage réels des utilisateurs PS, notamment pour practiceSettingCode qui ne peut pas être déduit de la carte CPS. Une possibilité est de proposer au PS de choisir une valeur par défaut lors de la déclaration de sa situation d'exercice dans le logiciel ; il est nécessaire d’assurer la cohérence avec la modalité d'exercice (healCareFacilityTypeCode) : par exemple un "cabinet individuel" (healCareFacilityTypeCode) ne peut a priori pas être en "établissement de santé" (practiceSettingCode). Le practiceSettingCode qui semble le plus adapté aux "cabinet individuel" est "Ambulatoire" (médecin libéral), mais d'autres codes sont envisageables en fonction des usages du LPS. Quelle est la relation entre le typeCode et le classCode d’un document ? Il y a une notion de subsomption entre le typeCode et le classCode à respecter : un type de document fait partie d'une classe de documents. Le fichier ASIP-SANTE_X04_<aaaammjj>.tab du CI-SIS fournit la subsomption entre typeCode et classCode (voir aussi le fichier CI-SIS_Annexe_Nomenclatures_Métadonnées_Documents_v1.0.1, tableau "Classification et typologie des documents : complément informatif" page 4). Quelle taille maximale le SI DMP accepte-t-il pour les champs "titre" et "commentaires" des documents et des lots de soumission ? Pour les documents, la taille maximale du champ "titre" est celle définies dans la norme XDS.b (voir IHE ITI-TF volume 3, dans "Table 4.1-5 Document Metadata Attribute Definition"), à savoir 128 caractères : "Max length, 128 bytes, UTF-8".
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. Le DMP limite les champs "commentaires" des lots de soumission et des documents à 1000 caractères.
Comment effectuer un remplacement de document sur le DMP ? 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).
Cela aura pour effet de remplacer dans le registre (registry XDS) l’ancienne fiche du document par la nouvelle dont la métadonnée availabilityStatus a la valeur « approved », en liant ces deux fiches par une association de type « RPLC » (replace) ; la métadonnée availabilityStatus de la fiche du document remplacé prend alors la valeur « deprecated ».
Le registre identifie les fiches par leur identifiant « clé » entryUUID ; l’identifiant unique du document (uniqueId, de type OID, généré par le producteur du document) n’est qu’un attribut de la fiche. 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).
Pour accéder à la fiche du document à remplacer, un établissement de santé en authentification indirecte doit donc au préalable rechercher sur le registre son identifiant entryUUID par une transaction TD3.1 « Registry Stored Query », en utilisant la méthode GetDocuments en mode ObjectRef avec comme paramètre l’identifiant uniqueId du document.
Note : un LPS producteur de document peut très bien générer lui-même le entryUUID d’un document conformément aux spécifications XDS.b, afin d’en garder la référence en interne ; néanmoins nous attirons l’attention sur le fait que certaines opérations possibles sur le DMP peuvent rendre obsolète cette référence : voir à ce sujet l’entrée « Que doit-on mettre dans les identifiants des objets ebXML (ExtrincicObject, RegistryPackage, Classification, Association) ? » dans cette même FAQ.
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 le document IHE_ITI_TF_Rev7-0_Vol3 (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 document CI-SIS_Couche_Contenu_Volet_Structuration_Minimale_v1_0_1_1.pdf au chapitre 3.3.4.6 relatedDocument – Version précédente à remplacer).
Exemple (partie CDA) : <relatedDocument typeCode="RPLC">
<id root="1.2.250.1.999.1.2.3"/> ==> identifiant du document remplacé (pointe sur le champ <id> du document original remplacé)
Comment renseigner le champ confidentialityCode du document CDA?
Ni le standard CDA ni le Cadre d'Interopérabilité des SIS ne précisent la manière dont chaque valeur possible (Normal, Restreint, Très Restreint) doit être interprétée. Les règles d'usage de ces valeurs sont à préciser par le système d'information qui donne les accès aux documents. Pour un document estimé comme ayant un niveau renforcé de confidentialité (retreint ou très restreint), il serait souhaitable qu’il soit remis en mains propres, ou sous pli scellé, ou par message direct à son destinataire, et qu’il ne soit pas mis en partage. Il est probable que le DMP ne reçoive en dépôt que des documents à niveau de confidentialité dit « normal ». Compte tenu de la spécification actuelle, la proposition de l'ASIP est de retenir la valeur "N" (Normal). Est-il possible de positionner le masquage (« masque ps ») et l’invisibilité du document au patient (« invisible patient ») pour un même document dans le champ confidentialityCode XDS ? La documentation indique que cela n'est pas possible dans le cadre du DMP : le DSFT spécifie, au chapitre 9.4.1.1 « il n'est pas possible qu'un document soit à la fois invisible et masqué. » Le statut masqué ET invisible doit néanmoins être positionné sur le document de signature, comme indiqué au chapitre 4.2.2 du document CI-SIS_Couche_Service_Volet_Partage_Documents_Sante_v1.0.1.pdf disponible [ ici ]. Voir également le confidentialityCode CDA.
Comment est gérée la signature du lot de soumission pour le DMP ? Afin d’assurer l’imputabilité de l’action de dépose des documents alimentant le système DMP, il est requis de signer les lots de soumission, en utilisant le profil IHE DSG avec une signature de type XAdES (voir documents CI-SIS et DSFT des interfaces DMP des LPS pour une définition précise de la transaction), quel que soit le mode d’authentification utilisé (directe ou indirecte). Un lot de soumission comporte un ou plusieurs documents pour un et un seul patient. Quelles sont les autorités de certification (AC) nécessaires à la mise en œuvre de la signature XADES ? Par rapport aux fichiers installés par la CryptoLib dans le dossier "coffre", les AC nécessaires à la signature XAdES sont les suivantes :
Pour l'authentification directe (carte CPS) :
IGC-CPS.CERTSIGN.EXPL.PROFESSIONNEL.CL01.cer => AC-CLASSE-1 (carte CPS "professionnel"), IGC-CPS.CERTSIGN.EXPL.PROFESSIONNEL.RACINE.cer => Racine AC-CLASSE-1 (carte CPS "professionnel"). Pour l'authentification indirecte (certificat de personne morale "établissement") :
2008_03_17_IGC_CPS2bis_Exploit_Classe4_CertSign_CrlSign_Fin_2020.cer => AC-CLASSE-4 (certif. ES),
2008_03_17_IGC_CPS2bis_Exploit_Racine_CertSign_Fin_2020.cer => Racine AC-CLASSE-4, Pour information, les autres fichiers installés dans le dossier "coffre" ne sont pas pour le moment utiles dans le processus d'alimentation du DMP : 2008_03_17_IGC_CPS2bis_Exploit_Classe5_CertSign_CrlSign_Fin_2020.cer => AC-CLASSE-5 (certificat de confidentialité "partageable", pour messagerie sécurisée par exemple), 2008_03_17_IGC_CPS2bis_Exploit_Classe6_CertSign_CrlSign_Fin_2020.cer => AC-CLASSE-6, IGC-CPS.CERTSIGN.EXPL.ANONYME.CL00.cer => AC-CLASSE-0 (CPE Anonymes), IGC-CPS.CERTSIGN.EXPL.ANONYME.RACINE.cer => racine AC-CLASSE-0 (CPE Anonymes), IGC-CPS.CERTSIGN.EXPL.STRUCTURE.RACINE.cer => racine des structures (classes 2 et 3), IGC-CPS.CERTSIGN.EXPL.STRUCTURE.CL02.cer => AC-CLASSE-2 (CDE), IGC-CPS.CERTSIGN.EXPL.STRUCTURE.CL03.cer => AC-CLASSE-3 (CPE). Les autres fichiers sont sans importance pour le DMP. Les documentations sur les différentes classes de certificats et la structure des chaînes de certification sont disponibles sur http://integrateurs-cps.asipsante.fr/ Comment valider les signatures XAdES (signature du lot de soumission) ? Quelles pistes de résolution suivre lorsque l’on obtient une erreur DMPInvalidSignature ? Il est nécessaire de respecter le profil IHE DSG de signature de lot de soumission, décrit dans l'annexe technique pour faciliter la mise en œuvre de ce profil (document DMP1_LPS_TEC_DSFT_des_interfaces_LPS_Anx_tech_IHE_DSG_20101119_v1.0.1_0.pdf). La consultation de l’entrée « Quels sont les grands principes de la signature numérique à maîtriser (VIHF et lots de soumission) ? » de cette FAQ peut également s’avérer utile. 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, notamment au niveau des namespaces XmlDSig et XAdES des éléments :
SignedProperties et ses éléments fils, qui 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 donc par conséquent doivent être dans le namespace XmlDSig (http://www.w3.org/2000/09/xmldsig#),
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] » :
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#), la Signature XAdES présente dans les messages d'exemples TD2.1 reflète cela, DMPInvalidSignature : « Le controle de la signature du lot a échoué : Invalid signature : invalid SignedInfos » :
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, DMPInvalidSignature : « Le controle de la signature du lot a échoué : Le controle de cohérence des condensats de la signature de là pièce jointe a échoué pour : urn:oid:1.2.250.1.59.905.20111001.1.2011101012.17090717^CR17090717 » : 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, décrit dans l'annexe technique pour faciliter la mise en œuvre de ce profil (document DMP1_LPS_TEC_DSFT_des_interfaces_LPS_Anx_tech_IHE_DSG_20101119_v1.0.1_0.pdf) dont nous recommandons particulièrement la lecture de la note (en rouge) en bas de la page 7 concernant la construction des OID et leur compatibilité avec IHE DSG. Quels sont les types MIME à renseigner dans un flux d’alimentation ? 2 types MIME sont à renseigner dans un flux d'alimentation : Pour les métadonnées XDS :
ce type MIME doit être cohérent avec la valeur inscrite dans la métadonnée XDS "formatCode". Comment activer le codage MTOM (framework .NET en général) ? Les requêtes d'alimentation XDS.b (TD2.1) doivent respecter le codage MTOM/XOP défini dans le profile IHE XDS.b. La page suivante explique les différences entre le codage "Simple SOAP" et MTOM/XOP : http://wiki.ihe.net/index.php?title=XDS.b Une erreur classique avec .Net est que le MTOM n'est pas activé par défaut ; pour activer le MTOM sous .Net, il faut positionner "requireMtom = true" sur le client "WebServicesClientProtocol" généré. Où trouver de l’information générale sur le format CDA ?
Une FAQ est disponible à l’adresse suivante (sa lecture est fortement recommandée à tout nouvel éditeur entrant dans le processus de DMP Compatibilité et ne connaissant pas CDA) : http://esante.gouv.fr/referentiels/interoperabilite/faq-sur-le-cda-r2 Comment valider un document CDA par rapport au schéma CDA.xsd ? Un exemple de code (Java 5 et supérieur) permettant de valider un document CDA par rapport à son schéma XSD (CDA.xsd) est disponible à l’adresse : http://www.herongyang.com/XML-Schema/JAXP-XSD-Schema-XML-Validator-Final-Version.html Comment est réalisé le lien avec la feuille de style XSL pour afficher un CDA R2 ? Le lien vers la feuille de style XSL n'est en général pas véhiculé dans les transactions ; le système consommateur du CDA R2 (DMP, LPS) appliquera lui-même la feuille de style afin d'afficher le document CDA R2 à l'utilisateur (le LPS consommateur pourra utiliser la feuille de style de son choix).
Comment assurer la cohérence des métadonnées XDS avec les données de l’entête CDA ? Les métadonnées XDS et les données de l'entête CDA doivent être cohérentes ; le document CI-SIS_Annexe_Liens_entete_CDA_Metadonnees_v1.0.1.0.pdf recense les concordances à assurer entre le document XDS et l'entête CDA. Une attention particulière doit être apportée sur la gestion des dates : cohérence entre les champs XDS creationTime, serviceStartTime, serviceStopTime et les éléments correspondants dans le CDA, avec - dans le cas où ces champs comportent des heures – la gestion du décalage horaire entre XDS (date à mettre en UTC) et CDA (date à mettre en heure locale+timezone, voir le chapitre 3.2.3 « Représentation du temps » du doc CI-SIS_Couche_Contenu_Volet_Structuration_Minimale_v1_0_1_1.pdf) Note : été : +0200 et hiver : +0100
Un conseil d'implémentation peut être de générer d’abord le document CDA, puis de déduire les champs des métadonnées XDS des champs du CDA - aux transformations près pour les champs dates - les documents du CI-SIS Volet partage de document de santé proposant pour chaque métadonnée la concordance avec le champ CDA équivalent, lorsque le champ CDA existe. Le DMP refuse l’alimentation d’un document avec le message d’erreur « CDA incorrect » 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é).
Nous rappelons les règles de conformité d'un document médical au format CDA dans le contexte français du DMP : CDA R2 est le standard utilisé pour les documents médicaux. Un document médical doit d’une part être conforme au standard CDA, c’est-à-dire au schéma xml « CDA.xsd » et d’autre part un document médical doit être conforme au volet « Structuration minimale des documents médicaux » du CI-SIS, c’est-à-dire au schématron « CISIS_StructurationCommuneCDAr2 ». Enfin, un document médical qui se réclame d’un modèle structuré spécifié par un volet de contenu du CI-SIS doit être conforme au schématron associé à ce modèle de volet ; ce schématron est un sur-ensemble du schématron « CI-SIS_StructurationCommuneCDAr2 ». La vérification de conformité d’un document médical au CI-SIS nécessite par conséquent toujours deux opérations :
la validation du document par rapport au schéma « CDA.xsd » ; tout écart détecté se traduit par la déclaration de non-validité du document,
l’analyse du document par rapport au schématron associé au modèle de document structuré dont il se réclame, ou à défaut par rapport au schématron « CISIS_StructurationCommuneCDAr2 » ; 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. Il s’agit dans les deux cas de validation sémantique et de vérification de conformité sémantique : les jeux de valeurs embarqués dans le standard CDA, les jeux de valeurs exploités par le volet « Structuration minimale des documents médicaux », ainsi que les jeux de valeurs définis par le modèle de document structuré sont exploités par la vérification de conformité, et toute valeur étrangère détectée se traduit par une non-conformité. Note: la version actuelle du DMP ne réalise que la validation syntaxique par rapport au schéma « CDA.xsd » ; il est prévu d'y intégrer à terme la validation par schématron, il est donc utile de prendre en compte d'ores et déjà ces schématrons lors de la mise au point de la DMP Compatibilité ; les schématrons sont disponibles sur le RNR (partie référentiels/cadre d’interopérabilité du site de l'ASIP Santé) : http://esante.gouv.fr/services/referentiels/interoperabilite/cadre-d-interoperabilite-des-systemes-d-information-de-sante-, en bas de la page, suivre le lien « Répertoire "Test contenus CDA" au jj/mm/aaaa ».
Le DMP refuse l'alimentation d'un document avec le message d'erreur : XDSRegistryMetadataError
Contexte: entryUUID=SubmissionSet01
Le code ""SAxxx"" ne fait pas partie du domaine d'affinité (contentTypeCode)
Il faut vérifier que le secteur d'activité est bien présent dans la nomenclature fournie par le CI-SIS pour le champ contentTypecode. Le document CI-SIS Annexe Sources Données Personnes et Structures V1.0.1 spécifie la méthode pour renseigner le champ contentTypeCode au paragraphe 4.1.1. XDS : le DMP renvoie l’erreur DMPInvalidRequestId Dans le cas où les métadonnées d'un document manquent (mais que le document est référencé dans le lot), l’erreur rencontrée est du type : <ns3:RegistryError codeContext="DMPInvalidRequestId document :Document01.2" errorCode="XDSMissingDocumentMetadata" location="XDSAdaptorBean.provideAndRegisterDocumentSetB" severity="urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error" />
XDS : le DMP renvoie l’erreur : XDSRepositoryMetadataError / context=Aucun lot de soumission détecté dans la requête
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-d40d-43f9-88c5-b4633d873bdd" classifiedObject="SubmissionSet01".../> incorrect : <ns7:Classification classificationScheme="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd" classifiedObject="SubmissionSet01" .../>
XDS : le DMP renvoie l’erreur RegistryResponse = "Failure" sans autre code d'erreur
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:ebxml-regrep: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:ebxml-regrep:ResponseStatusType:Failure" />
XDS : le DMP renvoie l’erreur XDSDuplicateUniqueIdInRegistry
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.7898.3.20110506142825.1;Un document avec un champ hash identique existe déjà"
errorCode="XDSDuplicateUniqueIdInRegistry" location="AffinityDomainImpl.checkDocumentEntryUnicity" severity="urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error"
XDS : le DMP renvoie l’erreur XDSRepositoryError / XDSRegistryError
Le DMP renvoie un code XDSRepositoryError avec le message texte "Une erreur systeme 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.
Le DMP refuse l'alimentation d'un document avec un message d'erreur XDSRepositoryError :
XDSRepositoryError
codeContext="entryUUID=8.1234.1; Impossible de parser le document."
errorCode="XDSRepositoryError"
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 l'annexe technique pour faciliter la mise en œuvre de ce profil (voir le document DMP1_LPS_TEC_DSFT_des_interfaces_LPS_Anx_tech_IHE_DSG_20101119_v1.0.1_0.pdf). Le DMP renvoie une erreur : DMPInvalidData « L'analyse du XML de la signature du lot de soumission a échoué : org.xml.sax.SAXParseException: Premature end of file » sur une transaction IHE XDS MetadataUpdate (TD3.3) La transaction TD3.3 (IHE XDS MetadataUpdate) est à soumettre directement sur le Registry XDS et non sur le Repository, tel que c'est indiqué dans le DSFT (chapitres 9.4.1.2 et 12.3) et le profil IHE MU.
6 Questions relatives à la recherche et consultation de documents Mise en œuvre de Query XDS en environnement Microsoft.Net : pourquoi le tableau d'objets IdentifiableType n’est-il pas rempli ? Exposé de la difficulté rencontrée au niveau de la réponse en retour du Web Service pour la requête TD3.1 : « Recherche de documents » (StoredQuery XDS.b) :
en revanche l'accesseur de la structure réponse utilisé (RegistryObjectList) doit remplir un tableau d'objets IdentifiableType (contenant les UUID des documents par exemple) or ce tableau n'est jamais rempli dans notre objet. Nous n'assurons pas de support sur les questions relatives aux environnements de développement des éditeurs ; nous invitons le candidat à regarder plus précisément du côté des options utilisées lors de la génération des objets en C# depuis le WSDL. Par ailleurs voici quelques rappels des notions utilisées dans le profil IHE XDS.b :
dans le RIM ebXML (les messages XDS sont en ebXML), tous les objets dérivent du type de base "Identifiable" ; les objets ExtrinsicObject représentent les documents, et les objets RegistryPackage les lots de soumission,
il est donc normal qu'un query XDS renvoie ce type d'objets dans une RegistryObjectList (les schémas présents dans l'annexe wsdl-schema montrent cela), il convient donc de trouver la bonne configuration de génération de code pour que l’environnement de développement gère les objets présents dans RegistryObjectList conformément aux WSDL IHE et schéma XML associés relatifs à ebXML ; en environnement .Net, il est également nécessaire d'activer le MTOM tel qu'il est requis par le profil XDS.b (positionner « requireMtom = true » sur le client « WebServicesClientProtocol » généré). Il est à noter que l’utilisation des technologies Microsoft .Net peut nécessiter de modifier la sérialisation de la structure RegistryObjectList afin de pouvoir utiliser la méthode d'accès (getter) au contenu de cette liste (liste d'objets de type « Identifiable » qu'il faut « caster » en ExtrincicObject, RegistryPackage, etc.). Voici un exemple de code Java correspondant à la récupération d'objets renvoyés via un StoredQuery :
Il est à noter que Microsoft a publié un projet Open Source de client XDS, dans lequel il semble qu'ils parsent "à la main" le XML (ebXML) retourné par le Registre XDS. Des informations sont disponibles sur les URL suivantes :
Le DMP renvoie l’erreur : DMPAccessDeniedByRightsService : Accès refusé;Vous n'avez pas ce droit fonctionnel, en retour d’une requête stockée (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. 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 DSFT indique : « Fonction de recherche de document accessible uniquement en authentification directe sauf la méthode GetDocuments en mode ObjectRef uniquement »). Le chapitre 3.18 Registry Stored Query du Volume 2a du Technical Framework IHE ITI (voir référence en annexe à la fin du DSFT) donne la liste des StoredQuery supportées par le profil XDS.b ainsi que leurs paramètres associés. Le sous-chapitre 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-a5fc-c8ca9b40b9d4 et non :
urn:uuid:5c4f972b-d56b-40ac-a5fcc8ca9b40b9d4 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...). Le DMP renvoie une erreur : DMPInvalidData « L'analyse du XML de la signature du lot de soumission a échoué : org.xml.sax.SAXParseException: Premature end of file » sur une transaction IHE XDS MetadataUpdate (TD3.3) Voir l’entrée correspondante dans la section Alimentation de cette FAQ. Lors de la phase de mise au point de notre LPS, nous n'arrivons pas à décoder le corps encodé en base 64 des documents non structurés du jeu d'essai de développement éditeur mis à disposition par l’ASIP Santé (présent sur les environnements éditeur ). En effet, la longueur du champ "nonXmlBody/text" du CDA du document n'est pas un multiple de 4 : la librairie utilisée pour générer ces jeux d’essai ne complète pas les chaine base 64 avec le padding de fin (le ou les caractère(s) "=").
Selon wikipédia http://en.wikipedia.org/wiki/Base64 :
“From a theoretical point of view, the padding character is not needed, since the number of missing bytes can be calculated from the number of Base64 digits. In some implementations, the padding character is mandatory, while for others it is not used. One case where padding characters are required is when multiple Base64 encoded files are concatenated”
Il existe donc certaines librairies qui ajoutent le padding 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 librairies d'encodage base 64. Il suffit de compléter avec la bonne valeur de padding de fin si votre librairie ne le réalise pas déjà, et si la longueur n'est pas correcte.
7	Questions relatives au passage de contexte et à l’accès Web PS Comment s’assurer que la configuration du poste de travail permet d’accéder au DMP ? Une matrice de compatibilité système d’exploitation / navigateur est régulièrement mise à jour à l’adresse suivante : http://dmp.gouv.fr/web/dmp/documents/liste-configurations-compatibles
Un outil de diagnostic du poste de travail est également disponible à l’adresse suivante : http://www.outil-diagnostic.dmp.gouv.fr ; cet outil :
Réalise un diagnostic du poste couvrant l’ensemble des pré-requis pour l’accès Web PS DMP,
Puis effectue les installations nécessaires en tenant compte des exigences suivantes :
Automatiser le processus lorsque plusieurs étapes sont nécessaires,
Ne pas impliquer l’utilisateur dans les opérations de configuration technique,
Poste fonctionnel en fin d’installation sans avoir à redémarrer,
Permet de revenir à la configuration antérieure si l’utilisateur rencontre des problèmes suite à la mise à jour (1 clic).
Pourquoi les pièces jointes du CDA au format PDF envoyées par le LPS ne sont-elles pas affichées correctement dans l'accès Web PS (affichage sous forme de texte) ? La raison de ce comportement est que le formatCode XDS envoyé (urn:ihe:iti:xds-sd:text:2008 / documents à corps non structuré en texte brut) n'est pas cohérent avec le type MIME du document encodé en base 64 dans le corps du CDA (application/pdf). Le Web PS détecte donc un document en texte brut (il se base sur le formatCode XDS stocké dans la Registty XDS). formatCode :
<Classification id="cla61" classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d" classifiedObject="Document01" nodeRepresentation="urn:ihe:iti:xds-sd:text:2008">
<Value>1.3.6.1.4.1.19376.1.2.3</Value>
<LocalizedString xml:lang="FR" charset="UTF8" value="documents à corps non structuré en texte brut" />
Extrait du CDA :
<text mediaType="application/pdf" representation="B64">JVBERi0.... Les derniers articles