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

Dans le cadre de la Vague 2 du programme Ségur, le financement de la DRIMbox est conditionné à la commande et à la mise en œuvre d’un RIS référencé Vague 2.
Il n’est pas interdit d’acquérir une DRIMbox hors financement SONS et de l’utiliser avec un RIS non référencé Vague 2, à condition que ce RIS dispose des fonctionnalités nécessaires pour échanger avec la DRIMbox.
Toutefois, cette configuration n’est pas recommandée : le client ne bénéficiera d’aucun financement SONS (ni pour le RIS, ni pour la DRIMbox) et il ne profitera pas des apports fonctionnels du RIS Vague 2, bien plus riches que de simples flux avec la DRIMbox.

Ces exigences indiquent que : 
- le logiciel utilisateur doit être habilité en tant qu’Éditeur de logiciel utilisateur à l’espace de confiance Pro Santé Connect (SC.PSC.14) 
- le Proxy e‑Santé doit être habilité en tant qu’Éditeur de Proxy e‑Santé à l’espace de confiance Pro Santé Connect (SC.PSC.16).
Ces habilitations sont indispensables avant de pouvoir demander le statut d’Opérateur correspondant (Opérateur de service utilisateur et Opérateur de Proxy e‑Santé).

La première étape consiste à passer par le guichet Éditeur de l’EDC PSC dans Convergence pour chacun des logiciels utilisateurs (composant principal) et pour le Proxy e‑Santé.
Une fois ces habilitations obtenues, l’éditeur doit également passer par le guichet Opérateur pour demander l’habilitation “Opérateur de logiciel utilisateur” pour les composants principaux et l’habilitation “Opérateur de Proxy e‑Santé” pour le Proxy.
Ces démarches sont nécessaires pour que la solution logicielle puisse bénéficier du dispositif de financement prévu par le Ségur.

Cf DSR Imagerie Vague 2, page 34 : DSR DRIMbox SEGUR du Numérique en Santé Vague 2

Pour une Solution Logicielle à référencer dans le cadre du Ségur Vague 2, il faut considérer la solution comme un ensemble :
- un composant principal ;
- un Proxy e‑Santé ;
et, le cas échéant, d'éventuels composants additionnels.
La Solution Logicielle dans son ensemble suit toutes les étapes de référencement (candidature, éligibilité, dépôt des preuves, etc.).
L’éditeur doit :
- Obtenir l’habilitation EDC PSC Editeur de logiciel utilisateur pour chaque composant principal ;
- Obtenir l’habilitation Espace de Confiance API PSC Editeur de Proxy e-santé pour le Proxy e-Santé. 
- Obtenir ensuite les habilitations Opérateurs de Services  correspondantes pour accéder aux financements et à l’espace de test CNDA.
Une fois les chapitres Prérequis et Maturité technique validés pour les deux parcours d’habilitation (logiciel et proxy), l’éditeur obtient l’accès aux environnements de test du CNDA.
Enfin, les habilitations Opérateur de service utilisateur (EDC PSC) doivent être demandées pour tous les composants principaux et l’habilitation Opérateur de Proxy e‑Santé pour le Proxy.
L’habilitation Opérateur de logiciel utilisateur sera notamment requise par l’ASP lors des demandes de financement.
Cf DSR Imagerie Vague 2, page 34 : DSR DRIMbox SEGUR du Numérique en Santé Vague 2

Le RIS est le seul système capable d’assurer un envoi cohérent, sécurisé et conforme des comptes rendus (CR) vers le DMP.
Conformément à la spécification RIS.TLR/INT.02, il demeure le point de diffusion officiel pour tous les CR issus de la téléradiologie :
- Les plateformes de téléradiologie agissent comme sous-traitants des services de radiologie. L’intégration des CR dans le RIS est donc indispensable pour garantir la traçabilité et la centralisation des données médicales.
- Un envoi direct par la plateforme entraînerait un risque d’incohérence documentaire : si un radiologue modifie un CR dans le RIS, plusieurs versions pourraient être présentes dans le DMP sans gestion de version.
- Ces plateformes ne sont pas des établissements de santé et ne disposent ni des certificats nécessaires, ni de l’agrément CNDA/Ségur requis pour transmettre elles-mêmes les documents au DMP.
Ainsi, même si le CR est validé sur la plateforme, seul le RIS est habilité à l’envoyer au DMP de façon fiable, sécurisée et conforme.

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. 

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. 

Les distributeurs doivent s'enrôler auprès de l'ASP pour pouvoir faire des demandes de financement pour les commandes qu'ils signeront. 

Pour qu'un distributeur puisse s'enrôler à l'ASP :

• il doit avoir été déclaré par l'éditeur dans le formulaire d'éligibilité dans l'outil Convergence.
• il doit disposer d'un mandat de distribution conclu avec l'éditeur.

Par ailleurs, si la solution est installée et opérée par l'éditeur et non par le distributeur revendeur pur, l'éditeur doit autoriser le distributeur à disposer de son habilitation Opérateur PSC (habilitation exigée pour faire des demandes de financement) explicitement dans le mandat, via la formulation suivante par 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."
 

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.  

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.