FAQ Entreprise du numérique en santé

• 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. 

Les exigences MS.AHI/SISIAO.09 et MS.AHI/SISIAO.12 précisent les règles de gestion et d’échange des données d’identité entre le SI SIAO et le DUI.

Les principales évolutions concernent :

• la récupération des données d’une PERSONNE via le flux GET PERSONNE et leur restitution dans le DUI ;
• les correspondances de champs lors de la première intégration ;
• les règles applicables lors de la mise à jour d’une PERSONNE déjà connue ;
• l’attribution automatique de l’attribut « identité douteuse » ;
• les correspondances lors de la transmission des données du DUI vers le SI SIAO via PUT PERSONNE ;
• le versionnement des objets.

Quelles correspondances appliquer lors de la première intégration ?

Lorsqu’une PERSONNE est intégrée pour la première fois depuis le SI SIAO :

• Nom SI SIAO → Nom de naissance DUI
• Nom d’usage SI SIAO → Nom utilisé DUI
• Prénom SI SIAO → Prénom utilisé DUI
• Premier prénom de naissance DUI → « INCONNU »

Quelles règles appliquer lors d’une mise à jour ?

Pour une PERSONNE déjà connue du DUI, lors d’une mise à jour reçue du SI SIAO :

• Prénom SI SIAO → Prénom utilisé DUI uniquement

L’attribut « identité douteuse » doit-il être appliqué ?

Oui. Toute identité créée à la suite d’un transfert de données d’identité depuis le SI SIAO doit se voir attribuer automatiquement, par défaut, l’attribut « identité douteuse ».

Quelles données transmettre du DUI vers le SI SIAO ?
Lorsqu’un utilisateur modifie et valide les informations d’une PERSONNE, le DUI doit transmettre automatiquement les données via le flux PUT PERSONNE :

• Nom de naissance DUI → Nom SI SIAO
• Nom utilisé DUI → Nom d’usage SI SIAO
• Prénom utilisé DUI → Prénom d’usage SI SIAO

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.

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).