FAQ Entreprise du numérique en santé

L'ensemble des preuves à soumettre pour démontrer la conformité à la section MSS doit impérativement provenir de la solution candidate elle-même. Exception faite des preuves MSS.02, MSS.17 & MSS.27 : les lignes de codes peuvent être reprises de l'éditeur de la solution tierce. Les identifiants des traces et des logs (…) produits lors de la validation de la conformité au référentiel socle MSSanté #2 doivent être ceux de la solution candidate au référencement TLC.

L’exigence MSS.02 est la suivante : "Le client de messageries MSSanté du Système DOIT vérifier que le certificat présenté par l’opérateur MSSanté n’est pas expiré, "conformément au référentiel socle MSSanté #2 (Clients de Messageries Sécurisées de Santé) [MSS1]." 

Pour répondre à l’exigence MSS.02, le candidat peut transmettre l’identifiant d’exécution du cas de test réalisé dans le cadre de l’exigence MSS.10.

La version v15 apporte des clarifications et un point de contrôle en moins qui est la vérification antivirus lors de upload de fichier. Selon le cas il est possible :

• soit l'ENS a déjà réalisé le test d’intrusion sur la base d’une version plus ancienne du formulaire alors l'ENS peut poursuivre sur cette base ; il n'est donc pas nécessaire de relancer un audit complet sur le nouveau formulaire. Si l'ENS a une non conformité sur le point de contrôle qui a été retiré de la nouvelle version du formulaire test d'intrusion v15, ce point n'est pas considéré comme bloquant.
• soit l' ENS n'a pas encore réalisé le test d’intrusion et il faut alors obligatoirement partir sur la nouvelle version du formulaire v15.

On entend par "correspondant" tout professionnel de santé avec lequel un utilisateur de la solution est susceptible d’interagir. L’utilisateur de la solution se distingue du correspondant par le fait d’avoir un accès à la solution (via une authentification PS avec un MIE, PSC, etc…), contrairement au correspondant.

Pour qu'une solution soit intégralement conforme au référentiel ANN, la création de fiche correspondant doit être effectuée dans l'application à chaque fois qu'un PS est mentionné par un utilisateur, dans un dossier patient ou ailleurs, ou consulté via l'envoi de documents ou d'informations.

Les informations obligatoires du correspondant et la fréquence de rafraichissement de ces informations sont les mêmes que pour l'utilisateur.

Ces preuves avaient été mises en place dans le cadre d'une certification pour le 31/12/2023. Elles n'ont plus lieu d'être. Pour rappel, pour être conforme aux exigences pentest, il faut :

• qu’il n’y ait plus aucune non-conformité pour les points de contrôle de gravité haute,
• qu’il y ait moins de 10 non-conformités pour les points de contrôle de gravité moyenne. 

Dans ce cas, pas besoin de lettre d'engagement à effectuer les démarches correctives.

L'expression fait référence aux cas où le système intègre un mécanisme d'authentification interne propre à la plateforme permettant aux utilisateurs professionnels de santé de s’identifier (exemple : identification par login / mot de passe). Dans ce cas, les exigences IEPS 05, IEPS 06 et IEPS 08 sont applicables. 

Si l’éditeur ne gère pas lui-même l’authentification et utilise uniquement un service externe ou une fédération d’identité (exemples : Pro Santé Connect, FranceConnect…), alors le système ne met pas en œuvre son "propre dispositif d’authentification". Dans ce cas, les exigences IEPS.05, IEPS.06 et IEPS.08 sont "Non Applicables". Une déclaration sur l'honneur justifiée, datée et signée par le responsable légal de l'entreprise, devra être fournie en preuve.

L'exigence IEPS.08 "SI le Système propose son propre dispositif d'authentification ET SI il autorise une identification électronique à un seul facteur succédant à une identification électronique à deux facteurs, ALORS le Système DOIT imposer un délai maximal paramétrable entre ces deux identifications électroniques et vérifier que le simple facteur utilisé fait partie du dispositif d'authentification à deux facteurs utilisé initialement." est considérée "Non Applicable" dans le cas où votre système propose exclusivement l'authentification à deux facteurs (2FA). Une déclaration sur l'honneur justifiée, datée et signée par le responsable légal de l'entreprise, devra être fournie en preuve. Cette déclaration doit préciser que le système ne permet à aucun moment l’utilisation d’un seul facteur d’authentification après une authentification à deux facteurs.

Il est nécessaire de :

• préciser les standards d'authentification sécurisés utilisés pour l'authentification des utilisateurs (exemple : OAuth2, SAML etc.…) ; 
• préciser les mécanismes mis en place pour authentifier les parties communicantes (exemple : certificats numériques x.509) ; 
• préciser les noms et les versions des protocoles de communication utilisés pour la transmission des flux vidéo (webRTC, RTP etc.…) et les mécanismes de protection de ces protocoles le cas échéant ; 
• préciser les mécanismes mis en place pour assurer l'intégrité des données transmises (algorithmes SHA-256, HMAC etc.…) ; 
• éventuellement, fournir un schéma d'architecture montrant comment les flux vidéo sont protégés de bout en bout, pour appuyer les éléments précédents ; 
• préciser les protocoles ne pouvant être chiffrés, le cas échéant.

Rappel de l'exigence : Lors de la visualisation d’un document au format HL7 CDA R2, le Système DOIT le rendre lisible par un humain (l'entête et le corps) avec la feuille de style envoyée par le producteur si elle existe, sinon avec la feuille de style du consommateur (un lien pour obtenir une feuille de style d'exemple est fournie dans le scénario).

Scénario - Vérifier la lisibilité par l'utilisateur des données d'un document au format HL7 CDA R2 N1
Prérequis : Un document au format HL7 CDA R2 N1 est reçu par le système.
Etapes du scénario : 

• intégrer un document H7 CDA R2 niv 1 ;
• afficher les données de l'en-tête d'un document au format CDA R2 N1.

Il est recommandé au consommateur de vérifier et de nettoyer la feuille de style du producteur afin de se prémunir des attaques de type injection, Cross Site Scripting, déni de service...etc. Si la feuille de style du producteur présente un quelconque risque de sécurité, le système doit utiliser sa propre feuille de style pour afficher le document.

La plateforme interop.esante.gouv.fr permet de visualiser les preuves en avance de phase, mais pour le référencement vous devez utiliser la plateforme interopsegur.esante.gouv.fr.

Non, il est simplement nécessaire de fournir un lien permanent vers le test "CI-SIS-CR-CDA-N1-Create_doc-Sc1" pour un type de document géré par la solution.