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.

Oui. 
Les exigences affichées dans Convergence sont générées automatiquement en fonction : 

• des profils fonctionnels déclarés, 
• des composants optionnels sélectionnés. 

Le filtrage est essentiel, le tri peut être simple (ex : ordre alphabétique). L’idée est d’extraire l'information (ex : nature du document) des métadonnées de l'enveloppe IHE.XDM sans avoir à ouvrir le message et permettre ainsi tri et filtre.  

Non, l’accès aux environnements CNDA est nécessaire pour réaliser les pentests.
Délai d’ouverture : 15 jours ouvrés incompressibles entre l’enregistrement au CNDA et l’ouverture des environnements de tests. Ce délai est lié aux processus de création de jeux de données et au whitelisting. L'information est communiquée via l’espace personnel éditeur. 

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, ce n’est pas une obligation. Toutefois, il est recommandé de faire appel à des sous-traitants certifiés sur le périmètre qui leur est confié. Cela facilite le respect des exigences de l'ISO 27001 relative aux fournisseurs.
 
Par ailleurs en tant qu'hébergeur, je dois être certifié sur toutes les activités concernées par mon offre y compris celles confiées à mon sous-traitant.

L’article L.1111-8 du code de la santé en public distingue trois grandes catégories de services d’hébergement de données de santé :

• l’hébergement de données de santé sur support papier dans le cadre d'un service d'archivage, qui doit être réalisé par un hébergeur agréé par l'Etat ;
• l’hébergement de données de santé sur support numérique (hors cas d’un service d’archivage électronique) qui doit être réalisé par un tiers hébergeur certifié HDS ;
• l’hébergement de données de santé sur support numérique dans le cadre d’un service d’archivage électronique, qui doit être réalisé par un tiers archiveur certifié HDS et agréé par l'Etat dans des conditions qui seront définies par décret en Conseil d’Etat pris après avis de la Commission nationale de l’informatique et des libertés et des conseils des ordres des professions de santé.

Oui : le chiffrement n'a pas d'impact sur l'obligation de certification. La nature de la donnée de santé à caractère personnel n'est pas modifiée.

La gestion d'une file d'attente d'envoi vers le DMP a deux objectifs : 

• éviter la perte de documents  
• permettre un envoi différé 

Par exemple, dans le cas d'un envoi impossible qui est stocké, ou lors d'un evoi effectué lors d’une reconnexion valide.