Besoin d’aide ? Toutes les réponses et ressources utiles pour les ENS

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.

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

Non, les exigences sont structurées en éléments de preuve distincts, qui doivent être déposés séparément, à leur emplacement respectif sur la plateforme Convergence, et ce en respectant les formats imposés.

Il sera demandé d'envoyer votre dossier de preuves en amont. Cet envoi sera suivi d’une visite sur site afin de vérifier certaines exigences. La procédure est semblable à celle du CNDA.

Si vous étiez en cours de référencement précédemment, alors vous devez candidater et déposer l'ensemble des preuves demandées, produites à partir de la version présentée en Référencement ("version candidate" de la Convention de Référencement)

L’exigence ETH.33 « Le Système DOIT intégrer dans son cycle de vie une démarche globale de développement durable. » concerne la société de TLC au sens large alors que l’exigence ETH.34 « Le Système DOIT mettre en œuvre des pratiques d'écoconception afin de réduire l’impact environnemental du service. » concerne le logiciel.

Au sujet de la démarche globale, il est attendu de prouver l’engagement de la société dans sa préoccupation au sujet de l’impact environnemental du numérique de la TLC. Vous devez démontrer une démarche d’évaluation, par exemple avoir un écolabel par un organisme indépendant, faire une autoévaluation, fournir un rapport annuel RSE avec description des activités, transmettre le pourcentage de salariés formés à l’écoconception. 

L’écoconception concerne la façon de coder le SI. 

Dans les deux cas, l’objectif est de réduire votre impact environnemental.

En accord avec l’exigence ETH 32 « Le Système DOIT être évalué à l'aune de l'impact environnemental de son utilisation au moyen de la méthode d'écoscore fournie par la DNS et l'ANS », il est attendu de réaliser le calcul de l'écoscore développé par la DNS et mis à disposition sur le site Ecoscore des applications de santé en cliquant sur « Calculer l’écoscore de son service numérique », en vous connectant sur votre compte iSC et en sélectionnant les services de téléconsultation. Pour vous aider au calcul de votre écoscore vous pouvez sollicité l’accompagnement par Greenspector via le Chat.

Evaluation des applications de téléconsultation

L'évaluation des applications de téléconsultation suit la même méthodologie que ce qui a été expliqué précédemment. Il existe cependant certaines adaptations :

• l’application côté patient (ou site web) est testée en parallèle de l’application côté professionnel de santé (ou site web), cela permet d'évaluer une téléconsultation dans des conditions proches de la réalité ; 
• les deux applications (ou les deux sites web) sont évaluées dans les mêmes conditions (en particulier avec la même plateforme matérielle) ; 
• les écoscore des deux applications (ou des deux sites web) sont mesurés indépendamment, un écoscore pour chacune d’elles, selon la méthodologie présentée précédemment ; 
• l'écoscore de la téléconsultation qui est produit est la moyenne des deux écoscore (l'écoscore « côté patient » et l’écoscore « côté professionnel de santé ») ; 
• les métriques de l'étape de téléconsultation sont basées sur une mesure d’une durée de 30 secondes pour une sollicitation raisonnée du banc de mesure. Cependant les indicateurs présentés dans l’analyse des ressources et de l’empreinte environnementale sont ensuite projetés sur une durée de téléconsultation moyenne, à savoir 15 minutes.