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

Oui, il est possible de modifier sa déclaration. Il est recommandé de faire ses arbitrages avant le dépôt des preuves car celles-ci pourraient être à requalifier.

Un Editeur de Logiciel Utilisateur (ELU) devra déclarer plusieurs dossiers s'il s'interface avec plusieurs Proxy e-Santé : 1 dossier par Proxy e-Santé.

Non. L’EAI tiers peut être intégré de deux manières :​

• Côté LPS (Composant Principal) : dans ce cas, il est intégré au logiciel utilisateur et l’ensemble doit être homologué par le CNDA.​
• Côté Proxy e-Santé : dans ce cas, l’EAI, intégré au Proxy e-Santé, sera homologué au CNDA. Le Proxy e-Santé en tant que tel n’a pas à être homologué au CNDA.  

Dans les deux cas, l’EAI doit être homologué par le CNDA, que ce soit intégré au LPS ou au Proxy e-Santé. 

Si une Solution Logicielle fait appel à plusieurs téléservices, elle doit avoir une architecture conforme pour être habilitée EDC PSC, c’est à dire disposer au minimum d’un Composant Principal LPS et d’un Proxy e-Santé.

Chaque composant doit être déclaré et suivi séparément pour son habilitation EDC PSC. 

L’éditeur de chaque composant doit assurer la conformité et la sécurité de son composant ainsi que des composants intégré ou interfacé avec lui, selon les exigences CNDA et PSC.​

Le Proxy e-Santé est utilisé pour sécuriser et standardiser les échanges entre le logiciel métier (Composant Principal LPS) et les API Pro Santé Connectées (DMP, INSi, Ordonnance Numérique, etc.).

Il gère les mécanismes d’authentification et de sécurité (mTLS, OAuth2, OpenID), facilite l’intégration technique, et permet de mutualiser certains développements.

Même si cela ajoute de la complexité, le Proxy e-Santé est obligatoire pour répondre aux exigences réglementaires et garantir la conformité des accès.​

• L'Éditeur de Logiciel Utilisateur développe le Composant Principal (LPS) et notamment son Interface Homme Machine (IHM) qui sera utilisée par le professionnel de santé. Le LPS gérera des règles métiers.​
• L'Editeur de Logiciel Proxy e-Santé édite le Proxy e-Santé qui est une brique technique assurant les liens techniques et de sécurité entre le LPS et les APIs des services socles, comme le DMP. Le Proxy e-Santé peut aussi gérer la création et le formatage de certaines requêtes métiers.

La définition du périmètre des tests d’intrusion relève de la responsabilité de l’éditeur, en fonction des cas d’usage et de l’architecture de la solution. Le processus générique est le suivant :

1. L'éditeur prend connaissance du périmètre du REM et candidate pour une solution dont il donne le nom et la version.
    
2. L’éditeur a la responsabilité de présenter à l’auditeur le périmètre concerné par le test d’intrusion, en s’appuyant sur sa connaissance de la solution et en se portant garant de la justification apportée.
    
3. L'auditeur doit mentionner dans le rapport de pentest le nom/version de l'application concernée.
    
4. Le guichet conformité vérifie que le nom et la version de l’application concernée correspondent à ceux déclarés par l'éditeur, et que le rapport est conforme aux exigences.

La mention de l'autorité d'affectation associée à l'identifiant IPP au sein de la requête d'appel contextuel est indiqué en section 4.6.1 de la spécification projet DRIMBox (paramètre PatientIDIssuer). A ce jour, il n'existe pas de définition explicite quant à la valeur devant être associée à ce paramètre lors de la génération des requêtes d'appel contextuel.

Cependant, l'implémentation d'un mécanisme basé sur la structure HL7v2 du sous-composant 4 associé au champ PID-3 est encouragée. Dans ce cadre, nous recommandons de mentionner l'ensemble du segment CX-4 (composé des éléments 4.1, 4.2 et 4.3) en tant que valeur associée au paramètre PatientIDIssuer au sein de la requête d'appel contextuel.

Toutefois, en pratique, la valeur associée à ce paramètre doit demeurer modulable afin de s'adapter au contexte et à l'environnement de déploiement propre à chaque solution logicielle. Ainsi, il peut être envisagé que le système appelant ne renseigne que les éléments CX-4.1, CX-4.2 ou une combinaison de ceux-ci pour le paramètre "PatientIDIssuer" au sein de la requête d'appel contextuel. 

La spécification projet DRIMBox visionneuse définit en section 4.2.2 la structure de l'URL d'accès à la visionneuse associée à la fonctionnalité source DRIMBox.

Un tableau y est notamment mentionné afin de récapituler les contraintes s'appliquant à chacun des trois paramètres figurant au sein de l'URL : StudyInstanceUID, Accession Number et Identifiant compte-rendu. 

Par conséquent, il est attendu que les solutions logicielles DRIMBox se conforment à cette spécification concernant la structure des URL permettant de les atteindre.

L'accès à l'interface de la fonction consommatrice associée à une solution DRIMBox n'est possible qu'à partir d'une transaction d'appel contextuel initiée par un LPS de type RIS ou DPI. Suite à l'émission de la requête d'appel contextuel par le LPS, cinq réponses possibles peuvent être émises par la solution DRIMBox interrogée :

• Réponse HTTP 303 See Other mentionnant un header "Location" associé à un URL absolu. Dans ce cas, le LPS doit effectuer une redirection vers l'URL mentionné au sein de la réponse 303.
   
• Réponse HTTP 303 See Other mentionnant un header "Location" associé à un URL relatif. Dans ce cas, le LPS doit effectuer une redirection vers un URL correspondant à la concaténation du hostname DRIMBox ciblé par la requête d'appel contextuel et le chemin relatif mentionné au sein de la réponse 303.
   
• Réponse HTTP 302 Found mentionnant un header "Location" associé à un URL absolu. Dans ce cas, le LPS doit effectuer une redirection vers l'URL mentionné au sein de la réponse 302.
   
• Réponse HTTP 302 Found mentionnant un header "Location" associé à un URL relatif. Dans ce cas, le LPS doit effectuer une redirection vers un URL correspondant à la concaténation du hostname DRIMBox ciblé par la requête d'appel contextuel et le chemin relatif mentionné au sein de la réponse 302.
   
• Réponse HTTP 400 Bad Request indiquant que la requête d'appel contextuel reçu par la DRIMBox ne satisfait pas aux exigences mentionnées au sein de la spécification projet DRIMBox (problème de format, paramètre manquant, ...).