FAQ DMP Compatibilité (actualisé)

 1 QUESTIONS RELATIVES AU PROCESSUS D’HOMOLOGATION
 
 2 QUESTIONS RELATIVES AUX ENVIRONNEMENTS DE TESTS
 
 3 QUESTIONS TECHNIQUES D’ORDRE GÉNÉRAL (TOUTES TRANSACTIONS)
 
 4 QUESTIONS RELATIVES AUX FONCTIONS DE CRÉATION ET GESTION ADMINISTRATIVE DU DOSSIER
 
 5 QUESTIONS SUR LES FONCTIONS D’ALIMENTATION
 
 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 

 

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

2 Questions relatives aux environnements de tests 

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

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

3 Questions techniques d’ordre général (toutes transactions)

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

• & : &
• > : >
• < : &lt;
• " (guillemets) : &quot; (dans les valeurs d'attributs)
• ' (apostrophe) : &#39; (dans les valeurs d'attributs)

• sous Internet Explorer : affichage d'une page erreur standard du navigateur du type « erreur 400 Bad Request »,
• sous Firefox : un message texte du type « Votre certificat CPS est invalide » est affiché.

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 :

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

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

• 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

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

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

• Code Erreur: DMPInvalidData
• Message Erreur: Impossible d'effectuer un test d'existence : Profession non correspondante 

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

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

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

• 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
  
   

4 Questions relatives aux fonctions de création et gestion administrative du dossier 

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

• au chapitre 7.2.4 :

• au chapitre 7.2.5 :

	Nom de famille du patient	Nom d'usage du patient
Carte Vitale V1bis	Absent	Obligatoire Désignation : nom usuel ou nom d’usage
Carte Vitale V1ter	Facultatif Désignation : nom de famille  ou nom patronymique	Obligatoire 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'	Composant 1 de PID-5 lorsque composant 7 de PID-5 = 'D'
Accès web patient DMP	Facultatif Désignation : Nom de naissance	Obligatoire Désignation : Nom d’usage
Accès web PS DMP	Facultatif Désignation : Nom de naissance	Obligatoire Désignation : Nom d’usage

5 Questions sur les fonctions d’alimentation

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

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

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

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

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

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

• le type MIME des ExstrinsicObject (c’est-à-dire les métadonnées des documents XDS) est toujours text/xml (note : dans le futur il sera possible pour le DICOM de mettre application/dicom), 
• le type MIME de l'ExstrinsicObject du document de signature DSG est toujours text/xml. 

• le mediaType est le vrai type MIME du fichier encapsulé dans le CDA R2 ; les types MIME autorisés sont décrits dans le document CI-SIS couche contenu volet structuration minimale 1.0.1.pdf : image/jpeg, image/tiff, text/rtf, text/plain, application/pdf. 

• ce type MIME doit être cohérent avec la valeur inscrite dans la métadonnée XDS "formatCode". 

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

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

• correct : 

• incorrect : 

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

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

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

• le bon flux XML est reçu (conforme au flux XML de test du code exemple),
• 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 :

AdhocQueryResponse response = null; 
 
try { 
  //récupération de la réponse 
  response = registry.documentRegistryRegistryStoredQuery(request); 
 
  //TODO : tester la valeur de retour pour voir s'il y a une erreur ou non 
  //... 
 
  //si pas d'erreur : récupération de la liste dans laquelle sont renvoyés les objets ebXML 
  RegistryObjectListType regList = response.getRegistryObjectList(); 
  //liste des éléments (documents, lots...) renvoyés dans la query 
  List<JAXBElement<? extends IdentifiableType>> returnedObjectList = regList.getIdentifiable(); 
  //parcour de la liste d'éléments (document, lots...) 
  for (JAXBElement<? extends IdentifiableType> element : returnedObjectList) { 
 
    //traitement des documents 
    if (element.getValue() instanceof ExtrinsicObjectType) { 
      //TODO : récupérer les métadonnées du document via les attributs ebXML de ExtrinsicObjectType 
      ExtrinsicObjectType documentMetadata = (ExtrinsicObjectType) element.getValue(); 
      System.out.println("document retourné entryUUID="+documentMetadata.getId()); 
    } 
    //traitement des lots 
    else if (element.getValue() instanceof RegistryPackageType) { 
      //TODO : récupérer les métadonnées du lot via les attributs ebXML de RegistryPackageType 
      RegistryPackageType lotMetadata = (RegistryPackageType) element.getValue(); 
      System.out.println("lot retourné entryUUID="+lotMetadata.getId()); 
    } 
    // TODO : traitement des associations... 
 
  } 
 
} catch (SOAPFaultException sfex) { 
  System.out.println("Erreur (SOAP Fault) : " + sfex.getMessage()); 
  sfex.printStackTrace(); 
}

• projet IHE XDS de Microsoft : http://ihe.codeplex.com , http://wiki.ihe.net/index.php?title=Implementation#Microsoft_IHE_Integration_Profiles
• White paper Microsoft décrivant le parsing "manuel" : http://www.microsoft.com/health/en-ng/resources/Pages/White-papers.aspx puis télécharger le document "Microsoft IHE XDS.b reference implémentation", puis page 28, voir la méthode UnpackStoredQueryResponse

Il est également possible d'adopter la méthode suivante (modification de la classe AdhocQueryResponse" générée par Visual Studio) :

Le problème semble lié au comportement de la classe System.Xml.Serialization.XmlSerialiser lorsqu’ il y a héritage dans la structure du XML de réponse (C'est le cas avec ObjectRefType, qui est dérivé de IdentifiableType). Dans la class autogenerée "AdhocQueryResponse", la propriété ElementName est utilisée afin que le nom de l'élément XML généré soit différent de l'identificateur du membre. Le RegistryObjectList du flux XML est maintenant un élément inattendu. Un nouveau membre, AllElements, est ajouté avec l'attribut "XmlAnyElement". Cela permet à XmlSerialiser de désérialiser les éléments ne disposant pas de membre correspondant dans l'objet en cours de désérialisation. L'élément RegistryObjectList du flux XML est donc trouvé dans le membre AllElements.

Les modifications de la classe auto-générée sont décrites ci-dessous :

// Renommer cet élémént dans le XML afin que le XmlSerializer ne puisse pas associer cet élément avec

// l'élément RegistryObjectList dans le flux XML

// Donc après deserialisation le RegistryObjectList sera null au lieu d'être vide.

[XmlElement( ElementName = "cet_element_n_existe_pas_dans_le_xml" )]

public IdentifiableType[] RegistryObjectList

{

get

{

return this.registryObjectListField;

}

set

{

this.registryObjectListField = value;

}

}

private IdentifiableType[] registryObjectListField;





// Un élément  ajouté à la main pour gérer le problème de IdentifiableType[]

// Parce que le XmlSerializer ne peut plus associer le XML RegistryObjectList avec la property RegistryObjectList

// (voir dessus) il ajoute l'élément RegistryObjectList du flux XML dans cette liste des éléments

// qu'il ne peut pas parser.  C'est l'attribut "XmlAnyElement" qui ajoute ce comportement.

[XmlAnyElement]

public System.Xml.XmlElement[] AllElements;

 
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.

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