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

En prérequis de ce scénario de test, il est demandé à ce que cinq documents soient publiés sur le DMP ciblé. Parmi ces documents, les contraintes implicites suivantes doivent s'appliquer :

• Un des cinq documents doit être visible au patient ou aux responsables légaux du patient.
• Un des cinq documents doit être non masqué aux professionnels de santé. 

L'étape n°1 du scénario de test consiste en une indication relative aux preuves de test à fournir. En effet, l'ensemble des éléments de preuve déposés doivent faire figurer une mention permettant d'identifier l'utilisateur. Cette information pourra être utilisée dans le cadre d'une analyse croisée des différents éléments de preuve fournis. 

Les étapes n°2 à n°5 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é (remplacement + suppression + masquage + invisibilisation). Afin de démontrer la capacité de la fonction source DRIMBox à assurer le workflow correspondant aux étapes n°2 à n°5, le 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 (remplacement/suppression/masquage/invisibilisation 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. 

L'étape n°6 du scénario de test implique l'utilisation de la fonction consommatrice DRIMBox afin de permettre à un utilisateur de visualiser un document préalablement publié sur le DMP. Les preuves déposées afin d'attester du déroulement de l'étape n°6 doivent illustrer à la fois le processus de consultation d'un document de santé depuis l'interface de la fonction consommatrice DRIMBox ainsi que les traces ou logs attestant des actions de consultation effectuées par l'utilisateur. 

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. 

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.

Une visualisation correcte du document PDF attendu suffit pour être valide. Le téléchargement du PDF est une implémentation possible, mais pas nécessaire.

Non, la connexion PSC n'est pas obligatoirement automatique après l'insertion de la CPS. La connexion suit le processus standard sans aucun automatisme obligatoire.

Oui, les deux cas sont obligatoires et doivent être logiquement implémentés. Le système doit être en mesure de déclencher un appel au téléservice INSi :

• lors de l’insertion de la carte Vitale ; 
• lors de l’ouverture du dossier à partir des traits d’identité.

La carte Vitale est à privilégier lorsqu’elle est disponible, mais les deux modalités doivent impérativement être implémentées.