FAQ Entreprise du numérique en santé

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.

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. 

Non. Le certificat de conformité HDS de l’hébergeur constitue un élément de preuve recevable pour les populations relevant du périmètre de l’hébergement (par exemple : exploitation, administration ou maintenance de l’infrastructure lorsqu’elles sont couvertes par le périmètre certifié).

Toutefois, ce certificat ne permet pas à lui seul de démontrer que les autres populations intervenant sur le système d’information de l’éditeur (par exemple : conception, développement, intégration, support fonctionnel, etc.) bénéficient également des actions de sensibilisation exigées.

L’éditeur doit obligatoirement compléter cette preuve par une documentation décrivant son dispositif de sensibilisation (PSSI ou autre document équivalent) pour les populations non couvertes par le certificat HDS.

Il doit donc fournir également une PSSI pour une partie du périmètre ce qui justifie de compléter le template correspondant pour y pointer les éléments attendus.
 

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.