Votre question concerne quel type d'offre ?
Votre question concerne quel couloir Ségur ?
Votre question concerne quel dispositif Ségur ?
Votre question concerne quel produit ou service produit?
Votre question concerne quelle thématique ?
Vous pouvez commander un certificat mTLS via la PFCNG. La procédure est détaillée au chapitre Authentification mTLS de la documentation technique. Le processus de commande détaillé est en train d’être mise à jour sur la page Certificats.
Cette réponse vous a-t-elle été utile ?
Pour Pro Santé Connect il faut que le certificat contienne le client_id dans le champ "CN" du certificat. Sur la plateforme de commande de certificats logiciels, le client_id doit être renseigné dans le champ "service applicatif". C'est ce dernier qui alimentera le champ "CN" du certificat. Il faut donc un certificat spécifique à Pro Santé Connect.
Cette réponse vous a-t-elle été utile ?
Pas de documentation ANS, l'implémentation d'un serveur intermédiaire est du ressort du fournisseur de service, il peut donc l'implémenter de la manière qu'il le souhaite.
Cette réponse vous a-t-elle été utile ?
Si le raccordement à Pro Santé Connect a déjà été réalisé en flux CIBA dans un service, il fonctionnera en e-CPS par défaut.
Pour ajouter la possibilité à l'utilisateur de s'authentifier à l'aide de sa CPx, il faut ajouter un paramètre optionnel « channel » (documenté dans la documentation technique) pour spécifier le type de MIE à utiliser.
Cette réponse vous a-t-elle été utile ?
Le client_secret ne doit jamais être présent sur le poste client, il doit impérativement être stocké sur le serveur intermédiaire. Nous recommandons, dans la mesure du possible, de conserver également le client_id et les jetons d’accès (access_token, id_token, et refresh_token) sur le serveur intermédiaire.
Cette réponse vous a-t-elle été utile ?
Non pas forcément, il est possible d'utiliser CPS-Gestion et la carte CPx sur un poste Windows, ou macOS (à venir). Mais en usage full mobile, l’utilisateur aura accès uniquement à sa e-CPS.
Cette réponse vous a-t-elle été utile ?
Les certificats mTLS deviennent en effet obligatoires en CodeFlow et en CIBA :
- Avant juin 2024 :
- en BAS – facultatif (n'hésitez pas à tester leurs déploiements sur vos environnements de test afin de vous familiariser avec le process) ;
- en production – non disponible.
- Après juin 2024 :
- en BAS – obligatoire ;
- en production – facultatif (passera en obligatoire dans un délai de 6 mois à compter de juin 2024).
Cette réponse vous a-t-elle été utile ?
L'équipe Pro Santé Connect étudie la possibilité de mettre cela en place, aucune date de mise à disposition ni de langage utilisé ne peut être annoncée à ce stade.
Cette réponse vous a-t-elle été utile ?
Les Appels à Financement des SONS du Ségur Numérique définissent aux chapitres 6.2 les modalités de paiement du solde des prestations. Dans ce cadre, les Mises-en-œuvre de Marche (MOM) ou les Vérifications d’Aptitudes (VA) font partie des pièces justificatives à joindre aux demandes de versement du solde.
Une VA non signée par le Client, transmise dans le cadre d’une demande de solde sera considérée comme non conforme par l’Opérateur de paiement.
Pour rappel, la Vérification d’Aptitude (VA) est une étape de constat par le Client qu’un logiciel livré présente bien les caractéristiques qui le rendent apte à remplir les fonctions précisées dans la réglementation Ségur.
Par ailleurs, il est rappelé que des conditions contractuelles garantissent une continuité d’intervention des éditeurs en phase de fonctionnement notamment les obligations relatives à la maintenance des logiciels dans le cadre des AF du Ségur et/ou, le cas échéant, l’étape de Vérification de Service Régulier (VSR) en fonction des relations contractuelles préexistantes.
Dans le cas où le Client souhaite mentionner des éventuelles réserves jugées non bloquantes, il peut les renseigner dans l’encadré “commentaires” des modèles de VA. Ces commentaires seront sans traitement par l’Opérateur de paiement.
En cas de désaccord entre le Fournisseur et le Client, il revient aux deux parties de formaliser leurs positions respectives et les conditions (moyens et calendrier) à réunir pour garantir la finalisation de la Prestation Ségur dans le calendrier compatible avec les échéances de la réglementation Ségur. Ces échanges sont par défaut régis selon les modalités prévues dans les documents contractuels en vigueur entre les parties.
Cette réponse vous a-t-elle été utile ?
Il s’agit d’une lettre dans laquelle vous attestez répondre aux critères d’éligibilité décrits dans la section 2.1 du DSR. Il convient, pour chacun des critères listés de décrire en quoi la solution logicielle y répond (par exemple sur la base d’une documentation produit, de captures d’écrans ou tout autre élément attestant de cette éligibilité).
Cette réponse vous a-t-elle été utile ?
Non. Le bon de commande doit impérativement faire figurer le montant réel, non nul, de la Prestation Ségur. La prise en charge par l'Etat doit être indiquée par la mention « Montant pris en charge par l’Etat au titre du Ségur de la santé » visible sur le bon de commande.
En particulier, au moment de la demande de solde, une copie de la facture faisant apparaître un montant total de la Prestation Ségur à 0€ sera systématiquement rejetée.
Cette réponse vous a-t-elle été utile ?
Le blocage de l’alimentation du DMP doit être unitaire et choisi par l’utilisateur.
L’utilisateur DOIT effectuer une action pour NE PAS ENVOYER dans le DMP (ex : case à cocher, bouton-radio…).
Cette action DOIT être effectuée pour CHAQUE document qu’il souhaite retenir.
Ce comportement DOIT être par défaut et DOIT être immuable : il NE DOIT PAS être configurable ou débrayable par l’utilisateur.
Cette réponse vous a-t-elle été utile ?
La transmission de données patient via MSSanté n'implique pas de disposer d'une identité INS qualifiée. Dans le cas ou l'INS du patient n'est pas qualifiée, le document transmis ne doit pas contenir l'INS et OID.
Cette réponse vous a-t-elle été utile ?
L'INS doit être utilisée pour référencer les données de santé produites dans la cadre de la prise en charge sanitaire ou le suivi médico-social de la personne. Seuls les acteurs de la santé et du médico-social concourant à la prise en charge de l’usager, au suivi médico-social de la personne, ou menant des actions de prévention sont tenus d’utiliser l'INS. Il convient donc de s'assurer que les documents respectent bien ce cadre et sont porteurs de l'INS.
A noter : les documents réalisés à des fins de facturation, destinés à des organismes de sécurité sociale ou à des organismes d'Assurance Maladie complémentaire ne doivent pas contenir l'INS.
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 (https://esante.gouv.fr/sites/default/files/media_entity/documents/DSR-HOP-DPI-Va1.pdf Chapitre 2.2).
Cette réponse vous a-t-elle été utile ?
Les solutions éligibles au dispositif SAS doivent comprendre :
- Un module de prise de rendez-vous en ligne ;
- Une accessibilité depuis les navigateurs Web standards du marché ;
- Un module d’agenda permettant la gestion des disponibilités du professionnel de santé et proposant à minima l’un des types de créneaux suivants : créneaux accessibles par le grand public hors patientèle, créneaux accessibles par l’ensemble des confrères clients de la solution logicielle hors structures et CPTS, créneaux accessibles uniquement par la plateforme numérique SAS.
A noter également que les solutions logicielles uniquement à destination des professionnels de santé hors contexte de médecine de ville ne sont pas éligible au dispositif SAS.
Cette réponse vous a-t-elle été utile ?
La date butoir de réception du dossier complet de preuves en vue du référencement est fixée au 17 avril 2024 à 14h. Vous trouverez l’ensemble des modalités de référencement dans le paragraphe 4.4 du DSR dédié.
A noter que toute demande postérieure à cette date est considérée comme irrecevable et sera immédiatement rejetée.
Cette réponse vous a-t-elle été utile ?
L'objectif du projet DRIM-M (Data Radiologie Imagerie Médicale & Médecine Nucléaire) est de proposer une architecture basée sur un maillage national de DRIMbox permettant d'aller chercher les images médicales là où elles se trouvent, et de permettre :
- Aux Professionnels de Santé exploitant de l'imagerie, spécialistes et radiologues et médecins nucléaires, d'afficher et d'importer l'examen dans leurs environnements de travail afin de réaliser des comparaisons, des reconstructions et du post-traitement
- Aux Professionnels de Santé et/ou patients, de visualiser un examen se rapportant au compte-rendu d'imagerie médicale à partir d'un lien intégré au document.
A travers le projet DRIM-M, chaque service et cabinet de radiologie producteur d'imagerie médicale devient un noeud du réseau DRIM-M : la structure d'imagerie partage des images via une passerelle nommée "DRIMbox" spécifiée par le projet.
Cette réponse vous a-t-elle été utile ?
En effet, les prescripteurs peuvent parfois disposer d'une BAL nominative (adresse MSS personnelle) ainsi que d'une BAL organisationnelle (boite de service, pouvant être utilisée par plusieurs professionnels
d’un même service). Dans ce cas, il convient d'enregistrer les deux correspondants : le prescripteur et le service ou établissement.
Cette réponse vous a-t-elle été utile ?
La demande de solde doit être conforme et introduite sur le même périmètre que la demande d’avance auprès de l’ASP. Cependant :
- si un ou plusieurs clients sont soustraits du périmètre de la demande d’avance, la demande de solde est recevable. Une compensation du montant versé lors de l’avance pour ce(s) client(s) sera effectuée au moment du solde.
- si un ou plusieurs clients sont ajoutés au périmètre de la demande d’avance, alors cette demande sera rejetée par l’ASP. Il faudra donc :
- modifier la demande de solde par un périmètre correspondant à la demande d’avance ou inférieur à celle-ci (si inférieur, une compensation du montant versé lors de l’avance pour ce(s) client(s) sera effectuée au moment du solde.)
- modifier la demande de solde par un périmètre correspondant à la demande d’avance ou inférieur à celle-ci (si inférieur, une compensation du montant versé lors de l’avance pour ce(s) client(s) sera effectuée au moment du solde.)
- si le périmètre est modifié en raison de l’évolution administrative d’un bénéficiaire (fusion, scission, etc.), cette demande sera acceptée par l’ASP à condition que :
- le JSON solde comporte les identifiants historiques (A et B) de l’avance au nouveau bloc « bénéficiaires »
- en complément au JSON solde, le fournisseur mentionne les bénéficiaires historiques ainsi que le nouveau bénéficiaire dans les documents de gestion. A cet effet, il faut joindre à la facture (dans le même document PDF), un traité de fusion. Ce document est mis à l'initiative du fournisseur, lors du dépôt de sa demande.
Ainsi, si A et B à l’avance, et que B est devenu C entre l’avance et le solde, le fournisseur devra fournir ce justificatif au moment de la demande de solde à l’ASP.
Cette réponse vous a-t-elle été utile ?