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

Vous pouvez contacter le support Convergence à cette adresse : ans-espacedetest.ci-sis@esante.gouv.fr.

Dans le cadre de votre référencement, vous devez utiliser l’Espace de tests d'interopérabilité Gazelle dédié au référencement [https://interop.referencement.esante.gouv.fr/], accessible via la plateforme iSC.

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. 

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.

Pour MSSanté, dans le PDF, on utilise la base « code » qui est imposée par le type code et son nom. Pour le DMP, on utilise le « title », qui sera visible des PS et patients. Pour certains documents ce dernier est imposé par le CI-SIS ; pour d’autres c’est à la main de l’utilisateur, idéalement sur proposition du logiciel (et cela correspond à l’exigence du GI DMP).

En accord avec la section 4.6.1 de la spécification projet DRIMBox, le mécanisme permettant à un utilisateur d'accéder à l'interface de la fonction consommatrice du logiciel DRIMBox est le suivant : Dans le cadre de la consultation d'un dossier patient au sein d'un LPS, l'utilisateur effectue une action déclenchant l'émission d'une requête d'appel contextuel à destination du logiciel DRIMBox. Suite à la réception de cette requête et à son traitement, le logiciel DRIMBox retourne une réponse HTTP 302 ou HTTP 303 mentionnant un lien de redirection vers son interface. Le LPS appelant réceptionne alors ce message de réponse et effectue la redirection indiquée.

Un ensemble d'informations complémentaires peuvent être précisées concernant le processus de traitement de la requête d'appel contextuel par la solution DRIMBox ainsi que la création d'une URL de redirection. Il est attendu que la réception d'une requête d'appel contextuel par le backend du logiciel DRIMBox entraîne la création d'une instance unique de frontend DRIMBox, associée aux informations issues du message reçu. L'accès à cette instance unique de frontend est rendue possible au travers d'une URL intégrant un UUID permettant de l'identifier. Cette URL d'accès est alors transmise au LPS appelant via le lien de redirection mentionné au sein du message de réponse HTTP 302/303. La robustesse du mécanisme de génération des UUID permettant d'identifier les différentes sessions créées par la solution DRIMBox peut être optimisée en y associant un timestamp.  

Il est à souligner que l'utilisation d'un cookie de session ne nous paraît pas indispensable afin d'assurer l'accès du LPS appelant au frontend de la solution DRIMBox. Dans le cas où un tel mécanisme est envisagé et que celui-ci échoue en raison d'un défaut d'utilisation du cookie de session, l'accès au frontend du logiciel DRIMBox doit tout de même être rendu possible. 
 

Dans le cadre du processus d'authentification à l'environnement DMP, préalable à la publication d'un document KOS, la fonction source de la solution DRIMbox doit utiliser un certificat ORG AUTH CLI, délivré par l’IGC-Santé et correspondant à la situation d’exercice du professionnel de santé ayant validé le compte-rendu d’imagerie associé. 
Afin de respecter la philosophie générale du projet DRIM-M, ainsi que l'ensemble des workflows définis au sein de la spécification projet DRIMBox, le choix du certificat à utiliser dans le cadre de l'authentification auprès de l'environnement DMP doit prioritairement être effectué en accord avec le segment "legalAuthenticator/assignedEntity/representedOrganization" mentionné au sein du compte-rendu d'imagerie associé à la production du document KOS à publier.
L'attribut PRT-8 mentionné au sein du message HL7v2 véhiculant le compte-rendu d'imagerie à destination de la solution DRIMBox doit théoriquement faire apparaître une information identique à celle référencée par le segment "legalAuthenticator/assignedEntity/representedOrganization" issu du document CDA. Le choix du certificat d'authentification à mettre en oeuvre auprès de l'environnement DMP peut donc également être effectué à partir de cet attribut. Cependant, nous priorisons une interprétation du contenu associé au compte-rendu d'imagerie afin de sélectionner le certificat à mettre en oeuvre. 
L'implémentation d'une vérification de cohérence systématique entre ces deux sources d'information (compte-rendu CDA / message HL7v2) par la solution DRIMBox n'est pas obligatoire, la responsabilité concernant la cohérence de ces données incombant  au système producteur du compte-rendu CDA et du message HL7v2 associé. Néanmoins, un tel contrôle peut être défini par les éditeurs de solutions DRIMBox s'ils le souhaitent . Dans ce cas, une situation non-passante (écart entre le document CDA et le message HL7v2 au niveau de la mention du professionnel de santé) doit interrompre le processus de production du document KOS et une alerte doit être remontée auprès de l'administrateur du système producteur de ces données.