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

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.

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 du dispositif DRIMbox 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
• Premier prénom de naissance
• Date de naissance
• Sexe
• Lieu de naissance
• Matricule INS
• Nature du matricule INS (OID)
• Liste des prénoms de naissance
• Prénom utilisé
• Nom utilisé

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.  

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 suppression de l’exigence DB.SO.106 initialement référencée au sein du REM DRIM-M a été actée suite à la constatation de son inapplicabilité. 

La mise à jour du REM DRIM-M n’ayant à l’heure actuelle pas été mise en œuvre au sein de la plateforme Convergence, l'exigence DB.SO.106 reste assignée aux candidatures à l’homologation SEGUR vague 2 pour les solutions DRIMBox. 

Par conséquent, la preuve de test associée à l'exigence DB.SO.106 peut être renseignée avec la mention « Non applicable au REM DRIM-M » en attendant une mise à jour corrective ultérieure de la plateforme Convergence.

Conformément au DSR, vous devez nous transmettre l’attestation d’homologation. A défaut, il est autorisé de déposer au plus tard au jalon date 2 (15/12), date de dépôt du dossier complet de preuves de conformité, une attestation de pré examen du dossier d’obtention de l’homologation concernée (ou une copie d’écran de votre espace personnel CNDA), attestant le dépôt auprès du CNDA de toutes les preuves nécessaires à ladite homologation. 
Si vous ne disposez pas des documents des documents mentionnés ci-dessu, mais que pour autant vous souhaitez soumettre le chapitre pour instruction côté équipe Référencement, vous pouvez déposer une copie d'écran de votre espace CNDA. Ce document (copie d'écran CNDA) devra néanmoins, faire l'objet d'une actualisation avant le 15/12 en déposant les documents cités dans le premier paragraphe.

Les liens sont disponibles pour téléchargement sur Convergence dans les éditos associés aux scénarios IA.83.01 et IAM.80.01

Les dispositifs SONS DPI et PFI sont indépendants et décrits distinctement dans les documents suivants : Appel à Financement (DPI et PFI), DSR (DPI et PFI) et REM (DPI et PFI). Par conséquent, les financements associés à la mise en œuvre des solutions DPI et PFI sont indépendants. Ainsi si un éditeur met en place une PFI pour laquelle l'établissement valide son fonctionnement conformément aux attendus décrit dans la VA (vérification d'aptitude), l'éditeur percevra le financement au bénéfice de l'établissement que ce dernier ait bénéficié ou non d'un DPI Vague 2. 

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

Cette exigence est présente dans le REM DPI avec le "profil CIBA". Il convient de bien sélectionner ce profil au niveau de votre formulaire d'éligibilité pour la voir dans l'espace de preuves.

L’exigence SSI/IE.31 porte sur la vérification des coordonnées utilisées pour l'authentification lors de la création du compte ou la modification d'une coordonnée, que ce soit par un administrateur pour un tiers ou par l'utilisateur de son propre chef.
A noter que dans le cas où un administrateur crée ou modifie un compte pour un tiers, cette mécanique de vérification des coordonnées mail et téléphone pour cet utilisateur tiers permet aussi de s’assurer que la personne concernée est consentante et qu'il n'y a pas eu d'erreur dans la saisie des coordonnées, ce qui est d'autant plus probable dans ce cas.