Questions fréquentes

Le scénario de test DMP/CONF.15.01 permet d'attester que les accès utilisateur pour la consultation de documents de santé depuis la fonction consommatrice DRIMBox sont bien tracés par cette dernière. Le déroulement des différentes étapes de test composant le scénario DMP/CONF.15.01 permet la mise en œuvre d'un tel workflow de consultation. Les éléments de preuve respectivement déposés en DMP/CONF.15.01.01 et DMP/CONF.15.01.02 doivent pouvoir être interprétés conjointement afin d'illustrer le processus de création de traces suite à une action utilisateur de consultation. 

Pour cela, les éléments suivants doivent être illustrés au sein de ces preuves de test : 

• Processus de consultation de documents de santé depuis l'interface utilisateur associée à la fonction consommatrice DRIMBox. 
• Logs logiciel ou traces d'audit correspondant aux actions de consultation effectuées par l'utilisateur. Il est à noter que le contenu de ces logs ou traces doit permettre une mise en correspondance avec les éléments démontrés au point précédent.

Il est important de relever que le prérequis associé au scénario de test DMP/CONF.15.01 qui mentionne : "intégré dans la base locale" ne s'applique pas aux solutions logicielles DRIMBox. En effet, étant donné qu'aucune exigence n'impose l'hébergement de documents de santé au sein d'une base locale, seule la consultation de documents de santé depuis le DMP doit être considérée afin de dérouler ce scénario de test pour une solution DRIMBox.

Les étapes n°1 à n°4 du scénario de test doivent être effectuées en impliquant la fonction source associée à la solution logicielle DRIMBox. Au travers de ces étapes de test, il est attendu qu'un workflow de gestion du cycle de vie d'un document KOS puisse être démontré (création + suppression). Afin de démontrer la capacité de la fonction source DRIMBox à assurer le workflow correspondant aux étapes n°1 à n°4, la ou les éléments de preuve déposés doivent illustrer les aspects suivants : 

• Déroulement de bout en bout du workflow de gestion du cycle de vie d'un document KOS, depuis l'envoi d'un message HL7v2 jusqu'à l'impact sur le DMP (ajout/suppression d'un document).
• Opérations effectuées par la fonction source associée à la solution logicielle DRIMBox. Etant donné que la fonction source DRIMBox ne dispose pas d'interface utilisateur, cet aspect de la preuve peut être attesté au travers de la mise à disposition de traces d'audit ou logs logiciels, afin de faire une mise en correspondance avec le workflow d'alimentation.

L'étape n°5 du scénario de test doit être effectuée en impliquant la fonction consommatrice associée à la solution logicielle DRIMBox. Le déroulement de cette étape de test implique une tentative d'accès (appel contextuel) à la fonction consommatrice DRIMBox pour un patient non consentant à la consultation de son DMP. La ou les preuves déposées afin d'attester du déroulement de l'étape n°5 doivent illustrer cette tentative de consultation ainsi que l'échec qui en résulte.

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 de la date 2 de votre couloir et à titre dérogatoire (date de dépôt du dossier complet de preuves de conformité), une copie d’écran de votre espace personnel CNDA montrant que le dossier est en cours de pré-examen. 

Pour le calcul de la tranche, le service de calcul ne prend pas en compte les numéros invalides. Ils sont indiqués dans le mail de résultat mais n'impactent pas le résultat.
Si la commande contient un ou plusieurs numéros AM et/ou FINESS indiqués comme "invalides" par le service de calcul, elle ne sera pas rejetée, sauf si tous les numéros FINESS et AM de la commande sont invalides conduisant à un montant plafond nul.

Un numéro est considéré comme "invalide" par le service de calcul dans les cas suivants :
- Numéro d'un établissement ou médecin créé après 2023
- Etablissement ou médecin existant en 2023 mais sans activité en 2023
- Tout numéro incorrect (par exemple format incorrect)

Non, une DRIMbox ne peut s’appuyer sur un RIS non référencé vague 2 .

L’utilisation d’un composant tiers déjà homologué par le CNDA ne dispense pas systématiquement de réaliser une demande dans le cadre de la mise en conformité de votre solution logicielle. Dans la majorité des cas, une démarche reste nécessaire, cela dépend du type de composant tiers et de son mode d’intégration.

Afin de clarifier les règles applicables, plusieurs situations doivent être distinguées :

Premier cas de figure : le composant principal de la solution logicielle PS utilise un composant additionnel non autonome

Un composant additionnel non autonome est appelé au CNDA "application EAI" dans le cas du DMP ou "moteur à IHM" masquée dans le cas de l'INSi.

Dans ce cas :

• Chaque application EAI ou chaque moteur à IHM masquée doit passer une homologation au CNDA.
• Chaque composant principal d'une solution logicielle qui intègre une application EAI / moteur à IHM masquée doit passer une homologation au CNDA.

A noter que l'homologation est complète mais plus rapide car les applications EAI/moteur à IHM masquée ont déjà validé une partie des tests à repasser.

Deuxième cas de figure : le composant principal de la solution logicielle PS utilise un composant additionnel autonome

Un composant additionnel autonome est une application (tierce) à part entière avec des IHM autonomes et visibles. Au CNDA, il s'agit d'une application autonome. Le composant principal d'une solution logicielle PS s'interface avec l'application autonome (tierce) via un appel contextuel. L'opérateur de la solution logicielle PS peut opérer une instance dédiée de la solution autonome (tierce) ou peut utiliser une instance mutualisée opérée par l'éditeur de la solution autonome tierce.

Dans ce cas :

• Chacune de ces applications autonomes tierces doit passer une homologation au CNDA.
• Dans le cas du composant principal de la solution logicielle PS :
  • Si l'opérateur du composant principal de la solution logicielle PS opère aussi une instance dédiée de l'application autonome (tierce) alors le composant principal de la solution logicielle PS doit passer une homologation d'interfaçage avec l'application autonome (tierce) dans le cadre de la conformité DMP.
  • Pour l’INSi et l’Ordonnance Numérique les éditeurs intégrant des composants tierces (moteur coté CNDA) doivent déposer une demande de conformité en mode apparent.
    • Dans le cas où le logiciel intègre un composant déjà autorisé « INSi » et/ou « Ordonnance Numérique » en mode IHM apparente, l’éditeur n’a pas à constituer de dossier de preuves de tests, il peut passer directement à l’étape d’examen de conformité indiquée à l’Article 5.3 : Etape d’examen.
      Dans le cas où le logiciel intègre un composant déjà autorisé « INSi » en mode IHM masquée (ou semi masquée), l’éditeur doit réaliser toute les phases de la procédure de conformité.

Effectivement cette étape du scénario ne sera pas prise en compte dans l’étude des preuves.

1. Quel est le changement principal ?

Lors de la publication des REM RIS et DB, MDV et DCC, le Guide d'implémentation (GI) 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].

Le CIBA est prévu dans la vague 2 du Ségur en tant que profil optionnel. En cas de client lourd, l'éditeur doit proposer les deux solutions (code flow et CIBA) en lien avec les exigences SC.PSC.01 et SC.PSC.13. Le profil est obligatoire lorsque l’éditeur a choisi d’implémenter dans sa solution logicielle l’authentification ProSanté Connect par le protocole CIBA (§3.1 du DSR DPI).

Cette phase a pour finalité d'échanger sur le rapport du test d'intrusion, notamment si des manquements aux règles de sécurité sont détectées. L'auditeur devra communiquer les résultats du test d'intrusion à l'éditeur en clarifiant les points suivants :

• Les détails techniques des vulnérabilités identifiées ;
• L'impact potentiel des non-conformités aux règles de sécurité et le niveau de risque associé ;
• Les solutions concrètes permettant de corriger les potentielles failles ;
• La définition des prochaines étapes (définition d’une date permettant d’évaluer de nouveau les vulnérabilités recensées).