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

Le partage de données d'imagerie entre deux solutions DRIMBox (fonction consommatrice interrogeant une fonction source) implique la mise en œuvre d'une connexion mTLS entre les deux entités. La description des certificats à exposer dans ce cadre peut être résumée de la manière suivante :

• Fonction source : Conformément au contenu de l'exigence DB.SO.90 issu de la spécification projet DRIMBox, la fonction source présente un certificat IGC-Santé rattaché au FQDN atteint par la fonction consommatrice tierce.
• Fonction consommatrice : La fonction consommatrice présente le certificat IGC-Santé correspondant au FQDN déployé au sein de la fonction source qui lui est associée. Dans le cas où la fonction source qui lui est associée expose plusieurs FQDN (donc de facto possède plusieurs certificats), le choix du certificat à présenter est libre. 

L'accès à l'interface de la fonction consommatrice associée à une solution DRIMBox n'est possible qu'à partir d'une transaction d'appel contextuel initiée par un LPS de type RIS ou DPI. Suite à l'émission de la requête d'appel contextuel par le LPS, cinq réponses possibles peuvent être émises par la solution DRIMBox interrogée :  

• Réponse HTTP 303 See Other mentionnant un header "Location" associé à un URL absolu. Dans ce cas, le LPS doit effectuer une redirection vers l'URL mentionné au sein de la réponse 303.
• Réponse HTTP 303 See Other mentionnant un header "Location" associé à un URL relatif. Dans ce cas, le LPS doit effectuer une redirection vers un URL correspondant à la concaténation du hostname DRIMBox ciblé par la requête d'appel contextuel et le chemin relatif mentionné au sein de la réponse 303.
• Réponse HTTP 302 Found mentionnant un header "Location" associé à un URL absolu. Dans ce cas, le LPS doit effectuer une redirection vers l'URL mentionné au sein de la réponse 302.
• Réponse HTTP 302 Found mentionnant un header "Location" associé à un URL relatif. Dans ce cas, le LPS doit effectuer une redirection vers un URL correspondant à la concaténation du hostname DRIMBox ciblé par la requête d'appel contextuel et le chemin relatif mentionné au sein de la réponse 302.
• Réponse HTTP 400 Bad Request indiquant que la requête d'appel contextuel reçu par la DRIMBox ne satisfait pas aux exigences mentionnées au sein de la spécification projet DRIMBox (problème de format, paramètre manquant, ...). 

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)