Sur le premier point : la requête TD-03.1 effectuée à partir de la date de dernière consultation remonte bien toutes les modifications survenues entre les deux requêtes, y compris celles portant sur des documents antérieurs à la première requête. Autrement dit, si un document plus ancien a été modifié ou supprimé après la dernière consultation, cette modification sera incluse. Ce qui détermine les résultats est la date de survenance du changement, et non la date du document lui-même.  
Sur le second point : lorsque le résultat de la première requête TD-03.1 indique zéro nouveau document, l'exigence SC.DMP/UX.46 est satisfaite en affichant ce résultat (« 0 nouveau document »). Si le praticien souhaite ensuite naviguer dans l'ensemble des documents du DMP (vue complète, avec filtres), une nouvelle transaction sera alors nécessaire. Ce second appel est donc bien justifié fonctionnellement, et est conforme aux recommandations du guide d'optimisation des transactions DMP publié par l'ANS (https://esante.gouv.fr/sites/default/files/media/document/Guide_optimisation_dmp.pdf).

Oui, la mention « annule et remplace » doit apparaître dans le corps du PDF, en toutes lettres, de sorte que le professionnel de santé destinataire du message MSS puisse identifier immédiatement que ce nouveau document remplace une version antérieure.

Cette exigence a été introduite pour corriger un dysfonctionnement fréquemment constaté sur le terrain : dans 10 à 15 % des cas de non-alimentation du DMP, la cause identifiée est que la carte CPS du médecin est physiquement détenue par la secrétaire. Cette pratique, bien que contraire aux principes d'identification, est très répandue.  L'exigence vise à permettre qu'un document validé par le médecin sur son propre poste puisse être transmis au DMP via le poste où se trouve la CPS (celui de la secrétaire), sans que cela nécessite une action supplémentaire de la secrétaire. Du point de vue de la cybersécurité, les experts ont validé cette approche en considérant que l'ordre d'envoi part bien du poste du médecin, et que c'est uniquement ce signal qui déclenche l'envoi depuis le poste où est insérée la CPS.  La prise en main à distance de la CPS (contrôle à distance de la carte depuis un autre poste) est en revanche explicitement interdite car elle constitue une porte ouverte aux risques cyber.  Il est reconnu que cette exigence répond à une situation de dysfonctionnement de fond, et que l'objectif à terme est que chaque professionnel dispose de ses propres moyens d'identification. En attendant, l'interprétation la plus appropriée de cette exigence est celle du médecin travaillant sur plusieurs postes, dont l'un contient sa CPS : l'envoi automatique se déclenche depuis le poste où la CPS est présente.  Il est également précisé que cette fonctionnalité est strictement limitée au dépôt de documents au DMP, et ne couvre pas la consultation du DMP ni d'autres usages de la CPS.

Oui, dans les scénarios où le compte a déjà été associé au moyen d’authentification correspondant. Le fonctionnement repose notamment sur les mécanismes d’appairage prévus dans l’écosystème PSC.

L’attendu est que Pro Santé Connect soit le mode d’authentification présenté par défaut.
Les autres modes de connexion peuvent être proposés, mais via une action supplémentaire (ex. Bouton « autres modes de connexion »).
L’objectif est de privilégier Pro Santé Connect par rapport aux mécanismes historiques d’authentification directe.

Non. Le lecteur doit être compatible, mais le logiciel doit également être capable d’exploiter correctement les données reçues.
Le logiciel doit satisfaire aux exigences du dispositif ApCV et obtenir les validations nécessaires auprès du CNDA.

L'utilisation de WebView2 en mode Evergreen est compatible avec la tolérance prévue par les EXI PSC 25 et 26 ;
Deux mesures de durcissement de l'usage de WebView2 sont recommandées dans le contexte de la cinématique PSC :

• isolation du User Data Folder dédié
• verrouillage du domaine de navigation.

Oui, dès lors que l’opération est exécutée depuis le poste où la CPS du professionnel est présente.
La solution décrite paraît conforme à l’intention de l’exigence.

Non.
Les scénarios historiques utilisant l’accès direct via CPS restent attendus en complément des scénarios Pro Santé Connect.
Cette règle s’applique notamment à :

• l’INS ;
• le DMP ;
• l’ordonnance numérique.

L’objectif de l’exigence est de permettre l’importation rapide de plusieurs documents sans devoir ouvrir individuellement chaque document avant import.
Plusieurs implémentations peuvent être acceptables :

• sélection multiple suivie d’un import global ;
• boutons d’import successifs directement accessibles depuis la liste.

L’essentiel est d’éviter un parcours du type :

1. ouvrir un document ;
2. l’importer ;
3. revenir à la liste ;
4. répéter l’opération.

L’esprit de l’exigence est donc respecté dès lors que l’utilisateur peut importer plusieurs documents sans navigation répétitive.

Les CGU doivent être accessibles avant l’utilisation du service et avant l’accès aux fonctionnalités du logiciel.
Toutefois, il a été précisé pendant la séance que :

• l’obligation porte sur l’affichage et la consultation des CGU ; il n’est pas attendu de recueillir une acceptation formelle avant l’identification de l’utilisateur ;
• l’éditeur peut conserver son propre mécanisme de validation juridique des CGU après authentification.

L’attendu est donc la mise à disposition des CGU en lecture avant l’authentification et non une validation juridiquement opposable à ce stade.

Oui, il est possible de faire le scénario avec un autre patient test.
Jeux d’essai INS mis à disposition par l’ANS : https://esante.gouv.fr/sites/default/files/media/document/ins_jeux-d-essais_v20260330.zip

Non. L'exigence impose au logiciel d'offrir la fonctionnalité d'envoi par MSSante Citoyenne (Mon espace sante), mais elle n'implique pas un envoi automatique ou systématique à chaque production de document.

L'envoi doit s'effectuer à l'initiative du professionnel de santé, sur sélection ou confirmation de sa part au moment opportun de sa prise en charge.

• Le Parcours Éditeur est destiné au fournisseur du logiciel. Il est limité au bac à sable (BAS) pour développer, tester et constituer le dossier d’homologation (Espace de Confiance Pro Santé Connect).
  La solution pourra être déployée en production via le parcours opérateur.
• Le Parcours Opérateur est destiné à l’établissement ou au prestataire exploitant une solution déjà homologuée. Il permet :
  • de s’appuyer sur l'habilitation EDC PSC de l’éditeur ;
  • de demander directement l’accès à la production ;
  • de ne pas repasser par le Bac à Sable.

Pour remplir le test d'intrusion, l'auditeur doit :

1. S'assurer que la première page du formulaire comporte le nom ainsi qu'une description succincte de l'application ;
2. Remplir l'onglet "Base Commune" et l'onglet correspondant au type d'application indiqué dans le champ "Type d'application" ;
3. Compléter l'ensemble des règles de sécurité ;
4. Si une règle de sécurité est notée comme "N/A" ou "NON", ajouter une justification dans la section des commentaires (attention Il est également important d'évaluer les risques de ce résultat, par exemple la présence de l'id de corrélation dans l'URL lors d'un authorization code flow sur PSC via le proxy).;
5. Générer un fichier PDF à partir de la macro du test d'intrusion ou manuellement à partir du descriptif ;
6. Signer électroniquement le formulaire de test d'intrusion.