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

Dans le cadre du déroulement des scénarios de test d'interopérabilité associés au processus d'homologation SEGUR vague 2 DRIM-M, l'intégration de documents KOS au sein d'une solution DRIMBox peut être demandé en tant que prérequis. L'objectif d'un tel processus consiste à limiter les interactions entre la solution DRIMBox et l’environnement de test DMP.

Deux situations doivent alors être distinguées en fonction du rôle joué par la solution DRIMBox au sein de laquelle le ou les documents KOS doivent être intégrés : 

• Fonction source : L'intégration d'un document KOS préalablement au déroulement d'un scénario de test permet de simuler une situation de première publication réussie de celui-ci auprès de l'environnement DMP, et ainsi de focaliser les étapes de test sur la gestion du cycle de vie du document KOS (mise à jour, dépublication) ainsi que sur la capacité de la solution DRIMBox à répondre à une requête WADO-RS (mise en œuvre des contrôles auprès de l'archive locale). 
  Sans ce prérequis d'intégration d'un document KOS au sein de la solution DRIMBox, plusieurs étapes de test supplémentaires auraient été nécessaires afin de se trouver dans les conditions permettant de réaliser le workflow demandé.  
• Fonction consommatrice : L'intégration de documents KOS préalablement au déroulement d'un scénario de test permet de pouvoir utiliser les fonctionnalités standards de la solution à son démarrage (navigation, visualisation/export des images référencées), sans qu'une transaction de consultation auprès du DMP soit nécessaire.

Afin de satisfaire aux prérequis d'intégration de documents KOS, plusieurs processus peuvent être envisagés. Ceux-ci sont également à distinguer en fonction du rôle joué par la solution DRIMBox concernée : 

• Fonction source :
  • Le ou les documents KOS peuvent être intégrés au sein de la solution DRIMBox au travers d'un mécanisme classique de génération, puis publication auprès de l'environnement de test DMP. A cet effet, l'ANS met à disposition un ensemble de jeux de données HL7v2, CDA, DICOM permettant de réaliser intégralement ce workflow et ainsi d'aboutir à une solution DRIMBox dont l'archive locale contient les documents KOS ciblés.
  • Le chargement de documents KOS au sein de la solution DRIMBox peut également être effectué au moyen d'un import d'archive IHE-XDM, sous réserve de ne pas activer automatiquement la fonction de resynchronisation, cf. exigence DB.SO.28 issue de la spécification projet DRIMBox. Dans ce cas, l'archive IHE-XDM doit être construite par le participant à partir des jeux de données mis à disposition par l'ANS.
  • Enfin, tel qu'envisagé au sein de la section 4.7 de la spécification projet DRIMBox, les documents KOS ciblés ainsi que les métadonnées associées peuvent être intégrés directement au sein de l'archive locale de la solution DRIMBox au moyen d'un mécanisme propriétaire. 
     
• Fonction consommatrice :
  • Le ou les documents KOS peuvent être intégrés au sein de la solution DRIMBox au moyen d'un mécanisme classique de consultation auprès de l'environnement de test DMP. Cependant, cela implique que le ou les documents KOS ainsi consultés doivent avoir préalablement été publiés au sein de l'environnement de test DMP. Implicitement, cet aspect fait donc également partie des responsabilités du participant dans le cas où le processus de consultation classique est mis en œuvre.
  • De la même manière que pour la fonction source, les documents KOS ciblés peuvent être intégrés directement au sein de l'interface de la solution DRIMBox au moyen d'un mécanisme propriétaire. Dans ce cas, l’affichage des documents KOS présentés à l’utilisateur au démarrage de la solution DRIMBox peut présenter un mode dégradé car certaines informations sont normalement issues des métadonnées XDS récupérées auprès de l'environnement DMP. 

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 :

1. Se connecter avec un compte à privilège dont la durée de validité a été dépassée
2. Mettre en évidence que le système impose à l'utilisateur un changement de son mot de passe
3. 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
4. Mettre en évidence le refus du changement de mot de passe
5. 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
6. Mettre en évidence le refus du changement de mot de passe
7. 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
8. Mettre en évidence le refus du changement de mot de passe
9. 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
10. Mettre en évidence le refus du changement de mot de passe
11. Effectuer une tentative de changement de mot de passe à l'aide d'un mot de passe précédemment utilisé
12. Mettre en évidence le refus du changement de mot de passe
13. Effectuer une tentative de changement de mot de passe à l'aide d'un mot de passe satisfaisant l'ensemble des critères
14. Mettre en évidence la réussite du changement de mot de passe
15. Effectuer une tentative de connexion au compte à l'aide d'un mot de passe erroné et répéter l'opération
16. 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

Afin de tester l'intégralité des mécanismes de contrôle implémentés par les Solutions DRIMBox candidates au référencement SEGUR DRIM-M, certaines situations "non-passantes" sont intégrées au sein des scénarios de test définis dans ce contexte.

Ces cas d'erreur peuvent résulter de l'exploitation de jeux de données volontairement corrompus ou d'interaction entre la solution DRIMBox et un simulateur présentant un défaut de configuration intentionnel.

Il est donc cohérent que pour ces situations l'utilisateur constate un résultat d'exécution non-passant au sein de l'interface du simulateur/validateur. 

Oui, une société identifiée par un SIREN, par exemple une SCM permettant à des radiologue de partager des équipements, peut signer une commande Ségur IMG Vague 2, dès lors que ses bénéficiaires portent une activité non nulle en 2023 de radiologie et/ou de médecins nucléaire.

Conformément à l'AF, en tant que Fournisseur, le Distributeur doit en effet disposer de l'habilitation « Opérateur de service utilisateur » de l’Espace de confiance Pro Santé Connect (EDC PSC) pour la Solution qu'il distribue, pour pouvoir faire des demandes de financement auprès de l'ASP.

Cependant, si la Solution est installée et opérée par l'Editeur et non par le Distributeur, celui-ci agissant comme "revendeur pur" (par exemple : cas d'une Solution SaaS), l'Editeur peut autoriser son Distributeur à disposer de son habilitation Opérateur PSC.

Cette autorisation sera mentionnée dans le mandat établi entre l'Editeur et son Distributeur, pour exemple :

"Dans la mesure où l’Editeur opère la Solution en production, l’Editeur autorise le Distributeur à disposer, dans le cadre des demandes d’avance SONS-IMG-DB-va2, de l'habilitation « Opérateur de service utilisateur » de l’Espace de confiance Pro Santé Connect (EDC PSC), obtenue par l'Editeur pour la Solution."

L'EntryUUID correspond à un identifiant de ressource, affecté dans un contexte d'enregistrement d'un document au sein de l'environnement DMP. La valeur de cet identifiant est fixée par le DMP lui-même, suite à une publication ou une mise à jour du document en question. 

Dans le cadre de la publication d’un document KOS par la fonctionnalité source d'un logiciel DRIMBox, le lot de soumission envoyé à destination de l'environnement DMP ne doit pas mentionner de valeur pour la métadonnée "XDSDocumentEntry.entryUUID". Suite à la réception de l'acquittement de publication du document KOS au sein de l'environnement DMP, le logiciel DRIMBox n’est pas tenu de sauvegarder l’EntryUUID affecté au document par le DMP.

En revanche, afin d'effectuer un remplacement ou une dépublication d'un document KOS auprès de l'environnement DMP, il est nécessaire d'avoir préalablement connaissance de la valeur de l’identifiant EntryUUID associée du document. Cette valeur peut être récupérée au moyen d'une transaction spécifique (TD3.1b - Recherche d’identifiant technique, telle que définie au sein du Guide d'Intégration DMP). 

De manière générale, il est préconisé de ne pas sauvegarder la valeur de l'identifiant EntryUUID au sein du logiciel DRIMBox après une transaction de publication ou de remplacement d'un document KOS auprès de l'environnement DMP. En effet, celle-ci est susceptible d'évoluer suite à une modification du document effectuée directement depuis l'interface du Web-PS DMP. Ainsi, même si elle est archivée au sein du logiciel DRIMBox, cette valeur ne pourra pas être réutilisée directement sans que l'opérateur ne s'assure au préalable qu'aucune modification intermédiaire du document KOS n'a eu lieu. 

Concernant le contexte d'export de l'archive locale d'un logiciel DRIMBox au format IHE-XDM, les spécifications associées indiquent qu'il est obligatoire de mentionner une valeur d’EntryUUID au sein des lots de soumission composant l'archive (pour plus de précisions, se référer au volet CI-SIS Echange de Documents de Santé). Dans ce cadre, nous préconisons que le logiciel DRIMBox soit en mesure de générer ses propres valeurs d'identifiant EntryUUID, afin de compléter les différents lots de soumission composant l’archive au format IHE-XDM.

Conformément aux indications formulées au sein du référentiel Espace de Confiance ProSantéConnect ainsi que du volet CI-SIS relatif aux API ProSantéConnect, une connexion mTLS est exigée entre le proxy e-santé et l'environnement ProSantéConnect. En complément, cette connexion mTLS doit être mise en œuvre dans le cadre d'une authentification OAuth 2.0 et conformément au référentiel RFC 8705. 

En conséquence, il n'est pas nécessaire de mettre en oeuvre l'utilisation d'un "client_secret". Cette indication s'applique également dans le cadre des interactions entre le proxy e-santé et les APIs ProSantéConnect (API PSC DMP notamment). 

Il est important de noter que la ou les clés privées associées au(x) certificat(s) client mis en œuvre dans le cadre de la connexion mTLS mentionnée ci-dessus doivent être archivées au sein d'un keystore sécurisé implémenté directement sur le proxy e-santé.

Dans le cas d'une architecture composée de plusieurs logiciels DRIMBox d'un même opérateur en hébergement "On Premise" au sein de différents établissements de santé et d'un proxy e-santé mutualisé pour l'intégralité de ces déploiements, il n'est pas nécessaire de démultiplier les commandes de l'ensemble des certificats. En effet, dans ce cas, seul un "Client_ID" attribué par ProSantéConnect et un certificat "ORG_AUTH_CLI" (CN=Client_ID de l'opérateur DRIMbox et OU=idStructure de l'opérateur proxy) sont à implémenter. 

Une fois obtenu, suite à une demande de Datapass effectuée par l'opérateur, l'identifiant Client_ID pourra être intégré à tous les logiciels DRIMBox déployés au sein de l'architecture mentionnée ci-dessus. Cet aspect n'est pas spécifique au projet DRIM-M, il s'agit d'un processus déjà documenté dans le cadre des architectures communautaires utilisant le service ProSantéConnect.

En revanche dans le cadre des interactions effectuées directement entre les logiciels DRIMBox composant l'architecture mentionnée ci-dessus et le service ProSantéConnect (endpoint d'introspection notamment), il est nécessaire de mettre en œuvre un certificat ORG_AUTH_CLI propre à chaque logiciel DRIMbox (CN=Client_ID et OU=SIRET opérateur DRIMbox).

Trois phases peuvent être distinguées afin d'assurer la gestion du cycle de vie d'un examen d'imagerie au niveau de l'archive locale associée au logiciel DRIMBox :

1. Dans le cadre de la réalisation d'un examen d'imagerie, un compte-rendu d'imagerie ainsi qu'un ensemble d'images médicales sont produits. Ces informations, une fois envoyées à la fonctionnalité source du logiciel DRIMBox, permettent la création d'un document KOS mentionnant l'ensemble des informations à utiliser afin d'accéder ultérieurement aux images. Une fois le document KOS créé par le logiciel DRIMBox et publié au sein de l'environnement DMP (transaction TD2.1a du Guide d'Intégration DMP), une nouvelle entrée est ajoutée au sein de l'archive locale de la DRIMBox (pour plus de précisions, voir section 4.5.7 de la spécification projet DRIMBox).
    
2. Dans le cadre d'une modification de contenu d'un examen d'imagerie (suppression/ajout d'images médicales, changement de visibilité du compte-rendu d'imagerie, ou autre), le document KOS associé doit être mis à jour en conséquence par le logiciel DRIMBox et remplacé au sein de l'environnement DMP (transaction TD2.1b du Guide d'Intégration DMP). Une fois la mise à jour effectuée auprès de l'environnement DMP, celle-ci doit également être répercutée au niveau de l'archive locale associée au logiciel DRIMBox. Cet ajustement aura pour conséquence un remplacement du document KOS archivé, ainsi que du lot de soumission associé (fichier METADATA.xml).
    
3. Dans le cadre d'une dépublication d'un compte-rendu d'imagerie ou en cas de suppression de l'intégralité des images associées à un examen d'imagerie médicale, alors le document KOS associé doit être dépublié de l'environnement DMP (transaction TD3.3c du Guide d'Intégration DMP). Conformément aux indications fournies en section 4.5.8.1 de la spécification projet DRIMBox, le document KOS sera alors identifié comme dépublié au niveau du stockage local. L’objet DICOM KOS en tant que tel peut éventuellement être supprimé de la base d’archivage, mais son identification et statut doivent être tracés afin de fournir une réponse précise lors de la demande d’accès aux images qu'il référence. 

Trois phases peuvent être distinguées afin d'assurer la gestion du cycle de vie d'un examen d'imagerie au niveau de l'archive locale associée au logiciel DRIMBox :

1. Dans le cadre de la réalisation d'un examen d'imagerie, un compte-rendu d'imagerie ainsi qu'un ensemble d'images médicales sont produits. Ces informations, une fois envoyées à la fonctionnalité source du logiciel DRIMBox, permettent la création d'un document KOS mentionnant l'ensemble des informations à utiliser afin d'accéder ultérieurement aux images. Une fois le document KOS créé par le logiciel DRIMBox et publié au sein de l'environnement DMP (transaction TD2.1a du Guide d'Intégration DMP), une nouvelle entrée est ajoutée au sein de l'archive locale de la DRIMBox (pour plus de précisions, voir section 4.5.7 de la spécification projet DRIMBox).
2. Dans le cadre d'une modification de contenu d'un examen d'imagerie (suppression/ajout d'images médicales, changement de visibilité du compte-rendu d'imagerie, ou autre), le document KOS associé doit être mis à jour en conséquence par le logiciel DRIMBox et remplacé au sein de l'environnement DMP (transaction TD2.1b du Guide d'Intégration DMP). Une fois la mise à jour effectuée auprès de l'environnement DMP, celle-ci doit également être répercutée au niveau de l'archive locale associée au logiciel DRIMBox. Cet ajustement aura pour conséquence un remplacement du document KOS archivé, ainsi que du lot de soumission associé (fichier METADATA.xml).
3. Dans le cadre d'une dépublication d'un compte-rendu d'imagerie ou en cas de  suppression de l'intégralité des images associées à un examen d'imagerie médicale, alors le document KOS associé doit être dépublié de l'environnement DMP (transaction TD3.3c du Guide d'Intégration DMP). Conformément aux indications fournies en section 4.5.8.1 de la spécification projet DRIMBox, le document KOS sera alors être identifié comme dépublié au niveau du stockage local. L’objet DICOM KOS en tant que tel peut éventuellement être supprimé de la base d’archivage, mais son identification et statut doivent être tracés afin de fournir une réponse précise lors de la demande d’accès aux images qu'il référence.