Questions fréquentes

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. 

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. 

Le référentiel PSC se divise en deux grandes catégories d’espace :

1. L’Espace Communautaire (Communauté PSC) : Cet espace regroupe l’ensemble des fournisseurs de services qui utilisent Pro Santé Connect pour l’authentification des utilisateurs. Les exigences du référentiel Communauté PSC couvrent les aspects liés à l’authentification, à la gestion des utilisateurs, et à la sécurité des échanges d'informations.
2. L’Espace de Confiance (Extension Espace de Confiance PSC) : Ce périmètre étend les exigences du référentiel à ceux qui partagent des données sensibles au sein de l’écosystème de santé via les API Pro Santé Connectées. L’Espace de Confiance garantit des niveaux supplémentaires de sécurité et de conformité pour les services qui traitent des données à caractère personnel dans un cadre de confiance mutuelle.

Pour rejoindre l'Espace de confiance consultez la documentation de référence

Concernant l'authentification du fournisseur de service à Pro Santé Connect, l'accès s'effectue via le Client ID / Client Secret ou en MTLS pour l'Espace Communautaire et obligatoirement en MTLS pour l'Espace de Confiance.

Pour en savoir plus sur l'Espace Communautaire et l'Espace de Confiance, cliquer sur le lien suivant : lien

Une fois l'éligibilité d'une solution logicielle validée, 

• un éditeur peut modifier la liste de ses composants additionnels,
• dans la mesure ou le dépôt de preuve n'a pas été initié.

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)

Les preuves permettant une illustration non opérationnelle (maquette, capture d'un prototype, schéma) ne sont pas acceptées dans le cadre de la certification de conformité au référentiel d’interopérabilité et de sécurité des DMN. Seules les preuves démontrant la conformité de la version de l'environnement de recette de la solution sont recevables. 

Nous vous rappelons l’obligation de déployer la version de la solution ayant reçu la certification de conformité auprès des utilisateurs. L’utilisation d’une version non certifiée est susceptible d’entraîner des non-conformités et des risques pouvant impacter la sécurité et la qualité des services. Il est donc essentiel de veiller à l’implémentation et au maintien strict de la version validée afin de garantir la conformité aux exigences applicables.

Les preuves permettant une illustration non opérationnelle (maquette, capture d'un prototype, schéma…) ne sont pas acceptées dans le cadre de la certification de conformité au référentiel d’interopérabilité, de sécurité et d’éthique des SI de téléconsultation. Seules les preuves démontrant la conformité de la version de l'environnement de recette de la solution sont recevables. 

Nous vous rappelons l’obligation de déployer la version de la solution ayant reçu la certification de conformité du jalon en cours auprès des utilisateurs. L’utilisation d’une version non certifiée est susceptible d’entraîner des non-conformités et des risques pouvant impacter la sécurité et la qualité des services. Il est donc essentiel de veiller à l’implémentation et au maintien strict de la version validée afin de garantir la conformité aux exigences applicables.

Oui, vous pouvez engager une démarche d'homologation DMP au CNDA dès lors que vous disposez déjà des prérequis de maturité technique dans l'Espace de Confiance (EDC) Pro Santé Connect (PSC).

Oui, MOTCO 2 est un outil de test accessible via ce lien.

L'environnement reste accessible même après le référencement de votre solution et peut être utilisé en tant que "bac-à-sable" pour vos tests.