774 questions / réponses
774 questions / réponses
Pour le couloir Hôpital de Ségur V2, un raccordement à l’Espace Communautaire est suffisant.
L’habilitation EDC PSC n’est pas obligatoire pour le référencement dans ce cas. Il est cependant possible pour un logiciel DPI de demander une habilitation EDC PSC en dehors du Ségur.
Cette réponse vous a-t-elle été utile ?
L’ensemble de la Solution Logicielle, c’est-à-dire le Composant Principal LPS, le Proxy e-Santé et les Composants Additionnels interfacés avec le Composant Principal LPS ou le Proxy e-Santé, font partie de l’Espace de Confiance PSC.
Le Composant Principal LPS et le Proxy e-Santé doivent être habilité dans l’Espace de Confiance PSC selon son rôle.
Cette réponse vous a-t-elle été utile ?
Le délai de réponse dépend du traitement par l’équipe en charge, mais vous pouvez généralement démarrer vos développements dès la réception d’une réponse positive.
Il est conseillé de surveiller votre messagerie et l’espace de suivi pour être informé dès que l’autorisation est accordée.
Cette réponse vous a-t-elle été utile ?
- 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.
Cette réponse vous a-t-elle été utile ?
- Quel est le changement principal ?
Lors de la publication des REM RIS et DB, MDV et DCC le GIi DMP 2.10 [DMP4] était publié en version release candidate (RC) (pas d'homologation CNDA).
La version du GI DMP 2.9 [DMP5] a donc été pointée dans les exigences.
La publication officielle du GI DMP 2.10 API PSC intégrant toutes ces exigences, cette référence à la 2.9 n’est plus nécessaire et devient source d’erreur pour les candidats.
- Concrètement, qu’est-ce que ça implique ?
Les exigences concernées qui mentionnent GI DMP 2.9 [DMP5] peuvent désormais être lues comme faisant référence au GI DMP 2.10 – API PSC [DMP4].
- Quand appliquer ce changement ?
Immédiatement, pour toutes les implémentations, vérifications et homologations en cours ou à venir.
- Quelles obligations pour l’éditeur ?
Se conformer à la version GI DMP 2.10 – API PSC [DMP4].
Cette réponse vous a-t-elle été utile ?
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 :
- L'éditeur prend connaissance du périmètre du REM et candidate pour une solution dont il donne le nom et la version.
- 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.
- L'auditeur doit mentionner dans le rapport de pentest le nom/version de l'application concernée.
- 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.
Cette réponse vous a-t-elle été utile ?
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.
Cette réponse vous a-t-elle été utile ?
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.
Cette réponse vous a-t-elle été utile ?
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, ...).
Cette réponse vous a-t-elle été utile ?
Pour accéder aux informations renseignées en Vague 1, vous pouvez émettre une demande au support iSC via l'adresse de contact suivante : https://isconnect.esante.gouv.fr/enrollement/account/login/#contactus.
Cette réponse vous a-t-elle été utile ?