Sur le premier point : les statistiques sont demandées à deux niveaux distincts – à l'échelle du professionnel de santé (identifié par son numéro RPPS) et à l'échelle de la structure (identifiée par son numéro FINESS). Pour les cabinets de groupe avec plusieurs RPPS, il n'est pas spécifiquement demandé d'agréger les données, mais cette fonctionnalité est bienvenue si elle est implémentée.  
Sur le second point : aucune spécification n'a été posée sur ce point. Par logique fonctionnelle, chaque praticien devrait visualiser ses propres statistiques. L'accès aux statistiques d'un autre praticien du cabinet est laissé à l'appréciation de l'éditeur.  Il est également précisé que des taux supérieurs à 100 % sont possibles et acceptables : par exemple, si un médecin envoie plusieurs documents au DMP pour une même consultation (plusieurs ordonnances, etc.), le taux de documents transmis par consultation peut dépasser 100 %. Ce cas ne constitue pas une anomalie.

Oui, ce scénario est tout à fait acceptable. L'exigence ne mentionne pas spécifiquement une secrétaire : elle porte sur le cas où la CPS est insérée dans un poste différent de celui sur lequel le professionnel travaille. Un médecin connecté sur deux postes distincts (l'un sans CPS, l'autre avec sa CPS) correspond parfaitement à ce scénario et constitue une preuve valide.

Un professionnel peut bénéficier d’un financement « Vague 1 + Vague 2 » dès lors :

• qu’il n’a pas déjà bénéficié du financement de la mise à jour Vague 1, quel que soit l’éditeur ;
• qu’il atteste ne pas avoir payé lui-même la mise à jour vague 1.

Un bon de commande Vague 1+vague 2 signé par un professionnel ne répondant aux conditions précisées ci-dessus sera refusé par l’ASP, un nouveau bon de commande uniquement  vague 2 sera à faire signé.

Oui, il faut en faire la demande via la messagerie Convergence
Un éditeur n’est pas tenu de maintenir un profil pour lequel il ne souhaite finalement pas être référencé.
Cette décision peut être prise jusqu’au référencement final.
Rappel de l’AF :

• Si le Client est une Structure d’exercice coordonné, alors la Solution logicielle doit disposer du Profil « Structures d’exercice coordonné » et du Profil « Médecin traitant et Suivi de l’enfant ».
• Si le Client est un médecin ayant une activité de médecin traitant déclarée (adultes et/ou enfants), d’au moins 10 patients auprès de l’Assurance Maladie, alors la Solution logicielle doit disposer du Profil « Médecin traitant et Suivi de l’enfant ».

Cette distinction n’est plus présente dans l’exigence MDV-07 de la vague 2.
Deux tableaux de bord distincts existent désormais :

• MDV-07 : indicateurs relatifs aux envois vers le DMP et MSSanté ;
• INS-02 : indicateurs relatifs aux statuts de qualification des INS de la patientèle.

La confusion provient probablement d’exigences historiques de la vague 1 qui autorisaient encore certains usages avec des INS récupérées ou non qualifiées.

L’exigence DMP UX 27 stipule que le système doit proposer au professionnel de santé une fonction de recherche et/ou de filtrage basée sur les métadonnées XDS des documents issus du DMP.

Afin d'éclairer la mise en œuvre de cette exigence, voici des précisions à titre indicatif et illustratif sur le niveau d'exigence réglementaire et les recommandations UX destinées à optimiser l'usage au quotidien par le professionnel de santé.

1. Cadre réglementaire et portée de l'exigence
   • Sur le plan réglementaire : Le texte de l'exigence SC.DMP/UX.27 n'impose pas de liste exhaustive de métadonnées obligatoires à filtrer, ni de modalités techniques strictes d'implémentation du filtrage (par exemple, type d'interface ou combinaison exacte de filtres).
   • Conséquence pour la conformité : Les éléments présentés ci-dessous ne constituent pas des exigences strictes de vérification, mais des recommandations d'ergonomie et de bonnes pratiques.
2. Recommandations fonctionnelles (À titre indicatif et d'amélioration UX)
   Pour offrir une valeur ajoutée maximale aux professionnels de santé et leur permettre de retrouver rapidement les informations pertinentes au sein du DMP du patient, il est fortement recommandé de proposer :
   • Des fonctionnalités combinées :
     • Un module de filtrage ciblé par critère.
     • Une possibilité de tri (ex. tri chronologique inverse par défaut).
     • Une recherche par mot-clé au sein des métadonnées affichées.
3. Exemples de critères et métadonnées recommandés pour le filtrage / tri
   Afin d'optimiser la lisibilité de la liste des documents, il est pertinent d'offrir des capacités de recherche ou de filtre sur les champs de métadonnées suivants :
   • La date du document / de l'acte :
     • Filtrage par période (ex. derniers 6 mois, année en cours) ou intervalle de dates.
   • La nature du document médical :
     • Par intitulé du type-code : Compte-rendu d'imagerie, Compte-rendu de Biologie, Lettre de liaison, Prescription de produits de santé, Synthèse Médical etc.
     • Par titre précis : Échographie abdominale, Consultation de cardiologie, etc.
   • L'auteur du document :
     • Par nom de l'auteur : Recherche textuelle ou sélection de l'émetteur.
     • Par profession / spécialité : Filtrage par Médecin généraliste, Radiologue, Pharmacien, Orthophoniste etc.
     • Par établissement / structure : Filtrage par centre hospitalier, cabinet, laboratoire, etc.
   • Le niveau de confidentialité :
     • Le filtrage sur l’invisibilité des documents fait l’objet d’une vérification obligatoire de cette exigence.

Conclusion

Bien que la liberté d'implémentation soit laissée à l'éditeur quant aux métadonnées XDS choisies pour le filtrage, l'intégration de ces critères clés (Date, Type/Titre, Auteur/Profession/Établissement) constitue un levier majeur d'ergonomie et d'efficacité pour le gain de temps médical.
 

Les preuves demandées sont majoritairement de la documentation spécifique à chaque exigence, une attestation sur l'honneur, ainsi que le formulaire du test d'intrusion en particulier pour l'exigence SC.SSI/GEN.18. Elles permettent de vérifier que les processus en question sont bien mis en œuvre et conformes à une démarche SSI.

La phase de rapport consiste à la fourniture par l'auditeur du rapport du test d’intrusion en remplissant et en signant électroniquement le formulaire correspondant. Ce document regroupe l’ensemble des résultats du test d’intrusion ainsi que le référencement de l’application.  

La phase de test implique la réalisation de tests en boîte grise, où l'auditeur dispose d'informations préalables, ainsi que la réalisation de compléments en boîte noire, où l'auditeur agit sans informations préalables dans le but de repérer les failles et d'obtenir une évaluation exhaustive de la sécurité de l'application. Cette phase dure en moyenne 3 à 4 jours.

La clause de revoyure permet d'avoir un engagement de la part de l'auditeur pour tester de nouveau les exigences non validées lors du test d'intrusion et d'effectuer un contre-audit afin de vérifier si les mesures de sécurité nécessaires ont été mises en œuvre.

La phase de cadrage est la phase qui précède les tests techniques. Elle est organisée par l'éditeur et consiste à communiquer les détails de l'audit au prestataire choisi pour effectuer l'audit, tels que les dates, l'environnement, les contacts, la documentation, etc.

Selon les différents pilotes réalisés par l'ANS et les échanges avec les auditeurs PASSI, le coût du test d'intrusion varie en moyenne entre 5 000 et 10 000 euros (uniquement pour le périmètre du Ségur) et dure environ une semaine ouvrée.

Un webinaire a été organisé par l'ANSSI et l'ANS à l'attention des auditeurs PASSI, dans le but de clarifier leurs responsabilités et leurs périmètres d'intervention à chaque phase du processus de réalisation du test d'intrusion : le cadrage, la réalisation du test d'intrusion et la phase de rapport.

Le replay du webinaire peut être retrouvé ici : https://esante.gouv.fr/webinaires/segur-vague-2-destination-des-prestataires-daudit-passi

Il est demandé qu’une fréquence de sauvegarde des données soit prévue dans la documentation, mais aucune fréquence n’est définie pour cette exigence.  
Il convient à chaque éditeur de définir ce qui est acceptable au regard du contexte d’utilisation de sa solution.   
Selon l’ANSSI, une stratégie de sauvegarde doit notamment tenir compte de la perte de données maximale admissible (PDMA) et de la durée maximale d’interruption admissible (DMIA) définies pour l’ensemble des valeurs métier du SI de l’entité (applications, données). 

Si l’utilisation des macros était bloquée pour des raisons de sécurité, nous recommandons à l’auditeur de se mettre dans un environnement sécurisé afin de les exécuter (VM, docker ou station isolée du SI).