FAQ Etablissement de santé

La relation contractuelle est établie entre l’éditeur et l'établissement ou le professionnel de santé. Bien que la puissance publique verse le financement directement à l'éditeur, il y a bien une commande et l'édition d'une facture adressée par l'éditeur à son client. Par conséquent, la relation contractuelle demeure encadrée le cas échéant par les règles liées au marché public.

L’opérateur, afin d’être en mesure d’obtenir les certificats serveur qui l’authentifieront dans l’Espace de Confiance, doit renseigner son FINESS juridique dans le contrat d'adhésion. Les établissements reliés au FINESS géographique appartiendront à la structure mère enregistrée sous le FINESS juridique.

Ainsi, l'enregistrement du FINESS juridique suffit dans le cas où une structure a plusieurs établissements.

Quelle est la différence entre FINESS juridique et géographique ?

• Le numéro FINESS juridique, qui porte l'immatriculation des entités juridiques (EJ) régissant les établissements sanitaires, sociaux, médico-sociaux, correspond à la notion de personnalité morale et est associé au SIREN de l'entreprise au moment de son enregistrement.
• Le numéro FINESS géographique qui assure l’immatriculation des établissements géographiques (ET) correspond à une implantation géographique et est caractérisé par une et une seule catégorie d’établissement. Chaque numéro FINESS géographique est rattaché à une et une seule entité juridique.
• Cependant, il convient de noter que la logique d’attribution du numéro FINESS géographique diffère de celle du numéro SIRET, et que plusieurs numéros FINESS géographiques peuvent cohabiter au sein d’un même SIRET. En effet, à une même adresse, on peut retrouver plusieurs « établissements géographiques » FINESS (EPHAD, centre de formation, laboratoire, centre hospitalier, …), relevant d’une catégorie d’établissement différente mais appartenant à une même entité juridique.
• Le SIRET porté par le numéro FINESS est celui de l’établissement au moment de son enregistrement et de la parution de l’arrêté lui attribuant son numéro FINESS.
   

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.
 

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.

Tout PS souhaitant ne pas voir sa BAL MSSanté affichée dans l’Annuaire Santé peut demander à être mis en liste rouge auprès de son Opérateur MSS. Sa BAL sera toujours fonctionnelle et active : elle continuera à envoyer et recevoir des messages et sera toujours compatibilisée dans les statistiques MSSanté.
 

Il n’existe aucune limite d’envoi de message entre les 3 types de BAL (personnelle, organisationnelle, applicative).

Cependant, une exigence particulière s’applique à tout message envoyé à partir d’une BAL applicative qui impose de renseigner la BAL de réponse au message envoyé (paragraphe 3.3.3, exigence ECO.2.2.5).
 

Être MSSanté compatible pour un Opérateur signifie que la solution respecte toutes les exigences de l'Espace de Confiance en termes d'interopérabilité, de sécurisation des données. La solution de messagerie de l'Opérateur respecte la liste des exigences et est compatible avec les normes de MSSanté.

Ces exigences sont à retrouver dans les référentiels, disponible ici.