Les certificats devront être rattachés au FINESS juridique de l'ES, le FINESS géographique étant véhiculé dans le VIHF des transactions DMP.

Néanmoins les certificats peuvent être rattachés aux FINESS géographiques. Dans ce cas il faut des certificats différents pour chaque FINESS géographique.

L'AF précise qu'il s'agit de l'envoi d'un message, sans imposer une pièce jointe. L'envoi doit être fait à l'adresse de test "reponse.automatique-test@patient.mssante.fr".

Non, il n’est pas demandé que le logiciel référencé affiche le numéro unique de référencement. En revanche, les noms commerciaux et versions affichés par le logiciel doivent permettre la vérification aisée par l’acheteur du bon référencement de la solution sur le site officiel de l’ANS.

La création de votre compte Gazelle est réalisée par les équipes de référencement dès que votre dossier de candidature est déclaré éligible. 

Il y a un délai d'environ une semaine d'instruction durant lequel vous seront transmises les informations pour accéder à Gazelle. 

Ce n'est pas systématique. L'éditeur doit assurer la compatibilité ascendante de ses solutions et déclarer les modifications à l'ANS. Ce principe est décrit dans les conventions de référencement pour chaque SONS.

Non, cela n'est pas interdit. Toutefois dans le cadre des échanges automatisés décrits dans les exigences, seuls sont concernés les CDA.

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

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. 

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