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

Oui. Les ordres auront accès aux données du RPPS via une extraction de l'Annuaire Santé afin d'identifier les PADHUE ayant une activité ouverte dans un établissement.
Cet accès leur permettra d'assurer un premier niveau de suivi et de contrôle, notamment pour les professionnels ayant obtenu le plein exercice.

Non. L'acronyme « PADHUE (Praticiens à Diplôme Hors Union Européenne) – Médecin / Pharmacien / Sage-Femme / Chirurgien-Dentiste » indique qu'il s'agit d'un professionnel à diplôme hors Union Européenne, en cours de procédure d'autorisation d'exercice.
Ce libellé ne doit pas être confondu avec les titulaires d'une autorisation temporaire d'exercice (ATE), qui sont des professionnels pleinement qualifiés.

L'affichage de ce libellé dans le Portail RPPS+ et dans l'Annuaire Santé est volontairement différencié pour éviter toute confusion.

Non, pas à ce stade. L'accès au DMP est dépendant d'une matrice de droits en cours de révision avec la CNAM.
Cette question est suivie séparément et fera l'objet d'une communication dédiée le moment venu.

Aucune disposition législative ou réglementaire du Code de la santé publique ne permet aux PADHUE en cours de procédure (AEP, EVC, PCC) de s'inscrire à un ordre (à l'exception de la procédure applicable en outre-mer).
Les PADHUE ne figurent pas dans la liste des professions que les ordres peuvent enregistrer au RPPS (cf. Arrêté RPPS du 23 septembre 2022).
L'enregistrement par les employeurs est la seule option juridiquement possible à court terme. Un modèle hybride nécessiterait des modifications législatives et réglementaires, incompatibles avec l'urgence de la situation terrain.

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. 

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.