FAQ de l'offre : Ségur du numérique en santé

Cette exigence est présente dans le REM DPI avec le "profil CIBA". Il convient de bien sélectionner ce profil au niveau de votre formulaire d'éligibilité pour la voir dans l'espace de preuves.

L’exigence SSI/IE.31 porte sur la vérification des coordonnées utilisées pour l'authentification lors de la création du compte ou la modification d'une coordonnée, que ce soit par un administrateur pour un tiers ou par l'utilisateur de son propre chef.
A noter que dans le cas où un administrateur crée ou modifie un compte pour un tiers, cette mécanique de vérification des coordonnées mail et téléphone pour cet utilisateur tiers permet aussi de s’assurer que la personne concernée est consentante et qu'il n'y a pas eu d'erreur dans la saisie des coordonnées, ce qui est d'autant plus probable dans ce cas.

La définition du périmètre des tests d’intrusion relève de la responsabilité de l’éditeur, en fonction des cas d’usage et de l’architecture de la solution. Le processus générique est le suivant :

1. L'éditeur prend connaissance du périmètre du REM et candidate pour une solution dont il donne le nom et la version.
    
2. L’éditeur a la responsabilité de présenter à l’auditeur le périmètre concerné par le test d’intrusion, en s’appuyant sur sa connaissance de la solution et en se portant garant de la justification apportée.
    
3. L'auditeur doit mentionner dans le rapport de pentest le nom/version de l'application concernée.
    
4. Le guichet conformité vérifie que le nom et la version de l’application concernée correspondent à ceux déclarés par l'éditeur, et que le rapport est conforme aux exigences.

Oui, il est possible de combiner certains critères, selon leur pertinence. Il n’est pas obligatoire de pouvoir interroger individuellement tous les critères listés dans l’exigence.

La spécification projet DRIMBox mentionne un ensemble de traces d'audit devant être collectées par les solutions DRIMBox lorsque celles-ci sont impliqués dans une action d'alimentation et/ou de consultation. Cependant, certains cas d'erreur peuvent empêcher ladite action d'aller à son terme et l'intégralité des champs relatifs à la trace d'audit associée peuvent ne pas être connus.

Par exemple, la section 4.5.12.3 de la spécification projet DRIMBox définit une trace d'audit à générer par la fonction source d'une solution DRIMBox lorsque celle-ci réceptionne et traite une requête WADO-RS ciblant la récupération d'images médicales. Cette trace d'audit comporte un champ "UserID" censé contenir l'identifiant RPPS du professionnel à l'origine de la demande d'accès aux images. Cette information ne peut être connue de la DRIMBox qu'après la phase d'introspection ProSantéConnect impliquant le jeton mentionné au sein de la requête WADO-RS. Or, si un cas d'erreur intervient avant la mise en oeuvre de l'introspection (échec de la connexion mTLS par exemple), l'identifiant RPPS ne peut être connu.

Dans ce cas de figure, et pour toutes les situations d'erreur qui empêcheraient la solution DRIMBox de connaître l'intégralité des informations à mentionner au sein d'une trace d'audit, une chaîne de caractère fixe, type "false", peut être renseignée. De cette manière, la trace d'audit exhaustive pourra tout de même être générée, tout en traduisant la situation d'erreur rencontrée.

Le contenu de l'exigence SC.DMP/CONF.14, rattachée au REM DRIM-M et donc applicable aux solutions DRIMBox candidates à l'homologation SEGUR vague 2, fait référence à une collecte de traces d'accès d'un utilisateur au DMP dans le contexte de la gestion du cycle de vie d'un document. Cette exigence est mentionnée au sein du REM DRIM-M car l'utilisateur en question peut être compris comme une personne physique ou bien une solution logicielle (DRIMBox dans notre cas). 

Ainsi, en substance, l'exigence indique que la fonction source de la DRIMBox doit conserver une trace de ses propres accès au DMP pour les situations d'alimentation (mise à jour de document inclus). En complément, la fonction consommatrice de la DRIMBox doit également conserver une trace de ses accès au DMP pour les situations de consultation.

Cette même logique est applicable concernant la formulation du scénario proposé afin de valider l'exigence SC.DMP/CONF.14. Au sein de ce scénario, la mention "utilisateur" peut également être comprise comme "solution logicielle DRIMBox".

En revanche, il est important de noter qu'au sein du scénario de test associé à cette exigence, le déroulement des étapes n°2 à n°5 implique la mise en œuvre d'une entité tierce à la DRIMBox. Cette entité tierce jouera le rôle d'un système RIS placé en amont de la DRIMBox afin de transmettre à cette dernière les ordres de remplacement, suppression, masquage, invisibilisation, au travers de messages HL7v2 dédiés. 

Nous confirmons que l'exigence SC.DMP/CONF.11 est absente du REM.

L'exigence SC.DMP/CONF.21 remplace l'exigence SC.DMP/CONF.11 sur les dispositifs RIS et DRIMbox.

Une action de mise à jour du document DSR est en cours.

Vous trouverez ci-dessous les liens vers les REM :

• RIS : REM – RIS – Vague 2 – version du 27/02/2025 (xlsx)
• DRIMbox : REM – DRIMbox – Vague 2 – version du 27/02/2025 (xlsx)

Dans le cadre du parcours de référencement de sa solution logicielle, l’Editeur de Logiciel Utilisateur doit obtenir l’Habilitation EDC PSC Editeur de Logiciel Utilisateur pour sa Solution.

Afin d'obtenir cette Habilitation, l’Editeur de Logiciel Utilisateur doit valider le chapitre "Prérequis Maturité technique" du guichet Editeur Espace de Confiance Pro Santé Connect. 

A ce titre, l'exigence EDC / PSC.101.01 prévoit que l’Editeur du Logiciel Utilisateur doit fournir une preuve de l’existence de CGU, même incomplètes, incluant un paragraphe dédié à Pro Santé Connect. 
Les CGU définitives ne sont requises qu’au moment du guichet Opérateur. Pour toute précision sur les attendus, vous pouvez vous référez à la question/réponse dédiée sur le sujet.

NB : Les Editeurs de Proxy ne sont pas concernés par les CGU car ils n'ont pas d'interface utilisateur.
 

1. Quel est le changement principal ?
Dans le scénario initial, le jeu de test utilisait un patient dont la balise « liste des prénoms » était vide.
Ce patient est désormais remplacé par : PAT-TROIS DOMINIQUE MARIE-LOUISE.

2. Concrètement, qu’est-ce que ça implique ?
• Toute référence à l’ancien patient doit être remplacée par le nouveau patient indiqué.

3. Quand appliquer ce changement ?
Dès à présent, pour l’ensemble des validations et démonstrations liées à l’exigence SC.INS/va1.72.01.

4. Quelles obligations pour l’éditeur ?
• Utiliser exclusivement le nouveau patient de test fourni.
• Adapter les preuves de tests pour les futurs dépôts sur Convergence.

Annexe – Nouveau scénario SC.INS/va1.72.01
Modification du jeu de test :
- Ancien patient (balise liste des prénoms vide) → remplacé.
- Nouveau patient à utiliser : PAT-TROIS DOMINIQUE MARIE-LOUISE.

Toutes les étapes du scénario demeurent identiques, seul le patient de test change.

Cette exigence SC.SSI/IAM.92 définit la manière dont le système doit gérer la robustesse des mots de passe administrateurs.

Avant, le système devait 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. Maintenant, le système peut utiliser un Moyen d'identification électronique (MIE) sans mot de passe s’il garantit un niveau de sécurité équivalent ou supérieur, par exemple une clé FIDO.

Concrètement, la nouvelle version de l’exigence SC.SSI/IAM.92 permet de démontrer l’authentification d’un administrateur au système afin de justifier 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.