La première étape consiste à passer par le guichet Éditeur de l’EDC PSC dans Convergence pour chacun des logiciels utilisateurs (composant principal) et pour le Proxy e‑Santé. Cette étape correspond au référencement Ségur de la solution logicielle. 
Une fois ces habilitations obtenues, l’éditeur doit également passer par le guichet Opérateur pour demander l’habilitation “Opérateur de logiciel utilisateur” pour les composants principaux et l’habilitation “Opérateur de Proxy e‑Santé” pour le Proxy.
Ces démarches étant nécessaires pour l'installation en production de la solution logicielle. 

Cf. Section "Identification électronique & Pro Santé Connect (PSC)" du DSR des différents couloirs. 

N.B. Un schéma récapitulatif du ou des guichet(s) qui vous concerne(nt) selon votre situation est accessible via ce lien. 

Pour obtenir vos homologations/certifications sur le guichet CNDA, plusieurs étapes sont à prendre en compte.

1. Contractualisation avec le CNDA

Dans un premier temps, vous devez vous rapprocher du CNDA afin d’engager votre démarche de labellisation. Cette étape vous permettra notamment d’obtenir le NIL et le NIE de votre solution logicielle, qui devront être renseignés dans votre candidature Ségur au sein du dossier administratif, à la date du Jalon 1 de votre couloir.

2. Homologation/certification sur la base des référentiels en vigueur

Les homologations et certifications sont réalisées sur la base des dernières versions des référentiels applicables au CNDA, notamment les guides d’intégration et d’implémentation du téléservice concerné.

Vous pouvez donc engager votre parcours de certification/homologation auprès du CNDA sur la base des guides actuellement en vigueur, notamment en débutant par le parcours d'authentification par cartes.

3. Prérequis pour l’homologation sur les API Pro Santé Connect du CNDA

Si vous souhaitez également être homologué/certifié sur les API Pro Santé Connect du CNDA, vous devez au préalable satisfaire aux prérequis de maturité technique applicables à votre LPS et à votre Proxy sur le guichet éditeur de l'EDC PSC.

La validation de ces prérequis vous permettra notamment d’obtenir les attestations d’accès aux environnements de test du CNDA, nécessaires à la poursuite de votre parcours.

Lorsque l’éditeur développe et intègre son propre Proxy, une seule habilitation est délivrée pour le couple LPS + Proxy.

À l’inverse, lorsque l’éditeur utilise un Proxy tiers, deux attestations d’accès distinctes doivent être délivrées : une pour le LPS et une pour le Proxy.

4. Extension du périmètre de l’homologation

Si vous avez déjà engagé votre parcours cartes auprès du CNDA, vous pouvez demander une extension du périmètre de votre parcours afin d’intégrer les tests correspondant aux API Pro Santé Connect du CNDA.

Il est toutefois fortement recommandé de mener les deux guichets en parallèle, en poursuivant le parcours Cartes auprès du CNDA, afin d’engager au plus tôt les démarches d’homologation/certification, tout en déposant auprès de l’EDC PSC les preuves relatives au chapitre « Prérequis de maturité technique ». La validation de ces prérequis permettra d’obtenir l’autorisation d’accès aux environnements de test du CNDA et de poursuivre les travaux d’intégration. Cela permettra ainsi de préparer au plus tôt la demande d’extension du périmètre d’homologation/certification aux API Pro Santé Connect du CNDA, une fois les prérequis nécessaires satisfaits.

N.B. Un schéma récapitulatif des étapes à respecter est accessible via ce lien. 

Le fichier des structures éligibles a été établi à partir de la situation à fin 2023. Il recense les structures à jour de leur accord conventionnel interprofessionnel (pour les MSP) ou de leur accord national (pour les CDS), et ayant effectué leur déclaration d'effectifs auprès de l'Assurance maladie. Ce fichier ne devrait pas être réactualisé. Les structures créées après fin 2023 ne sont donc pas éligibles au dispositif. Les causes possibles d'absence de ces structures dans le fichier de référence peuvent être : une déclaration d'effectifs non réalisée, un accord conventionnel non signé, ou encore une erreur dans la collecte des données.  Pour les structures créées après fin 2023 et non éligibles dans le cadre du dispositif collectif (MSP/CDS), des bons de commande individuels au niveau du médecin peuvent être envisagés. Cette option ne s'applique cependant pas aux centres de santé.

Oui, l'ensemble des types de documents listés dans le profil « Structure d'exercice coordonné » est requis, car ce profil a été défini de façon standardisée pour couvrir l'ensemble des structures d'exercice coordonné. Il s'agit d'exigences de niveau CDA R1 (format minimal), ce qui signifie qu'aucune spécification particulière n'est imposée sur le contenu du document : un document avec un titre suffit. Ainsi, même si une carte d'implant ou un bilan bucco-dentaire n'est pas une production habituelle de la structure concernée, il doit être techniquement possible de produire un tel document depuis le logiciel, même avec un contenu minimal.

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.