Besoin d’aide ? Toutes les réponses et ressources utiles pour les ENS

Le format demandé dépendra du type de document que vous souhaitez transmettre. Nous vous suggérons de consulter les REM en ce qui concerne le format des documents de santé. Vous pouvez consulter l'annexe 5.3 du DSR.

Les contrôles ne sont pas à effectuer par la PFI.
Les logiciels DPI ou RIS doivent comparer l’ensemble des traits d’identités (nom de naissance, 1er prénom de naissance, date de naissance, sexe, code INSEE du lieu de naissance, (liste des prénoms, matricule INS et OID si identité au statut qualifié présente)) du document reçu avec les traits des patients de sa base de données. 

Le code d'erreur 905 doit être envoyé (Cf : https://interop.esante.gouv.fr/ig/hl7v2/trans-cda-r2/error-codes.html)

Dans l’outil IGC, l’administrateur technique peut gérer l’ensemble de ses certificats depuis la page « suivi des certificats ». Il a notamment accès à la date de fin de validité de l'ensemble des certificats du parc géré.

Ce n'est pas exigé dans les fonctionnalités Ségur : c'est au SGL du laboratoire producteur du CR de réaliser cet envoi. Un établissement de santé reste cependant libre d'organiser les flux internes à son SIH selon sa stratégie. 

Le Code officiel géographique (COG) utilisé est bien issu des fichiers officiels INSEE. Certains cas de tests incluent des communes supprimées pour illustrer des cas réels d’historique administratif. 

Si l’éditeur constitue une base locale des COG, il doit impérativement l’alimenter et la maintenir à jour à partir de l’ensemble des fichiers disponibles sur le site de l’INSEE (communes actuelles, événements, COG complet).

L'export des données doit être réalisé sous un format standard, structuré et/ou non structuré, au choix de l’éditeur (ex : HL7 CDA, HL7 FHIR, PDF, DOC, DOCX, XML, etc.), avec une documentation détaillant la procédure à réaliser. La profondeur de l’historique doit être paramétrable dans la procédure. Le format des fichiers mis à disposition doit être lisible, exhaustif, exploitable, et documenté par l’éditeur.

Nous vous invitons à vous référer au DSR de votre couloir au chapitre 3.2.

Oui, l'appel contextuel via PSC du web PS DMP doit obligatoirement être implémenté dans le cadre de la vague 2.

Non, cela n'est pas interdit. Toutefois dans le cadre des échanges automatisés décrits dans les exigences, seuls sont concernés les CDA.

Conformément aux indications formulées au sein du référentiel Espace de Confiance ProSantéConnect ainsi que du volet CI-SIS relatif aux API ProSantéConnect, une connexion mTLS est exigée entre le proxy e-santé et l'environnement ProSantéConnect. En complément, cette connexion mTLS doit être mise en œuvre dans le cadre d'une authentification OAuth 2.0 et conformément au référentiel RFC 8705. 

En conséquence, il n'est pas nécessaire de mettre en oeuvre l'utilisation d'un "client_secret". Cette indication s'applique également dans le cadre des interactions entre le proxy e-santé et les APIs ProSantéConnect (API PSC DMP notamment). 

Il est important de noter que la ou les clés privées associées au(x) certificat(s) client mis en œuvre dans le cadre de la connexion mTLS mentionnée ci-dessus doivent être archivées au sein d'un keystore sécurisé implémenté directement sur le proxy e-santé.