86 Questions/réponses
Ségur du numérique en santé Imagerie DRIMbox
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.
Cette réponse vous a-t-elle été utile ?
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 réponse vous a-t-elle été utile ?
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.
Cette réponse vous a-t-elle été utile ?
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.
Cette réponse vous a-t-elle été utile ?
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.
Cette réponse vous a-t-elle été utile ?
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.
Cette réponse vous a-t-elle été utile ?
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).
Cette réponse vous a-t-elle été utile ?
La structure d'un compte-rendu d'imagerie CDA référençant plusieurs examens d'imagerie, c'est à dire mentionnant plusieurs identifiants StudyInstanceUID, est conditionnée à la multiplicité des actes d'imagerie impliqués.
Dans le cas où seul un acte d'imagerie conduit à la réalisation des différents examens d'imagerie, alors le compte-rendu CDA associé doit référencer l'ensemble des identifiants StudyInstanceUID au sein d'un même segment ""documentationOf/serviceEvent"", via la multiplicité des attributs ""id"".
En revanche, dans le cas où un compte-rendu d'imagerie CDA référence plusieurs examens d'imagerie associés à des actes d'imagerie distincts, il est nécessaire de démultiplier le segment ""documentationOf/serviceEvent"" et d'associer un seul attribut ""id"" à chacun d'eux.
Quel que soit le cas de figure applicable, il est attendu que la solution DRIMBox soit en mesure d'extraire ces différents identifiants StudyInstanceUID du document CDA afin de générer les documents KOS associés.
Il est important de souligner que lorsqu'un compte-rendu d'imagerie référence plusieurs examens d'imagerie, il est possible que de multiples identifiants Accession Number, voire Order Placer Number, soient également présents (segment ""inFulfillmentOf"" du document CDA). Dans ce cas, et conformément aux volets CI-SIS Références d'Objets d'un examen d'imagerie et Partage de Documents de Santé, le document KOS ainsi que le lot de soumission associés à un unique examen d'imagerie doivent référencer l'intégralité des Accession Number et Order Placer Number mentionnés au sein du compte-rendu d'imagerie. En effet, lors de l'interprétation du document CDA par la solution DRIMBox, aucun élément tangible ne permet d'effectuer une correspondance entre les identifiants OrderPlacerNumber / AccessionNumber / StudyInstanceUID. Face à ce constat, le plus pertinent consiste à référencer l'ensemble des identifiants OrderPlacerNumber et AccessionNumber potentiellement associés à un StudyInstanceUID au sein du document KOS et du lot de soumission XDS associés. "
Cette réponse vous a-t-elle été utile ?
Le scénario SSI/IAM.92.01 relatif aux preuves de conformité sur la gestion des mots de passe a fait l'objet d'une évolution.
Afin d’harmoniser les exigences sur l’ensemble des couloirs, le scénario modifié s’applique désormais à tous les éditeurs qui candidatent sur les guichets RIS et DRIMBox.
Qu’est-ce qui change concrètement ?
Le scénario précédent pour RIS et DRIMbox prévoyait un blocage du compte après 5 échecs de changement de mot de passe.
Désormais, conformément au scénario harmonisé, il faut :
- Réaliser une tentative de connexion erronée répétée,
- Mettre en évidence le blocage du compte après un nombre d’échecs consécutifs au plus égal à 10 (et non plus après 5 échecs de changement de mot de passe).
Le scénario attendu est le suivant : Scénario de conformité : SSI/IAM.92.01
Vérifier la mise en place d'une politique de mots de passe robuste pour les comptes à privilèges
Etapes du scénario :
- Se connecter avec un compte à privilège dont la durée de validité a été dépassée
- Mettre en évidence que le système impose à l'utilisateur un changement de son mot de passe
- Effectuer une tentative de changement de mot de passe à l'aide d'un mot de passe ne respectant pas la limite de 15 caractères
- Mettre en évidence le refus du changement de mot de passe
- Effectuer une tentative de changement de mot de passe à l'aide d'un mot de passe ne respectant pas la présence d'une majuscule
- Mettre en évidence le refus du changement de mot de passe
- Effectuer une tentative de changement de mot de passe à l'aide d'un mot de passe ne respectant pas la présence d'un chiffre
- Mettre en évidence le refus du changement de mot de passe
- Effectuer une tentative de changement de mot de passe à l'aide d'un mot de passe ne respectant pas la présence d'un caractère spécial
- Mettre en évidence le refus du changement de mot de passe
- Effectuer une tentative de changement de mot de passe à l'aide d'un mot de passe précédemment utilisé
- Mettre en évidence le refus du changement de mot de passe
- Effectuer une tentative de changement de mot de passe à l'aide d'un mot de passe satisfaisant l'ensemble des critères
- Mettre en évidence la réussite du changement de mot de passe
- Effectuer une tentative de connexion au compte à l'aide d'un mot de passe erroné et répéter l'opération
- Mettre en évidence le blocage du compte après un nombre défini d'échecs de connexion consécutifs au plus égal à 10
Notez que le scénario s’applique immédiatement pour tous les futurs dépôts. Le mécanisme de preuve reste inchangé (Capture vidéo montrant le bon déroulé du scénario de conformité).
Que dois-je faire si mes preuves sont déjà réalisées ou en cours de réalisation ?
- Si vos preuves n’ont pas encore été déposées, appliquez directement le scénario harmonisé.
- Si vos preuves ont déjà été déposées selon l’ancienne version, préparez une mise à jour conforme au nouveau scénario pour répondre aux demandes de modification.
Pour toute question, nous vous invitons à contacter le support Industriels Ségur : Formulaire de contact
Cette réponse vous a-t-elle été utile ?
Les preuves requises consistent en des captures d'écran ou des séquences vidéo illustrant les mesures de gestion des accès et des identités.
Cette réponse vous a-t-elle été utile ?
Non, chaque éditeur est libre d'utiliser le type de fichier de son choix tant que la fonctionnalité demandée par l'exigence est disponible.
Cette réponse vous a-t-elle été utile ?