310 résultats
310 résultats
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).
Cette réponse vous a-t-elle été utile ?
Le représentant légal de la structure concernée par le certificat peut déléguer tout ou une partie de la gestion de ses certificats à un tiers, via le portail meshabilitation. La délégation de la commande et l'installation des certificats au fournisseur sont comprises dans les prestations Ségur.
Cette réponse vous a-t-elle été utile ?
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.
Cette réponse vous a-t-elle été utile ?
Oui, l'appel contextuel via PSC du web PS DMP doit obligatoirement être implémenté dans le cadre de la vague 2.
Cette réponse vous a-t-elle été utile ?
Toutes les solutions référencées ou candidates au référencement sont affichées sur les sites Industriels et esante avec des données complémentaires : DSR, vague, profils, composants additionnels, etc. Veillez à respecter les jalons indiqués lors du webinaire et sur la page https://industriels.esante.gouv.fr/segur-numerique-sante/vague-1 relative à votre couloir pour pouvoir être référencés avant fin 2024 et permettre à vos clients de percevoir le forfait structure 2024.
Cette réponse vous a-t-elle été utile ?
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.
Cette réponse vous a-t-elle été utile ?
Un seul formulaire 413 est suffisant pour commander les certificat DMP et INSi.
Il vous faut cocher la case "Certificat ORG (personne morale)", puis indiquer dans la case "Précisions sur l’usage des certificats et sur votre projet" les informations suivantes:
INSI: authentification sur les TLS INSi.
Vous pourrez retrouver toutes les informations concernant les commandes des certificats logiciels couloir par couloir sur la page https://esante.gouv.fr/produits-services/certificats-logiciels
Cette réponse vous a-t-elle été utile ?
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é.
Cette réponse vous a-t-elle été utile ?
Les éditeurs devront déposer leurs preuves sur le guichet Vague 2 dès qu’il sera ouvert et ils pourront bénéficier du financement SONS Va1+Va2 en cas de référencement, dans les limites d'exclusion précisées dans l'AF Vague 2 ("Eligibilité d’un Client à la Prestation Ségur Vague 1 + Vague 2"). S’ils sont référencés Vague 1, ils ne devront pas redéposer les preuves Vague 1, mais uniquement celles du périmètre Vague 2.
Cette réponse vous a-t-elle été utile ?
La dernière version de ce document est disponible sur la page dédiée du dispositif concerné ainsi que via son lien de téléchargement direct :
La date de la version publiée est par ailleurs indiquée sur le lien de téléchargement du document.
Pour votre information, voici un historique des versions publiées :
Date | Notes de mises à jour |
---|---|
19/05/2024 | Version initiale |
30/05/2024 | Scénario concerné : SSI/GEN.18.01 et Preuve concernée : SSI/GEN.18.01.02
Scénarii concernés : MSS/CONF.03.01.01, MSS/CONF.05.01.01, MSS/CONF.06.01.01, MSS/CONF.12.01.01, MSS/CONF.14.01.01, MSS/CONF.15.01.01, MSS/CONF.16.01.01, MSS/CONF.21.01.01, MSS/CONF.27.01.01
Scénarii concernés : MSS/va1.17.01, SSI/GEN.01.01, SSI/GEN.02.01, SSI/GEN.03.01, SSI/GEN.11.01, SSI/GEN.18.01, SSI/GEN.20.01, SSI/GEN.21.01
|
26/06/2024 | Ajout de liens vers des documents d'accompagnement au référencement dans l'onglet "Liste Référentiels" Exigences concernées : SC.SSI/GEN.18
Exigence concernée : SC.DB/PFI.01
Preuve concernée : SSI/GEN.03.01.01
|
04/07/2024 | Scénario concerné : SSI/IE.39.01
|
17/07/2024 | Scénario concerné : SSI/GEN.03.01
|
05/09/2024 | Scénario concerné : SC.DB/PFI.01.01
|
27/11/2024 | Correctifs apportés au scénario de conformité : améliorations et correction d'une erreur sur les jeux de données proposés.
|
11/03/2025 | Exigences concernées : PFI.MSS/UX.11 et PFI.MSS/UX.12
|
Cette réponse vous a-t-elle été utile ?