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

À ce jour, il n’est pas possible d’utiliser en production une DRIMbox qui n’est pas financée dans le cadre de la Vague 2 du Ségur du numérique en santé.

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. 

L’identification du patient doit comporter l’ensemble des éléments constitutifs de l’identité INS, à savoir :

• le nom de naissance ;
• les prénoms de naissance ;
• la date de naissance ;
• le sexe ;
• le lieu de naissance – code INSEE ;
• le matricule INS, complété par son OID.

Cet attendu est explicitement précisé par l’exigence DB.SO.105, qui mentionne l’utilisation des informations contenues dans l’entête du Compte-Rendu pour l’identification du patient, à savoir « INS accompagné de ses traits stricts ».

Dans le cadre de la trace d’audit définie par DB.SO.43, ces informations doivent être véhiculées au niveau du « ParticipantObjectID » du bloc « C.Patient AuditMessage/ParticipantObjectIdentification ».

Aucun format de représentation particulier n’est imposé par la spécification. L’utilisation d’un format tel que HL7 CX est possible mais non obligatoire ; une représentation libre est acceptable dès lors que l’ensemble des éléments constitutifs de l’identité INS est effectivement véhiculé et exploitable.

La formulation actuelle de DB.SO.43, qui mentionne uniquement « Identifiant INS du patient », peut prêter à confusion. Cet attendu doit être compris en cohérence avec DB.SO.105 et avec la définition des traits stricts composant l’INS.

Les spécifications DRIMbox prévoient, dans le cadre du profil consultation, les deux transactions suivantes :

• TD3.3b – Modification de la visibilité des documents : cette transaction doit être gérée par la DRIMbox consommatrice. Il s’agit donc d’une fonctionnalité attendue en consultation.
• TD3.3c – Suppression des documents : cette transaction est également prévue dans les spécifications DRIMbox. Toutefois, une tolérance est actuellement accordée : la suppression peut être gérée uniquement par réception depuis la DRIMbox source (profil alimentation) d'un compte-rendu dans le RIS.

Ainsi, la gestion de la TD3.3b est obligatoire en consultation, tandis que la non-gestion de la TD3.3c en consultation est actuellement acceptée, dès lors que la suppression est prise en charge via la réception d'un flux HL7 sur la DRIMbox source.

Cette tolérance concerne uniquement la TD3.3c et ne s’applique pas à la TD3.3b.

Dans le cadre de la prestation principale liée au déploiement d’une DRIMbox, il est demandé de réaliser un audit ciblé du plateau d’imagerie existant ainsi que de l’architecture informatique associée aux composants nécessaires au fonctionnement de la DRIMbox. Cet audit doit donner lieu à la production d’un rapport formel.

Cet audit n’a pas vocation à constituer un audit global de l’ensemble du système d’information de l’établissement. Il doit permettre d’identifier les éléments techniques nécessaires à la préparation du SI au déploiement de la DRIMbox, notamment au regard des solutions d’imagerie et de leurs interfaces, afin de s’assurer que l’environnement est compatible et sécurisé pour son déploiement.

Il appartient aux prestataires de s’appuyer sur leurs propres abaques et méthodologies d’audit, ainsi que sur les spécifications et guides disponibles sur le site de l’ANS, afin de proposer un audit adapté au contexte du site concerné.

À ce jour, aucun modèle ou exemple de rapport d’audit n’est imposé. Le rapport produit doit néanmoins formaliser les constats réalisés, les éventuels écarts ou points d’attention identifiés ainsi que les éléments nécessaires à la préparation du déploiement de la DRIMbox.

Oui. L'exigence SC.SSI/IE.38.01 prévoit que « le système DOIT permettre au professionnel de fermer sa session ». Dès lors qu'un professionnel de santé peut accéder à la solution via plusieurs interfaces distinctes nécessitant une authentification, cette exigence doit être satisfaite sur chacune de ces interfaces.

Ainsi, toute interface authentifiée donnant accès à la solution doit permettre au professionnel de santé de se déconnecter et conduire à la fermeture effective de sa session.

Bonne pratique sécurité

Cette exigence vise explicitement les accès des professionnels de santé. Elle ne s'applique donc pas formellement aux interfaces destinées aux patients.

Toutefois, lorsque la solution propose également des interfaces accessibles aux patients après authentification, il est recommandé d'appliquer le même principe de sécurité en permettant au patient de fermer sa session et en garantissant la fermeture effective de celle-ci. Cette approche constitue une bonne pratique de sécurité visant à limiter les risques d'accès non autorisés, notamment en cas d'utilisation de postes ou d'équipements partagés.

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.