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. 

Après certification, le CNDA remet à l’éditeur :

• L'attestation de conformité ;
• La lettre de référencement.

L’éditeur utilise ensuite l’attestation de conformité comme preuve de certification auprès de l’ANS.

Vous trouverez ci-dessous un exemple d'attestation de conformité :

Image

Le contenu des traces fonctionnelles attendues est défini par l’exigence SC.MSS/CONF.18.
L’objectif est de permettre un suivi des actions significatives réalisées sur les boîtes aux lettres MSSanté, sans conserver l’intégralité des échanges IMAP/SMTP ni le contenu des messages.

Ainsi, pour chaque boîte aux lettres, il est attendu a minima que les traces permettent de connaître :

• l’identifiant de l’auteur de l’action, dûment authentifié ;
• l’horodatage local du poste au moment de l’action ;
• le type d’action réalisée (consultation, envoi, suppression, etc.) ;
• la demande effectuée sur le serveur de messagerie MSSanté ;
• la réponse fournie par le serveur (y compris en cas d’échec).

Le contenu des messages ne doit en aucun cas être tracé. Le choix du niveau de détail des traces et des traitements suivis est laissé à l’appréciation de l’éditeur, dans la mesure où ces traces visent avant tout à le protéger, notamment en cas de requête judiciaire ou d’incident de sécurité. Il est toutefois attendu a minima que les actions d’envoi et de suppression de messages soient tracées.

Concernant la durée de conservation :

• Comme indiqué au §5 du référentiel #2 MSSanté, une durée de conservation de 6 mois est recommandée pour ces traces fonctionnelles.
• Le responsable de traitement (LPS) reste libre de définir la durée exacte de conservation, en fonction de son analyse de risques et de son cadre réglementaire.
• Les traces doivent être soumises aux mêmes mesures de sécurité et de confidentialité que les données MSSanté auxquelles elles se rattachent (mesures organisationnelles, techniques, etc.).

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.

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.

Le CIBA est prévu dans la vague 2 du Ségur en tant que profil optionnel. En cas de client lourd, l'éditeur doit proposer les deux solutions (code flow et CIBA) => SC.PSC.01 et SC.PSC.13. Le profil est obligatoire lorsque l’éditeur a choisi d’implémenter dans sa solution logicielle l’authentification ProSanté Connect par le protocole CIBA (§3.1 du DSR DPI).

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)

Nous vous invitons à contacter le support de iSC afin que nous vous indiquions si votre mandataire ou responsable légal est inscrit au fournisseur d’identité Industriels Santé Connect en transmettant son nom et son prénom ainsi que le nom de l’entreprise.

Les collaborateurs inscrits sur le fournisseur d’identité iSC disposent d’une interface dédiée avec un tableau de bord via lequel il est possible de consulter la « Liste des collaborateurs » dans laquelle sont précisés les nom, prénom, adresse e-mail, rôle et date de création de l’ensemble des comptes des collaborateurs de votre entreprise.

 Vous pouvez vous référer au guide utilisateur iSC.