171 questions / réponses
171 questions / réponses
Conformément aux exigences prévues au chapitre 4 des DSR et à la section 4.3 de l’Appel à financement, pour les solutions logicielles pour lesquelles vous souhaitez mobiliser des financements Ségur, la déclaration de l’ensemble des versions techniques ayant fait l’objet d’une information publique auprès de vos clients concernant un arrêt de maintenance et/ou un arrêt de commercialisation est obligatoire.
À cet effet, le fichier modèle de déclaration des versions obsolètes, disponible dans le formulaire d’éligibilité, doit être complété. Dans le cas où aucune version obsolète n’est à déclarer, cette situation devra être explicitement mentionnée dans le fichier dédié.
Cette démarche est un prérequis obligatoire à l’obtention du financement Ségur 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 ?
La dernière version de ce document est disponible sur les pages dédiées des dispositifs concernés 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 |
|---|---|
| 22/03/2024 | Version initiale |
| 18/07/2024 | Simplification des paramètres associés à l'URL d'accès à la DRIMbox Consommatrice (Tableau 1 - pages 10-11) :
Ajout d'une note afin de mettre en visibilité la norme RFC 3986 (page 11) :
|
Cette réponse vous a-t-elle été utile ?
Les dispositifs SONS DPI et PFI sont indépendants et décrits distinctement dans les documents suivants : Appel à Financement (DPI et PFI), DSR (DPI et PFI) et REM (DPI et PFI). Par conséquent, les financements associés à la mise en œuvre des solutions DPI et PFI sont indépendants. Ainsi si un éditeur met en place une PFI pour laquelle l'établissement valide son fonctionnement conformément aux attendus décrit dans la VA (vérification d'aptitude), l'éditeur percevra le financement au bénéfice de l'établissement que ce dernier ait bénéficié ou non d'un DPI Vague 2.
Cette réponse vous a-t-elle été utile ?
Les preuves sont analysées une fois que l'ensemble du chapitre est complet et soumis.
Cette réponse vous a-t-elle été utile ?
Ces exigences SC.SSI/IAM.91 et SC.SSI/IAM.92 définissent la manière dont le système doit tracer certaines opérations et gérer la robustesse des mots de passe administrateurs.
Avant, le système devait conserver les traces de l’ensemble des opérations mentionnées (SC.SSI/IAM.91) et permettre à la structure de santé de mettre en place une politique de mots de passe robuste s’il gérait des comptes d’administration dans sa base de compte propre (SC.SSI/IAM.92).
Maintenant, le système doit uniquement conserver les traces des opérations mentionnées qu’il gère localement (SC.SSI/IAM.91) et peut utiliser un MIE sans mot de passe s’il garantit un niveau de sécurité équivalent ou supérieur, par exemple une clé FIDO (SC.SSI/IAM.92).
Ce changement est lié au fait que la rédaction initiale de ces exigences ne prenait pas en compte des cas d’usage remontés durant la procédure de référencement.
Concrètement :
- Dans la nouvelle version de l'exigence SC.SSI/IAM.91 : possibilité pour chaque scénario de déposer un justificatif expliquant le fonctionnement de l’application et indiquant que l’action n’est pas gérée localement.
- Dans la nouvelle version de l'exigence version SC.SSI/IAM.92 : possibilité de montrer l’authentification au système d’un administrateur pour justifier de l’utilisation d’un MIE sans mot de passe (NB : les codes PIN sont proscrits).
A noter qu'il n'y a aucune obligation pour l'éditeur, il s’agit d’une prise en compte de cas d’usage existants.
Cette réponse vous a-t-elle été utile ?
Oui, un composant "EAI/librairie" non autonome intégré dans le proxy doit passer son agrément au CDNA pour obtenir sa propre homologation.
Cette réponse vous a-t-elle été utile ?
En cas d'identification d'erreurs non légitimes, vous pouvez contacter l'adresse support monserviceclient.mssante@esante.gouv.fr en précisant dans l’objet « [MOTCO2] ».
L'équipe support prendra contact avec vous après analyse des traces fournies. Eventuellement MOTCO2 devra évoluer pour prendre en charge votre spécificité.
Cette réponse vous a-t-elle été utile ?
Le délai de réponse dépend du traitement par l’équipe en charge, mais vous pouvez généralement démarrer vos développements dès la réception d’une réponse positive.
Il est conseillé de surveiller votre messagerie et l’espace de suivi pour être informé dès que l’autorisation est accordée.
Cette réponse vous a-t-elle été utile ?
L’ensemble de la Solution Logicielle, c’est-à-dire le Composant Principal LPS, le Proxy e-Santé et les Composants Additionnels interfacés avec le Composant Principal LPS ou le Proxy e-Santé, font partie de l’Espace de Confiance PSC.
Le Composant Principal LPS et le Proxy e-Santé doivent être habilité dans l’Espace de Confiance PSC selon son rôle.
Cette réponse vous a-t-elle été utile ?