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

Conformément aux exigences prévues au chapitre 4 des DSR et à la section 4.3 de l’Appel à financement, pour les solutions logicielles pour lesquelles vous souhaitez mobiliser des financements Ségur, la déclaration de l’ensemble des versions techniques ayant fait l’objet d’une information publique auprès de vos clients concernant un arrêt de maintenance et/ou un arrêt de commercialisation est obligatoire.

À cet effet, le fichier modèle de déclaration des versions obsolètes, disponible dans le formulaire d’éligibilité, doit être complété. Dans le cas où aucune version obsolète n’est à déclarer, cette situation devra être explicitement mentionnée dans le fichier dédié. 

Cette démarche est un prérequis obligatoire à l’obtention du financement Ségur vague 2.

Le corpus documentaire associé au projet DRIM-M comporte deux éléments définissant l'affichage de l'intégralité des traits stricts INS au sein de l'interface DRIMBox consommatrice : l'exigence INS/va1.36 issue du REM DRIM-M ainsi que la section 4.6.2 de la spécification projet DRIMBox.

Ainsi, l'utilisateur doit être en mesure de consulter les données d'identification patient suivantes au démarrage de la DRIMBox :

• Nom de naissance : affichage par défaut au lancement de l'interface utilisateur.
• Premier prénom de naissance : affichage par défaut au lancement de l'interface utilisateur.
• Date de naissance : affichage par défaut au lancement de l'interface utilisateur.
• Sexe : affichage par défaut au lancement de l'interface utilisateur.
• Lieu de naissance : affichage par défaut au lancement de l'interface utilisateur.
• Matricule INS : affichage possible via paramétrage de l'utilisateur. (existence du champ obligatoire)
• Nature du matricule INS (OID) : affichage possible via paramétrage de l'utilisateur. (existence du champ obligatoire)
• Liste des prénoms de naissance : affichage possible via paramétrage de l'utilisateur. (existence du champ obligatoire)
• Prénom utilisé : affichage possible via paramétrage de l'utilisateur. (existence du champ obligatoire)
• Nom utilisé : affichage possible via paramétrage de l'utilisateur. (existence du champ obligatoire)

En considérant le workflow global de consultation de données de santé associé à la fonction consommatrice DRIMBox, deux flux permettent à cette dernière d'avoir connaissance de l'intégralité des traits stricts INS du patient ciblé :

• Transaction d'appel contextuel initiée par un système LPS à destination de la solution DRIMBox (Cf. section 4.6.1 de la spécification projet DRIMBox). Dans le cadre de cette interaction, le LPS transmet les traits INS suivants à la solution DRIMBox : Nom de naissance ; Premier prénom de naissance ; Date de naissance ; Sexe ; Lieu de naissance ; Matricule INS ; Nature du matricule INS (OID).
• Transaction TD3.1 initiée par la solution DRIMBox vers l'environnement DMP afin de récupérer les lots de soumission associés aux documents publiés sur ce dernier. Suite à cette interaction, la solution DRIMBox récupère l'intégralité des traits INS associés au patient ciblé (au travers des métadonnées "sourcePatientId" et "sourcePatientInfo").

Ainsi, parmi l'exhaustivité des traits stricts INS, trois d'entre eux ne peuvent être connus de la fonction consommatrice DRIMBox qu'à la suite d'une transaction TD3.1 vers le DMP : Liste des prénoms de naissance ; Prénom utilisé ; Nom utilisé.

Par conséquent, le workflow associé au lancement de la fonction consommatrice DRIMBox a été défini afin de tenir compte de ces aspects, pour rappel :

1. Mise en oeuvre d'une transaction d'appel contextuel, initiée par un système LPS à destination de la fonction consommatrice DRIMBox.
2. Authentification de l'utilisateur via ProSantéConnect.
3. Interaction TD3.1 entre la solution DRIMBox et l'environnement DMP permettant de récupérer les métadonnées XDS associées aux documents d'intérêt publiés sur le DMP.
4. Ouverture de l'interface DRIMBox (fonction consommatrice) présentant les résultats de la transaction TD3.1.

Au sein du workflow présenté ci-dessus, la combinaison entre les étapes n°1 et n°3 implique que l'intégralité des traits stricts INS du patient soient connus de la solution DRIMBox au démarrage de son interface.

La dernière version de ce document est disponible sur la page dédiée du dispositif concerné ainsi que via son lien de téléchargement direct : 

La date de la version publiée est par ailleurs indiquée sur le lien de téléchargement du document.

Pour votre information, voici un historique des versions publiées : 

Les spécificités des DRIMbox font que certains flux sont effectivement en HTTP et ne peuvent être protégés par l’utilisation du chiffrement.

Les flux suivants font exception au point de contrôle C17 :

• Défi ACME HTTP-01,
• URL de téléchargement des CRLs IGC Santé et CRLs IGC du marché,
• URL de téléchargement des ACs IGC Santé et ACs IGC du marché,
• Répondeur OCSP IGC Santé et IGC du marché.

Tous les autres flux doivent être protégés par l’utilisation du chiffrement.

NB : pour les quatre types de flux cités, les réponses sont sécurisées : 

• Le protocole ACME utilise l'empreinte d'une clé de compte,
• Les CRLs sont signées par la clé privée de l'AC intermédiaire de l'IGC,
• L'AC intermédiaire est signée par la clé privée de l'AC RACINE, et l'AC RACINE est signée par sa clé privée,
• Le service OCSP signe ses réponses vers le client qui envoie la requête.

Les preuves sont analysées une fois que l'ensemble du chapitre est complet et soumis.

Oui, un composant "EAI/librairie" non autonome intégré dans le proxy doit passer son agrément au CDNA pour obtenir sa propre homologation.

En cas d'identification d'erreurs non légitimes, vous pouvez contacter l'adresse support monserviceclient.mssante@esante.gouv.fr en précisant dans l’objet « [MOTCO2] ».

L'équipe support prendra contact avec vous après analyse des traces fournies. Eventuellement MOTCO2 devra évoluer pour prendre en charge votre spécificité.

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.

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

2. 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].

3. Quand appliquer ce changement ?

Immédiatement, pour toutes les implémentations, vérifications et homologations en cours ou à venir.

4. Quelles obligations pour l’éditeur ?

Se conformer à la version GI DMP 2.10 – API PSC [DMP4].

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.