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

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. 

Le Référentiel d’Exigences Minimales et le Dossier de Spécification de Référencement (DSR) du dispositif dédié aux Logiciels de Gestion de Cabinet (LGC) du couloir Médecin de ville incluent dans leur périmètre l’obtention de l’agréement au cahier des charges "Guide d'intégration Ordonnance numérique" [GION2] auprès du CNDA (SC.ORDN/CONF.01).

Le Cahier des charges ordonnance numérique Médecins précise que le logiciel doit être certifié Logiciel d’Aide à la Prescription en médecine ambulatoire auprès de la HAS Haute Autorité de Santé - Certification des logiciels des professionnels de santé.

Pour plus de précision sur l’Ordonnance Numérique, vous pouvez vous référer au webinaire dédié sur le sujet.

La suppression de l’exigence DB.SO.106 initialement référencée au sein du REM DRIM-M a été actée suite à la constatation de son inapplicabilité. 

La mise à jour du REM DRIM-M n’ayant à l’heure actuelle pas été mise en œuvre au sein de la plateforme Convergence, l'exigence DB.SO.106 reste assignée aux candidatures à l’homologation SEGUR vague 2 pour les solutions DRIMBox. 

Par conséquent, la preuve de test associée à l'exigence DB.SO.106 peut être renseignée avec la mention « Non applicable au REM DRIM-M » en attendant une mise à jour corrective ultérieure de la plateforme Convergence.

La suppression de l’exigence DB.SO.34 initialement référencée au sein du REM DRIM-M a été actée suite à la constatation de son inapplicabilité. 

La mise à jour du REM DRIM-M n’ayant à l’heure actuelle pas été mise en œuvre au sein de la plateforme Convergence, l'exigence DB.SO.34 reste assignée aux candidatures à l’homologation SEGUR vague 2 pour les solutions DRIMBox. 

Par conséquent, la preuve de test associée à l'exigence DB.SO.34 peut être renseignée avec la mention « Non applicable au REM DRIM-M » en attendant une mise à jour corrective ultérieure de la plateforme Convergence.

La suppression de l’exigence DB.CO.131 initialement référencée au sein du REM DRIM-M a été actée suite à la constatation de son inapplicabilité. 

La mise à jour du REM DRIM-M n’ayant à l’heure actuelle pas été mise en œuvre au sein de la plateforme Convergence, l'exigence DB.CO.131 reste assignée aux candidatures à l’homologation SEGUR vague 2 pour les solutions DRIMBox. 

Par conséquent, la preuve de test associée à l'exigence DB.CO.131 peut être renseignée avec la mention « Non applicable au REM DRIM-M » en attendant une mise à jour corrective ultérieure de la plateforme Convergence.