FAQ DMP Compatibilité

Espace DMP | 28 oct. 2014
 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 DE GESTION ADMINISTRATIVE DU DMP
 
 5 QUESTIONS SUR LES FONCTIONS D’ALIMENTATION
 
 6 QUESTIONS RELATIVES AUX FONCTIONS DE RECHERCHE ET DE CONSULTATION DE DOCUMENTS

 7 QUESTIONS RELATIVES À L’ACCÈS WEB PS AVEC PASSAGE DE CONTEXTE 
La lecture des FAQ "professionnel de santé" et "Patients" du site www.dmp.gouv.fr 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 Editeur. L'homologation consiste à vérifier le bon fonctionnement des interfaces des LPS avec le Système d'Information DMP. Elle porte sur des profils de DMP Compatibilité, qui regroupent de façon cohérence les différentes transactions exposées par le SI DMP.

Ces profils sont : création et gestion administrative du DMP ; alimentation du DMP ; consultation du DMP.

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 dans ce cas ne fait pas l'objet d'une homologation par l'ASIP Santé.
 
Comment puis-je prendre connaissance du processus d'homologation à la DMP Compatibilité ? 
Le processus d’homologation à la DMP Compatibilité est décrit sur le site de l’ASIP Santé : http://esante.gouv.fr/services/espace-dmp/processus-d-homologation-a-la-dmp-compatibilite

Nous vous conseillons également de lire le Contrat Editeur de l'ASIP Santé pour la DMP Compatibilité.
 
Quelles sont les transactions qu'un logiciel de professionnel de santé (LPS) doit implémenter pour pouvoir être homologué DMP-Compatible ?
 
Lors du processus d’homologation, la DMP Compatibilité est vérifiée par profil / mode d'authentification.

L'homologation porte sur l'ensemble des transactions obligatoires du profil et sur les transactions optionnelles que l’éditeur a décidé d'intégrer.

L’éditeur peut intégrer les différents profils à son rythme, en passant plusieurs homologations pour des profils / mode d’authentification différents.

A chaque nouvelle homologation la totalité des transactions fait l'objet de vérifications par l'ASIP Santé.

Pour plus d’information lire le DSFT des interfaces DMP des LPS.
 

Mon LPS peut fonctionner sous différents systèmes d’exploitation : dois-je passer une homologation spécifique pour chacun d'entre-eux ?
La constitution d’une famille de produits (voir le Contrat Editeur pour la DMP Compatibilité) est laissée à la libre appréciation du candidat et peut comporter plusieurs logiciels s’exécutant sous des systèmes d’exploitation différents.

Le Contrat Editeur pour la DMP Compatibilité ne contraint pas le candidat à passer une homologation pour chaque couple famille de produit / système d’exploitation. Cependant, dans la mesure où les tests sont en pratique réalisés avec un seul logiciel de la famille de produits, l’ASIP Santé recommande de passer une homologation par couple famille de produit / système d’exploitation

Quelles sont les modalités de nouveau passage en homologation en cas d’ajout de transactions optionnelles à un profil déjà homologué ?
A chaque nouvelle homologation, la totalité des transactions fait l’objet de vérifications par l’ASIP Santé : les nouvelles et celles 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é ?
A chaque nouvelle homologation, la totalité des transactions fait l’objet de vérifications par l’ASIP Santé : les nouvelles et celles déjà homologuées, pour le nouveau mode d’authentification et celui déjà homologué.

Quelles sont les modalités de nouveau passage en homologation en cas de modification du LPS ?
Le Contrat Editeur pour la DMP Compatibilité précise que dans le cas où l’un des produits qui constitue la famille est modifié, il appartient à l’éditeur d’évaluer, en fonction des évolutions qu’il a réalisé, la nécessité de resoumettre la nouvelle version de son logiciel à l‘homologation de la DMP Compatibilité. Si ces évolutions touchent les fonctions DMP, l’ASIP Santé recommande fortement à l’éditeur de repasser sa famille de produit à l’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). 
 
 

2 Questions relatives aux environnements de tests 

 
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 ?
Des environnements de tests du système d'information DMP sont prévus pour les candidats ayant signé le Contrat Editeur pour la DMP Compatibilité. Pour plus d’information sur les environnements de tests disponibles, voir le DSFT des interfaces DMP des LPS.

Qui contacter en cas de problème sur les environnements de tests et de formation ?
Pour les environnements de tests, vous devez contacter l’équipe en charge de la DMP Compatibilité à l’ASIP Santé par mail à DMPCOMPATIBILITE@sante.gouv.fr.
Pour les environnements de formation, vous devez contacter DMP Info Service (24/24, 7/7) au 0810 33 11 33 (prix d’un appel local) ou en utilisant le formulaire de contact http://www.dmp.gouv.fr/contact-ps.

L'utilisation des cartes et certificats CPS de production est-elle autorisée sur les environnements de tests DVx ?
Non, les cartes et certificats CPS de production ne peuvent pas être utilisés sur les environnements de tests de la DMP Compatibilité.
Pour vos tests et pour l’homologation, vous devez utiliser des cartes CPS de tests (pour l’authentification directe) et des certificats serveurs de tests test lié à votre carte CPA de test émis par l’IGC CPS (certificats AC-Classe-4).

Quelle est la procédure pour obtenir les cartes CPS de tests (pour l’authentification directe) ou les certificats serveurs de tests émis par l’IGC CPS (certificats AC-Classe-4) ?
La démarche est décrite et les documents téléchargeables sur http://integrateurs-cps.asipsante.fr/. Vous trouverez également des informations sur la procédure dans le DSFT des interfaces DMP des LPS dans le paragraphe « L’espace intégrateur CPS de l’ASIP Santé ».

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

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 ? 
 
A l'AFNOR :
L’AFNOR gère une branche d'OID identifiée « 1.2.250.1 ». Les demandes peuvent être adressées à la personne en charge des enregistrements et de gestion de registre d'OIDs pour la France :
AFNOR -DTEC
Martine DEGARDIN (martine.degardin@afnor.org)
11, rue Francis de Pressensé
93571 LA PLAINE SAINT DENIS CEDEX
Le traitement d'un dossier d'enregistrement prend en moyenne 2 semaines.
L’AFNOR peut fournir des OID numérique et alphanumérique. Cependant, les racines d’IOD alphanumériques ne sont pas acceptées dans les normes HL7 et XDS, et par conséquent ne le sont pas non plus par le DMP. Demandez une racine d’OID numérique.

A l’ITU:(http://www.itu.int/ITU-T/asn1/uuid.html) :
Il existe 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).
 
 
Pouvez-vous valider ma méthode de génération des OID ?
 
Non car 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 des exigences énoncées dans le DSFT des interfaces DMP des LPS.
 
 
Pourquoi certaines données renvoyées par le SI DMP comportent-elles la chaine de caractères "&" (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 peut comporter un caractère « & » (encodé & 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 : 
  • & : &
  • > : >
  • < : &lt;
  • " (guillemets) : &quot; (dans les valeurs d'attributs)
  • ' (apostrophe) : &#39; (dans les valeurs d'attributs)
Comment identifier une carte CPS/CPE opposée (révoquée) ?
En accès Web PS du DMP, le comportement observé avec une carte révoquée est le suivant :
  • 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 http://testssl.asipsante.fr/ de l'ASIP Santé ne fait pas mention de l'opposition du certificat d'authentification de la carte.
 
Comment récupérer toutes les informations d’un PS (différentes situations d'exercice d'un PS, …) ? 
 
L’Accès Web PS du DMP affiche des informations sur les PS (pour les auteurs de documents ou les PS autorisées par exemple) telles que les différentes situations d’exercices (avec le nom de la structure, l’adresse, le code postal, le téléphone, ...). Pour cela, le DMP réalise une requête sur l'annuaire ASIP-CPS.

Les interfaces DMP des LPS ne proposent pas cette fonctionnalité.

Les LPS qui souhaitent récupérer ces informations doivent interroger l'annuaire ASIP-CPS (qui ne contient cependant que les porteurs de cartes CPx).

Il est à noter que le futur Référentiel des Acteurs Santé Sociaux (RASS) va bientôt permettre de récupérer ces informations pour l'ensemble des professionnels de santé et leurs structures de rattachement.
 

Où trouver la version du TLS utilisée par mon LPS ?
Dans le cadre de la procédure d'homologation DMP compatibilité, il est demandé au candidat d'indiquer la version de TLS est utilisée par le LPS. La version du protocole est visible côté client en activant le « debug » de la couche TLS au niveau de la librairie TLS utilisée (OpenSSL, CUrl…).

Par exemple en Java, en positionnant javax.net.debug=all on peut voir la version de TLS lors des échanges :

*** ClientHello, TLSv1.2
...
***
main, WRITE: TLSv1.2 Handshake, length = 82


Interception des requêtes SOAP (trames entrantes/sortantes) en environnement .Net
En environnement Microsoft .Net il est possible d'utiliser les fonctionnalités d'inspecteurs de message de WCF pour intercepter les requêtes et réponses échangées avec les webservices et les manipuler :
http://msdn.microsoft.com/en-us/library/system.servicemodel.dispatcher.iclientmessageinspector%28v=vs.100%29.aspx

Comment traiter des problèmes de génération d’objets à partir du WSDL GestionDossierPatientPartage.wsdl sous Java ?
Voici, à titre d'exemple uniquement puisque l’ASIP Santé ne fournit pas support pour le développement des LPS, un 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 



 

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

 
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.
 
 

5 Questions relatives à la fonction d’alimentation

 
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 :
  • 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. 
Pour la pièce jointe CDA R2 :
  • 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. 
....
<component>
   <nonXMLBody>
       <text mediaType="text/plain" representation="B64">VGVzdCA=}</text>
   </nonXMLBody>
</component>
  • 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. 
 
Pour en savoir plus sur les différences entre le codage "Simple SOAP" et "MTOM/XOP" : http://wiki.ihe.net/index.php?title=XDS.b

Attention : sous .Net, le MTOM n'est pas activé par défaut. Pour l’activer, il faut positionner "requireMtom = true" sur le client "WebServicesClientProtocol" généré.
 
Comment valider un document CDA par rapport au schéma CDA.xsd ? 
Vous trouverez un exemple de code (Java 5 et supérieur) permettant de valider un document CDA par rapport à son schéma XSD (CDA.xsd) à l’adresse suivante : 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).
 

6 Questions relatives aux fonctions de recherche et de 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 vous invitons à 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é).
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(); 
}
 
Microsoft a publié un projet Open Source de client XDS, dans lequel il semblerait qu'ils parsent "à la main" le XML (ebXML) retourné par le Registre XDS. Des informations sont disponibles sur les URL suivantes :
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;

Import des WSDL de IHE XDS en PHP 5.3  : 
En PHP 5.3, lors de l'analyse des WSDL des fonctions de recherche de document (IHE XDS Registry) avec SOAPClient, des erreurs peuvent être générées (ex : SOAP-ERROR: Parsing Schema: element 'urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0:InternationalString' already defined). Ce client SOAP ne gère pas bien les inclusions de WSDL : il est possible de résoudre ce problème en concaténant les différents WSDL en un seul pour éviter des inclusions et des importations en double. 
 


Pourquoi les documents CDA non structurés (pdf par exemple) envoyés par le LPS ne sont-ils pas affichés correctement dans l'accès Web PS ?  
Ce problème peut être lié au fait que le formatCode XDS du document n'est pas cohérent avec le mediaType dans le corps du document CDA. L’Accès Web PS se base sur le formatCode XDS stocké dans la Registry XDS.

Lors de l’alimentation du DMP, il est donc impératif de respecter la cohérence entre le component/nonXMLBody/text@mediaType CDA et le formatCode XDS.

Les correspondances à respecter entre CDA et XDSsont les suivantes :
 mediaType CDA  formatCode XDS
 application/pdf  urn:ihe:iti:xds-sd:pdf:2008
 text/plain  urn:ihe:iti:xds-sd:text:2008
 text/rtf  urn:ihe:iti-fr:xds-sd:rtf:2010
 image/jpeg  urn:ihe:iti-fr:xds-sd:jpeg:2010
 image/tiff  urn:ihe:iti-fr:xds-sd:tiff:2010

Lorsque j'accède à l’Accès Web PS avec passage de contexte (environnements de développement), j'obtiens une erreur du type : The requested URL was rejected. Please consult with your administrator. Your support ID is: XXXXXXXXXXXXXXXXXXXXXX

Une fois vérifié que l'erreur ne provient plus du filtrage IP (i.e. que l’IP utilisée par éditeur est bien celle qu’il a déclaré auprès de l’ASIP Santé, à vérifier par exemple à l’aide du site www.whatismyip.com) : si vous n'avez jamais accédé à l’Accès Web PS préalablement (sur DV1) merci de vous assurer que :
  • le poste de travail est correctement configuré
  • la CPS est bien fonctionnelle en se connectant sur http://testssl.asipsante.fr/ et en nous transmettant les informations retournées par le site sur la CPS.
     
Services: