FAQ des industriels

Oui, l'appel contextuel via PSC du web PS DMP doit obligatoirement être implémenté dans le cadre de la vague 2.

Après la certification de la solution logicielle, le CNDA transmet à l’éditeur l’attestation de conformité ainsi que la lettre de référencement (ci-dessous). Les éditeurs apportent l'attestation de conformité comme preuve de certification à l’ANS.

Non, un distributeur n'a aucune action à réaliser pour le référencement de la solution. Le référencement de la solution est pris en charge par l'éditeur de la solution. Ce dernier doit déclarer ses distributeurs dans le dossier administratif du référencement Ségur. Un mandat de distribution devra également être fourni à l'ASP par le distributeur au moment de l'enrôlement au guichet ASP.

Cette habilitation est exigée pour toute demande de financement de prestation principale Ségur vague2 DRIMbox auprès de l'ASP. En tant qu'opérateur de la solution Ségur en production, le distributeur doit donc demander l'habilitation Opérateur de service utilisateur Espace de Confiance Pro Santé Connect pour la solution qu'il déploie et opère chez ses clients. 
Néanmoins, un distributeur revendeur pur qui s'appuie sur l'éditeur pour le déploiement et les opérations en production chez ses clients, pourra utiliser l'habilitation opérateur de service utilisateur Pro Santé Connect de l'éditeur dès lors que celui-ci l'y autorise. Cette autorisation devra faire l'objet d'une mention dans le mandat demandée par l'ASP au distributeur au moment de l'enrôlement. Par exemple : "Dans la mesure où les Prestation Ségur sont réalisées techniquement par l’Editeur, 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."

Le passage sur l'Espace de test interopérabilité pour la DRIMBox et Proxy e-santé illustrés au travers du schéma mentionné en section 4.1 du DSR DRIMBox illustrent le fait que ceux-ci pourront être initiés et déroulés en parallèle afin que l'obtention des habilitations à l'espace de confiance PSC du LPS et du Proxy e-santé soient finalisées au moment de l'instruction du dossier Segur.

Actuellement, le projet DRIM-M spécifie la possibilité qu'un patient puisse accéder à un service de visualisation de ses examens d'imagerie au moyen d'un lien URL positionné au sein des comptes-rendus d'imagerie associés. L'utilisation de ce sevice de visualisation implique que l'utilisateur (patient) soit en mesure de s'identifier auprès du dispositif FranceConnect+. Or, à l'heure actuelle, les différents fournisseurs d'identité associés au dispositif FranceConnect+ imposent  que l’utilisateur ait plus de 15 ans pour créer son identité numérique. En conséquence, un mineur de moins de 15 ans ne sera donc pas en mesure d'utiliser le service de visualisation de ses examens d'imagerie à partir de la consultation de ses comptes-rendus d’imagerie, FranceConnect+ étant le seul moyen d’authentification patient actuellement spécifié au sein des exigences associées au projet DRIM-M. 
Afin de pallier cette situation, une solution complémentaire peut être temporairement envisagée. Conformément à la note mentionnée au sein de la section 4.1 de la spécification projet DRIMBox visionneuse, il est possible de mettre les images à disposition du patient mineur via un support physique en attendant le déploiement du fournisseur d’identité en direct proposé par le service « Application Carte Vitale ». Cette méthode d’authentification, actuellement en cours de spécification par les acteurs institutionnels, devrait permettre de résoudre la situation évoquée. En effet, tel qu’envisagé actuellement, l’utilisateur patient aura à terme le choix entre deux méthodes d’authentification suite à une demande de visualisation d'un examen d'imagerie : FranceConnect et Application Carte Vitale. Ainsi, si l'utilisateur sélectionne la méthode d’authentification proposée par le service Application Carte Vitale, alors le titulaire de la carte vitale (càd parent) auprès de laquelle il est associé en tant qu'ayant droit (exemple : enfant) affilié à son régime sera en mesure de se connecter et de visualiser les images médicales associées au compte-rendu.

Le corpus documentaire associé au projet DRIM-M spécifie que les différents logiciels DRIMBox déployés doivent effectuer une récupération quotidienne du fichier de liste blanche mis à disposition par l'ANS. Suite à chacune de ces récupérations, le fichier de liste blanche obtenu doit être vérifié afin de prévenir d'éventuelles corruptions de celui-ci. 
Le processus de contrôle du fichier de liste blanche implique une vérification de la signature qui lui est associée . Pour cela, les informations mentionnées au sein du tag "X509Data" du document liste blanche doivent être exploitées. Ces données correspondent aux principales caractéristiques du certificat utilisé afin de signer le fichier de liste blanche ANS. 
Tel qu'indiqué au sein de la spécification projet DRIMBox, nous préconisons l'utilisation de l'outil eSignSanté afin de valider la conformité de la signature associée au fichier de liste blanche ANS (pour plus de précisions concernant cet outil, voir https://github.com/ansforge/esignsante). 
En complément, nous pouvons indiquer que dans le cadre de l'homologation SEGUR vague 2 DRIM-M, une preuve de mise en oeuvre du processus de vérification de la signature est demandée. Dans ce contexte, les informations suivantes peuvent permettre de répondre à certaines interrogations :   
* Autorité à l'origine de l'émission du certificat utilisé pour la signature de la liste blanche de test : http://igc-sante.esante.gouv.fr/AC%20TEST/ACI-EL-ORG-TEST.cer. 
* CRL associée au certificat  utilisé pour la signature de la liste blanche de test : http://igc-sante.esante.gouv.fr/CRL/ACI-EL-ORG-TEST.crl. 
* Le certificat à mettre en oeuvre afin de signer la preuve de vérification de la signature associée à la liste blanche de test doit être propre à chaque éditeur de solution DRIMBox. Ainsi, dans le cas où l'outil eSignSanté est utilisé, le fichier de configuration "config.json" doit être complété avec un certificat propriétaire au niveau de la section "proof". 

Les endpoints d'accès à un logiciel DRIMBox, tel que définis au sein du corpus documentaire associé au projet DRIM-M et tels que délivrés par le registre national ANS, comportent notamment deux paramètres : "ID_DRIMBox" (identifiant unique d'un logiciel DRIMBox) et "ID_Registre" (identifiant du fournisseur pour un site donné). 
Au vu des différents types d'architecture possibles pour le déploiement d'un logiciel DRIMBox, la gestion de ces paramètres peut soulever certaines interrogations. Afin de répondre à celles-ci, nous pouvons envisager deux architectures de déploiement d'un logiciel DRIMBox et étudier la gestion des paramètres "ID_DRIMBox" et "ID_Registre" qui en découle : 
* Cas d’un logiciel DRIMBox  au sein d'un établissement et utilisé par un radiologue ayant plusieurs situation AM (activités libérales). Dans cette situation, les URLs implémentés par le logiciel DRIMBox comporteront tous le même paramètre "ID_DRIMbox" et le même "ID_Registre" dans ce cas un seul logiciel DRIMBox et PACS sont déployés. Aussi une instance DRIMBox peut être utilisée par plusieurs professionels de santé comportant plusieurs situations d'exercice.
* Cas d’un logiciel DRIMBox avec un PACS desservant deux établissements. Dans cette situation, les URLs implémentés par le logiciel DRIMBox comporteront tous le même paramètre "ID_DRIMbox" puisqu'un seul logiciel DRIMBox est déployé. De manière identique, l'ensemble des URLs implémentés par le logiciel DRIMBox mentionneront le même "ID_Registre" puisqu'un seul site est identifié, depuis lequel sont desservis les deux établissements. 

Le corpus documentaire associé au projet DRIM-M n’impose pas de mise en œuvre d’une fonctionnalité de filtrage IP dans le cadre de l’implémentation du service Healthcheck par les logiciels DRIMBox. 
Cependant, si pour des raisons de sécurité ou autre un éditeur de logiciel DRIMBox souhaite que cette opération de filtrage ait lieu, alors l’implémentation de celle-ci doit inclure une composante flexible afin de pouvoir suivre les évolutions liées au contenu de la whitlelist des adresses IP utilisées par les sondes healthcheck. 
Une mise à jour « dynamique » de la whitelist des adresses IP associées aux sondes healthcheck semble dont être la solution à privilégier. Afin d’implémenter ce processus, nous vous invitons à consulter la page de questions utilisateurs associée au service BetterStack : https://betterstack.com/docs/uptime/frequently-asked-questions/#looking-for-a-machine-readable-list. Il y est notamment indiqué que la whitelist des adresses IP peut être récupérée de manière automatique au format .txt ou .json. Ce fichier mentionne les adresses IPv4 de l'exhaustivité des sondes déployées par BetterStack.
En complément de ces informations, nous pouvons indiquer que dans le cas où un décalage entre la whitelist IP implémentée au sein du logiciel DRIMBox et la whitelist IP mise à disposition par Betterstack conduirait à l’affectation d’un statut « hors service » associé à la DRIMBox au sein de la météo des services ANS, alors l'ANS sera en mesure d’investiguer afin de déterminer si le processus d’actualisation de la whitelist IP est en cause. Dans ce cas, une discussion entre les acteurs institutionnels et l’éditeur de logiciel pourrait avoir lieu afin d’arbitrer cette situation.

Tel qu'indiqué au sein de la spécification projet DRIMBox et précisé par le Guide d'Intégration à l'Espace de Confiance DRIM-M, seule une constatation de l'absence de mention du logiciel DRIMBox au sein de la liste blanche récupérée implique une interruption de service de celui-ci. 
En cas d'indisponibilité de la liste blanche supérieure à 48h (serveur inaccessible ou document récupéré inexploitable), le logiciel DRIMBox conserve la possibilité d'utiliser la précédente version de la liste blanche archivée localement.

Suite à la publication du décret du 8 octobre 2019, l’utilisation de l’Identité Nationale de Santé (INS) pour référencer les données de santé est obligatoire depuis le 1er janvier 2021 pour tous les logiciels, systèmes PACS compris.
Au sein du référentiel INS, l'ANS précise donc que, d'après les articles R. 1111-8-1 à R. 1111-8-7 du Code de la Santé Publique,  le numéro d'inscription au répertoire national d'identification des personnes physiques (dit « NIR » ou numéro de sécurité sociale) constitue désormais l'identifiant national dans les champs de la santé et du médico-social.
Les systèmes PACS doivent donc être en mesure de récupérer, de stocker et de transmettre le matricule INS au travers des échanges de données d'imagerie auxquels ils participent, en plus des autres traits stricts d'identités constituant l'Identité Nationale de Santé, le matricule seul n'étant pas suffisant pour différencier l'identité :
* Nom de naissance
* Premier prénom de naissance
* Date de naissance
* Sexe
* Code INSEE du lieu de naissance
Par ailleurs, il est également nécessaire de prendre en compte les traits d'identité complémentaires afin que le système PACS puisse se conformer au référentiel d'identitovigilance :
* Nom utilisé : nom utilisé par l’usager dans la vie courante, enregistré obligatoirement lorsque différent du nom de naissance
* Prénom utilisé : prénom utilisé par l’usager dans la vie courante, enregistré obligatoirement lorsque différent du premier prénom de naissance
Il est à noter que les interactions entre la DRIMbox et le(s) PACS, les requêtes ne sont pas basées sur l'INS mais sur le StudyInstanceUID, cela permet à la DRIMbox d'être déployée même si le PACS n'est pas encore INS compatible

Dans le cadre d'une dépublication d'un document KOS (suite à une dépublication du compte-rendu d'imagerie associé ou d'une suppression de l'examen d'imagerie référencé), le lot de soumission correspondant doit être construit par le logiciel DRIMBox à partir du contenu de l'archive locale correspondant aux précédentes étapes du cycle de vie dudit document KOS.

Dans le cadre du processus de consultation de documents KOS par la fonction consommatrice d'un logiciel DRIMBox, tel que défini au sein de la spécification projet DRIMBox, le premier acteur impliqué est le LPS initiant une requête d’appel contextuel. Dans ce cadre, le LPS est responsable de la qualification de l’intégralité des traits INS en amont de la construction de la requête d’appel contextuel émise à destination du logiciel DRIMBox. Ainsi, les traits d'identité INS qui sont réceptionnés par le logiciel DRIMBox peuvent être considérés comme « fiables ». 
A partir du contenu associé à la requête d'appel contextuel reçue, la fonction consommatrice du logiciel DRIMBox est en mesure d’interroger l'environnement DMP afin de déterminer quels documents d’intérêt doivent être présentés à l’utilisateur au sein de son IHM (Cf. transaction TD3.1 définie au sein du Guide d'Intégration DMP). 
A l'issue de cette première interaction avec l'environnement DMP, le logiciel DRIMBox récupère un certain nombre de métadonnées associées au contexte de publication du document d’intérêt. C’est uniquement à partir de cette étape que l'interface de consultation du logiciel DRIMBox peut être constituée (pour plus de précisions, se référer à l'exigence DB.CO.54 de la spécification projet DRIMBox). 
Les métadonnées récupérées par la fonction consommatrice du logiciel DRIMBox auprès de l'environnement DMP peuvent elles-mêmes être considérées comme « fiables » car résultant d’un contexte de publication du document KOS construit à partir de l’analyse d’un compte-rendu d’imagerie, lui-même issu d’une demande d’acte d’imagerie remplie par un professionnel de santé.
Ainsi, l’ensemble du processus aboutissant à l’affichage des informations au sein de l’IHM de la DRIMBox consommatrice permet de conserver une cohérence avec celles saisies initialement lors de la planification de l’examen d’imagerie du patient.

Dans le cadre d'une demande de consultation d'un document KOS par un professionnel de santé depuis l'interface du logiciel DRIMBox, ce dernier doit tout d'abord contrôler la consentement du patient à une telle opération (information véhiculée au travers du paramètre "InformationEtConsentement" mentionné au sein de la requête d'appel contextuel provenant du LPS). Ensuite, le logiciel DRIMBox doit  initier une transaction permettant d'effectuer un test d'existence du DMP et de récupérer les conditions d'accès à celui-ci (transaction TD0.2 mentionnée au sein du Guide d'Intégration DMP). Enfin, et si cela s'avère nécessaire, le logiciel DRIMBox doit ajouter une autorisation du professionnel de santé pour la consultation de ce DMP (pour plus de précisions à ce sujet, se référer à la transaction TD0.3 définie au sein du Guide d'Intégration DMP).

La spécification projet DRIMBox mentionne un ensemble d'éléments de filtrage devant être implémentés de manière obligatoire par les logiciels DRIMBox dans le cadre de la consultation de documents KOS, suite à leur récupération auprès de l'environnement DMP (pour plus de précisions, se référer à la section 4.6.2 du document). Trois critères de filtrage doivent à minima pouvoir être exploités par l'utilisateur : Modalité d'acquisition de l'examen ; Date d'acquisition de l'examen ; Région anatomique ciblée. 
En complément, le Guide d'Intégration DMP indique que le logiciel DRIMBox doit également proposer les éléments de filtrage suivants (pour plus de précisions, se référer aux exigences EX_3.1-1012, EX_3.1-1020, EX_3.1-1030) : Visibilité du document ; Date de publication du document ; Historique depuis la dernière connexion d’un professionnel de santé au DMP du patient.

Conformément au Guide d'Intégration DMP, il est nécessaire que le logiciel DRIMBox soit en mesure de s'identifier (via le jeton VIHF et le contenu du lot de soumission) et de s'authentifier (via le certificat de signature du lot de soumission) auprès de l'environnement DMP dans un contexte d'alimentation.

Trois modes d'authentification/identification sont ainsi envisageables : 
* Mode EJ : Utilisation du FINESS de l'entité juridique associée à la DRIMBox dans le cadre de l'identification. Utilisation du certificat de l'entité juridique associée à la DRIMBox dans le cadre de l'authentification. L'implémentation du mode EJ au sein du logiciel DRIMBox est cependant fortement déconseillée par le Guide d'Intégration DMP, car celui-ci sera à terme désactivé. 
* Mode EG : Utilisation du FINESS de l'entité géographique associée à la DRIMBox dans le cadre de l'identification. Utilisation du certificat de l'entité géographique associée à la DRIMBox dans le cadre de l'authentification.
* Mode EJ/EG : Utilisation du FINESS de l'entité géographique associée à la DRIMBox au sein des lots de soumissions envoyés à l'environnement DMP. Utilisation du FINESS de l'entité géographique ou juridique associée à la DRIMBox au sein des jetons VIHF transmis à l'environnement DMP. Utilisation du certificat de l'entité juridique associée à la DRIMBox dans le cadre de l'authentification.

Concernant le processus de création d'un document KOS associé à un examen d'imagerie, la première étape consiste en une récupération d'un compte-rendu d'imagerie par le logiciel DRIMBox, au moyen d'un flux HL7v2 ORU/MDM initié par un système RIS associé. A travers cette transaction, le logiciel DRIMBox aura connaissance du FINESS de l'entité géographique associée à la création du compte-rendu d'imagerie. Ainsi, dans le cadre de l'utilisation du mode d'authentification/identification EJ/EG au sein du logiciel DRIMBox, ce FINESS géographique pourra être mentionné dans le jeton VIHF ainsi que dans le lot de soumission transmis à l'environnement DMP. En revanche, il peut être nécessaire d'implémenter une table de correspondance entre FINESS géographique et FINESS juridique afin d'utiliser un certificat d'entité juridique dans le cadre de l'authentification du logiciel DRIMBox auprès de l'environnement DMP.

Pour plus de précisions concernant ce sujet, les ressources suivantes peuvent être consultées : 
* Guide d'Intégration DMP.
* https://esante.gouv.fr/quels-moyens-didentification-electronique-pour-quels-usages
* https://interop.esante.gouv.fr/ig/hl7v2/trans-cda-r2/mapping.html

Le contenu du Guide d'Intégration DMP ainsi que la définition technique fournie au sein de la spécification projet DRIMBox concernant la transaction d'appel contextuel, initiée par un LPS vers le logiciel DRIMBox, impliquent l'implémentation du mode d'accès "bris de glace" à l'environnement DMP au sein de ces deux types de logiciels (LPS et DRIMBox). En pratique, lorsqu'un professionnel de santé souhaite accéder aux examens d'imagerie d'un patient en situation d'urgence et sans avoir pu récupérer préalablement son consentement, alors le LPS procède à l'émission d'une requête d'appel contextuel vers le logiciel DRIMBox en y mentionnant la valeur "bris_de_glace" associée au paramètre "InformationEtConsentement". Suite à cela, le logiciel DRIMBox doit effectuer un accès à l'environnement DMP en mode bris de glace et adopter le comportement défini au sein des sections 2.2.2 et 3.2.2.1 du Guide d’intégration DMP.

Dans le cadre de la mise à jour d'un document KOS auprès de l'environnement DMP, le logiciel DRIMBox doit construire en amont un jeton VIHF afin de justifier son identification ainsi que son habilitation. Deux cas de figure sont ainsi à distinguer :
 

• Cas d'une mise à jour du document KOS suite à un ajustement du compte-rendu d'imagerie associé : Dans cette situation, le logiciel DRIMBox réceptionne le compte-rendu d'imagerie modifié au moyen d'un flux HL7v2 ORU/MDM initié depuis le système RIS associé. Les informations mentionnées au sein du compte-rendu d'imagerie (structure + utilisateur) sont à utiliser par le logiciel DRIMBox afin de créer un jeton VIHF propre au contexte de mise à jour.

• Cas d'une mise à jour du document KOS suite à un ajustement de contenu de l'examen d'imagerie associé :  Dans cette situation, le logiciel DRIMBox réceptionne l'information de mise à jour depuis le système PACS associé via un flux C-STORE IOCM ou HL7v2 OMI^O23. Les informations mentionnées au sein de l'archive locale du logiciel DRIMBox (précédent lot de soumissions associé au document KOS)  sont à utiliser par le logiciel DRIMBox afin de créer un jeton VIHF propre au contexte de mise à jour.

  
  Pour plus de précisions concernant ce sujet, deux référentiels peuvent être consultés : le volet CI-SIS Transport Synchrone pour Client Lourd et le Guide d’intégration DMP.

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é.