La convention de référencement Ségur stipule que l’éditeur doit pouvoir commercialiser le logiciel référencé au plus tard dans les 2 mois à compter de l’entrée en vigueur de la Convention. La date d’entrée en vigueur de la convention est la date de décision du référencement.

Les logiciels pouvant candidater au programme Ségur doivent répondre aux fonctionnalités décrites dans les DSR (Dossier de Spécifications de Référencements). Toutefois le DSR DPI ne s'adresse pas aux dossiers de spécialité.

Les solutions référencées Ségur Vague 1 doivent couvrir les aspects suivants, entre autres :

• Génération et visualisation du CR-Bio en CDA R2 N3 auto-présentable ainsi qu’en PDF/A-1 et CDA R2 N1 conformément au CI-SIS, avec les informations structurées (INS, analyses en LOINC, commentaires, etc.), ainsi que les analyses éventuellement sous traitées, soit comme un PDF encapsulé à partir du CR Bio reçu par MSSANTÉ du sous-traitant, soit, en respect de la cible, avec une lecture du CDA R2 N3 et/ou du flux HL7 v2 IHE ILW généré par le sous-traitant ;
• Envoi systématique et automatisé au DMP, éventuellement via un connecteur partenaire, au format CDA R2 N3 et PDF en CDA R2 N1 (ce dernier n’étant prévu que pour une période transitoire de 2 ans, avec, au 1er janvier 2024, l’envoi au DMP uniquement du CDA R2 N3), selon le guide d’intégration DMP compatibilité (v2.4.0 ou supérieure), avec possibilité de modification / retrait de documents ;
• Envoi systématique et automatisé par MSSanté éventuellement via un connecteur partenaire, au format CDA R2 N3 et PDF/A-1), vers le patient et les professionnels correspondants, depuis une boîte aux lettres applicative du SGL, avec possibilité d’envoi de correctifs et de compléments, conformément au RGPD ;
  • Pour le contexte hospitalier et dans la perspective d’un envoi au DMP et par MSSANTÉ éventuellement géré au travers de connecteurs et/ou du DPI, la capacité de transmettre au DPI les CDA R2 N3 / N1 et les PDF/A-1 via un flux HL7 v2 via des messages ORU/OUL (contexte profil IHE LTW), avec données de masquage et de connexion secrète pour les cas où c’est nécessaire (certaines analyses pour les patientes mineures, consultation d’annonce VIH, etc.) ;

Tous ces éléments sont précisés dans le paragraphe 2.2 du DSR Bio SGL Vague 1 : https://esante.gouv.fr/sites/default/files/media_entity/documents/DSR-BIO-SGL-Va1.pdf

Non, l’atteinte de l’objectif repose sur la mise en œuvre d’un système d’authentification sécurisé et indépendant pour l’accès aux infrastructures de sauvegarde. Le candidat est libre du choix de la solution mise en œuvre pour atteindre cet objectif, qui peut reposer sur un active directory dédié comme sur des comptes locaux.
Dans le cas où un active directory dédié est mis en œuvre, un niveau supérieur ou égale à 3 doit être obtenu à l’audit ADS réalisé en fin de phase opérationnelle.
 

Il est interdit d’utiliser une clé de chiffrement symétrique unique commune à tous les badges et les terminaux (car trop peu sécurisée). Il est donc obligatoire d’utiliser une clé unique au sein de chaque badge, qui peut être diversifiée d’une clé maitresse commune et sécurisée.

De plus, il est imposé d’utiliser une solution de type Key Management System (KMS) propre à l’établissement qui contient l’ensemble des clés symétriques et/ou la clé maîtresse à partir de laquelle le KMS diversifie une clé fille propre à chaque carte et qui est encodée dans la puce DESFIRE de la carte lors de son enrôlement dans le système. Il s’agit ici d’une application DESFIRE locale et propre à l’établissement non fournie par l’ANS.

En plus de la gestion des clés cryptographiques et des cartes physiques, il convient de définir des processus d’encodage/enrôlement des cartes. Ces trois dimensions peuvent être définies et contractualisées entre l’établissement utilisateur et l’éditeur/intégrateur offrant le service. Cette solution ne s’adresse a priori qu’à des configurations s’appuyant sur des solutions d’IAM (Identity & Access Management) /SSO (single sign-on).

D2.03.C : Dans le cadre de la mise en œuvre du 3-2-1, il est en effet demandé d’avoir 3 copies sur 2 supports différents dont 1 support hors ligne / hors site. 

Non, les données du serveur de production ne peuvent pas être considérées comme une copie. La stratégie « 3-2-1 » implique la réalisation de 3 copies de sauvegarde, sur 2 supports différents, dont 1 nécessairement hors-ligne.

L’ANSSI rappelle dans son document « Sauvegarde des SI » qu’il est « essentiel de pouvoir disposer de trois copies des données sauvegardées : la sauvegarde initiale et deux copies supplémentaires. Cette redondance réduit le risque de perte de données en cas de défaillance d’un ou plusieurs supports ».

Aussi, le serveur de production ne peut pas être considéré comme une copie.
 

L'attendu défini pour le D2.01.C porte sur la réalisation d’un plan de continuité d’activité établie sur la base de 2 scénarios d’indisponibilité portant sur (i) l'indisponibilité du SI, et (ii) un autre scénario au choix du candidat.

Il est fortement recommandé de traiter les 4 scénarios d'indisponibilités listés dans le kit PCA / PRA proposé par l’ANS : indisponibilité des ressources humaines, indisponibilité bâtimentaire, indisponibilité des fournisseurs et indisponibilité informatique. Auquel cas, l'ensemble des dépenses associées à la réalisation des scénarios d'indisponibilité non encore couverts sont éligibles.
 

Compte tenu du grand nombre de dossiers actuellement en cours d’analyse, l’ANS ne peut pas répondre individuellement aux demandes de suivi d’état d’avancement des candidatures. 

En revanche, voici les jalons clés à retenir :​ 

• clôture du guichet de déclaration d’atteinte des objectifs : 30 juin 2025 ;​ 
• fin de la vérification par les ARS : 30 septembre 2025 ;​ 
• fin de l’instruction par l’ANS : 31 décembre 2025.​ 

Si vous avez une question concernant une demande de complément formulée par un vérificateur ANS via la plateforme Convergence, vous pouvez contacter le support afin d’obtenir les précisions utiles. 

Oui, il est prévu d'utiliser un certificat serveur pour transmettre les messages.

Oui, la liste des documents à envoyer ou intégrer est précisée en annexe du DSR.

• Un opérateur développeur désigne un opérateur MSSanté qui met en œuvre pour lui-même ou pour le compte d’opérateurs acheteurs les composants spécifiques aux exigences MSSanté (exemple : connecteur MSSanté).
• Un opérateur acheteur :  désigne un opérateur qui a recours à la technologie d’un opérateur développeur (disposant d’un contrat opérateur MSSanté signé avec l’ANS) en lui achetant les composants techniques tels que le connecteur MSSanté (ex : les établissements sanitaires opérateurs MSSanté qui achètent leur connecteur MSSanté auprès d’un opérateur MSSanté tiers).
   

L’API LPS DUI est une interface de messagerie basée sur le standard SMTP imposée à tous les opérateurs de MSSanté.

Tout éditeur de client/brique de messagerie MSSanté pourra s’interfacer à n’importe quel opérateur MSSanté du moment que l’éditeur présente l’API LPS/DUI.

Cependant, l’utilisation d’interfaces propriétaires est toujours autorisée.
 

Un opérateur MSSanté est une personne physique ou morale qui développe et fournit un service de Messageries Sécurisées de Santé au profit d’utilisateurs finaux.

L’opérateur professionnels fournit un service MSSanté à des professionnels habilités. Les opérateurs professionnels sont notamment un établissement de santé ou plus largement toute structure de soins, un groupement de coopération sanitaire, un industriel etc...

Les éditeurs de logiciel MSSanté correspondent aux éditeurs de clients de messagerie MSSanté qui développent des logiciels en capacité d’envoyer ou de recevoir des courriels, en se connectant à un Opérateur MSSanté, pour le compte d’un professionnel habilité.

Le terme « Connecteur MSSanté » correspond à l’ensemble des équipements qui concourent à l’interconnexion à l’espace de confiance MSSanté. Les opérateurs de messagerie sont tenus d’utiliser une solution technique de « Connecteur MSSanté » afin de pouvoir se raccorder techniquement à l’espace de confiance MSSanté. Un Connecteur MSSanté d’un opérateur communique uniquement avec un autre Connecteur MSSanté d’un autre opérateur.
 

Il est possible d'envoyer tout type de format de documents, structurés ou non. Il est donc possible d'envoyer des comptes rendus médicaux au format PDF, par exemple.

Le CR au format PDF permet une prise de connaissance facile par le professionnel quel que soit le contexte d’accès au message : logiciel métier, webmail, application mobile.

Le CR en format structuré (IHE_XDM.Zip) contient les mêmes informations que le format PDF, mais il ne peut être consulté que depuis un logiciel métier compatible. Le contenu de l’archive zip ne peut être consultée autrement.

Le format structuré permet une meilleure intégration des données dans les différents logiciels métier.

Pour plus d'informations, se référer au Guide de Normalisation des échanges, disponible au lien suivant : https://mssante.fr/is/doc-technique.
 

La liste blanche référence l’ensemble des Opérateurs reconnus comme répondant aux exigences du référentiel MSSanté et autorisés à proposer une offre de messagerie sécurisée de santé (des boîtes aux lettres). Cette liste est gérée par l’Agence du Numérique en Santé (ANS). Celle-ci est disponible ici.