Oui, il est possible de faire évoluer le numéro de version du logiciel au fur et à mesure de l’obtention des homologations et agréments du CNDA, notamment si la version initialement déclarée évolue à l’issue de ces démarches.
Il est toutefois fortement recommandé de déposer les preuves de conformité sur la version candidate au référencement Ségur.
En cas de modification de la version du logiciel, l’éditeur doit s’assurer, avant le passage en collège de référencement, que la nouvelle version répond à l’ensemble des exigences du référentiel Ségur applicable.
L’éditeur doit également demander l’accès au formulaire administratif permettant de déclarer cette modification de version.
Afin de garantir la conformité de la nouvelle version, une attestation devra être déposée dans le dossier candidat.

Le principe d’équivalence des preuves entre les différents dispositifs du Ségur est détaillé dans la Notice d’équivalence des preuves, notamment aux pages 10 à 17.
L’application de cette équivalence dépend du cas de figure rencontré, notamment de l’identité de la solution logicielle candidate, de son nom commercial et des composants qui la constituent.
Les principaux cas de figure sont les suivants :
La solution logicielle candidate est identique à la solution logicielle déjà référencée (même composant principal, mêmes composants additionnels le cas échéant et même composant Proxy e-santé), sous le même nom commercial.
La solution logicielle candidate est identique à la solution logicielle déjà référencée (mêmes composants), mais est commercialisée sous un ou plusieurs noms commerciaux différents.
Le composant principal est identique à celui de la solution logicielle déjà référencée, mais un ou plusieurs composants additionnels ou le composant Proxy e-santé sont différents, que la solution soit ou non commercialisée sous le même nom.
Ainsi, l’équivalence des preuves ne s’applique pas automatiquement dans tous les cas. Les modalités à appliquer dépendent de la situation de la solution candidate.
La Notice d’équivalence des preuves est disponible à l’adresse suivante : https://esante.gouv.fr/sites/default/files/media/document/segur-va2-notice-equivalence-des-preuves.pdf

La liste des éditeurs et opérateurs proposant des proxys habilités Pro Santé Connect est disponible sur le site de l’Agence du Numérique en Santé (ANS) : https://esante.gouv.fr/ens/offre/pro-sante-connect/liste-des-proxys-habilites-editeurs-et-operateurs-sur-le-guichet-edc-psc

Oui. La validation des prérequis de maturité technique relève du périmètre de l’Espace De Confiance Pro Santé Connect côté ANS.
Toutefois, le dépôt et l’instruction des dossiers ne peuvent débuter qu’à compter de l’ouverture officielle du guichet, conformément au calendrier défini par l’ANS. Il faut donc rattacher votre demande à un couloir Ségur ouvert.
Ainsi, l’ouverture du guichet constitue un prérequis au démarrage officiel de la démarche et peut conditionner le calendrier de validation du PMT et la poursuite des étapes suivantes, notamment la présentation au CNDA.

Lorsqu’une demande DataPass est modifiée, l’habilitation associée est également modifiée. Le numéro de la demande DataPass reste inchangé. En revanche, le numéro d’habilitation est modifié, puisqu’une nouvelle habilitation est générée à la suite de la modification de la demande.

Les parcours « Éditeur » et « Opérateur » répondent à des objectifs complémentaires et nécessitent chacun des éléments de production spécifiques.
Le parcours Éditeur vise principalement à démontrer la conformité fonctionnelle et technique de la solution aux exigences de Pro Santé Connect.
Le parcours Opérateur porte davantage sur l’exploitation de la solution en production, notamment sur la gestion des configurations, ainsi que sur la gestion des incidents et des alertes.
Les références obtenues dans le cadre du parcours Éditeur ne sont donc pas directement réutilisables dans une candidature Opérateur. Chaque candidature sur le guichet « Opérateur » nécessite ses propres éléments de production. En particulier, un Client_ID de production doit être demandé pour chaque composant concerné (Proxy, logiciel utilisateur, etc.).
En revanche, la demande DataPass reste commune aux deux parcours : une seule demande DataPass est nécessaire par service à raccorder.
Les preuves attendues sont détaillées dans le référentiel EDC PSC ainsi que dans les guides dédiés aux guichets « Éditeur » et « Opérateur » EDC PSC.

Oui, les prérequis de maturité technique du proxy et d'un logiciel qui l'utilise peuvent être déposés et validés de manière indépendante.
Des preuves relatives au prérequis de maturité technique du Proxy sont bien prévues sur le guichet EDC PSC. En revanche, le CNDA ne réalise pas d’homologation du Proxy seul : l’homologation porte sur le logiciel utilisateur, y compris lorsque celui-ci est adossé à un Proxy
Il est donc nécessaire d’attendre que votre logiciel utilisateur obtienne le prérequis de maturité technique avant de réaliser les tests auprès du CNDA avec le couple logiciel utilisateur / Proxy.
Par ailleurs, l’autorisation d’accès aux environnements de test ne comporte pas de date de fin de validité.

Concernant le Proxy, aucune homologation n’est à réaliser au CNDA sur le Proxy lui-même. L’homologation porte uniquement sur le logiciel utilisateur, y compris lorsque celui-ci est adossé à un Proxy.
Par ailleurs, l’autorisation d’accès aux environnements de test ne comporte pas de date de fin de validité. Elle restera donc valide, notamment au regard des délais de traitement actuels.

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.