FAQ Entreprise du numérique en santé

C'est un scénario nominal possible si les fichiers d'attente ne sont pas synchronisés au sein du logiciel. Si cette situation se produit :

• Côté DMP : La V2 sera stockée (comme version initiale ou de remplacement selon le choix fait à la Question 1).
• Côté MSSanté : Le destinataire ayant reçu la V1, l'émetteur DOIT obligatoirement renvoyer la V2 par MSSanté (selon le principe du "Annule et remplace" exigé en vague 1) afin de garantir que le correspondant dispose de la même information médicale que celle présente sur le DMP du patient.
   

Note : Les éditeurs sont encouragés, dans la mesure du possible, à synchroniser leurs files d'attente DMP et MSSanté pour éviter ces écarts.

Si le DMP n'a jamais reçu la version initiale (V1), toute tentative d'envoi d'une V2 contenant une métadonnée de remplacement (RPLC ou lien vers l'identifiant de la V1) sera refusée par le DMP, car le document à remplacer est inconnu de ses services. Dans ce scénario, le logiciel a deux options, la première étant fortement recommandée :

1. Option privilégiée : Envoyer directement la version finale (V2) au DMP en tant que document initial (V1 pour le DMP). Les modifications intermédiaires restent purement locales au logiciel métier.
2. Option secondaire : Envoyer de manière séquentielle la V1, puis la V2 avec sa requête de remplacement (génère un trafic technique peu utile).

En vertu du RGPD vous devez déjà tracer l’accès aux données de santé à caractère personnel. Le fait de rajouter l’INS à ces données de santé à caractère personnel ne change rien. Il sera simplement vérifié que cette traçabilité est faite. Cette exigence sera vérifiée en s'assurant que lorsqu'un acteur accède au dossier d'un usager - doté ou non d'une INS (ouvre le dossier de cet usager) - cet accès est tracé dans la solution.

L’exigence SC.MSS/va1.15 telle que définie historiquement dans le référentiel client de messagerie MSSanté est erronée depuis sa publication. Elle décrit un mécanisme d’accusé de réception non conforme aux normes RFC. Cette anomalie est présente dans les référentiels de la vague 1 et reprise dans certains REM de la vague 2. Sur le terrain, les éditeurs ont majoritairement implémenté les accusés de réception conformément à la norme RFC.

L’exigence SC.MSS/va1.15 évolue pour s'aligner sur le mécanisme DSN normalisé afin de garantir la bonne émission et réception des accusés de réception par les solutions MSSanté.

La nouvelle version de l'exigences est la suivante : 
Le système DOIT permettre de demander un accusé de réception de type DSN lors de l'émission d'un courrier. Lors de l'envoi du message, le paramètre NOTIFY doit être positionné avec les valeurs SUCCESS,FAILURE,DELAY dans la commande SMTP "RCPT TO:"
Le mécanisme DSN est décrit dans la RFC 3461.
Exemple : RCPT TO: <adresse email> NOTIFY=SUCCESS,FAILURE,DELAY

Les nouveaux scénarios et preuves sont également mis à jour : 

Scénario - Accusé de réception par l'opérateur destinataire
Etapes :

1. Préparer un courriel.
2. Choisir l'option qui permet d'avoir un accusé de réception de type DSN.
3. Envoyer le message.

Preuves : 

• Preuve 1 : Produire des copies d’écran : du courriel envoyé afin de valider la preuve.
• Preuve 2 : Produire des copies d’écran : de l’accusé de réception reçu suite à l’envoi du courriel émis.

L’utilisation d’un composant tiers déjà homologué par le CNDA ne dispense pas systématiquement de réaliser une demande dans le cadre de la mise en conformité de votre solution logicielle. Dans la majorité des cas, une démarche reste nécessaire, cela dépend du type de composant tiers et de son mode d’intégration.

Afin de clarifier les règles applicables, plusieurs situations doivent être distinguées :

Premier cas de figure : le composant principal de la solution logicielle PS utilise un composant additionnel non autonome

Un composant additionnel non autonome est appelé au CNDA "application EAI" dans le cas du DMP ou "moteur à IHM" masquée dans le cas de l'INSi.

Dans ce cas :

• Chaque application EAI ou chaque moteur à IHM masquée doit passer une homologation au CNDA.
• Chaque composant principal d'une solution logicielle qui intègre une application EAI / moteur à IHM masquée doit passer une homologation au CNDA.

A noter que l'homologation est complète mais plus rapide car les applications EAI/moteur à IHM masquée ont déjà validé une partie des tests à repasser.

Deuxième cas de figure : le composant principal de la solution logicielle PS utilise un composant additionnel autonome

Un composant additionnel autonome est une application (tierce) à part entière avec des IHM autonomes et visibles. Au CNDA, il s'agit d'une application autonome. Le composant principal d'une solution logicielle PS s'interface avec l'application autonome (tierce) via un appel contextuel. L'opérateur de la solution logicielle PS peut opérer une instance dédiée de la solution autonome (tierce) ou peut utiliser une instance mutualisée opérée par l'éditeur de la solution autonome tierce.

Dans ce cas :

• Chacune de ces applications autonomes tierces doit passer une homologation au CNDA.
• Dans le cas du composant principal de la solution logicielle PS :
  • Si l'opérateur du composant principal de la solution logicielle PS opère aussi une instance dédiée de l'application autonome (tierce) alors le composant principal de la solution logicielle PS doit passer une homologation d'interfaçage avec l'application autonome (tierce) dans le cadre de la conformité DMP.
  • Pour l’INSi et l’Ordonnance Numérique les éditeurs intégrant des composants tierces (moteur coté CNDA) doivent déposer une demande de conformité en mode apparent.
    • Dans le cas où le logiciel intègre un composant déjà autorisé « INSi » et/ou « Ordonnance Numérique » en mode IHM apparente, l’éditeur n’a pas à constituer de dossier de preuves de tests, il peut passer directement à l’étape d’examen de conformité indiquée à l’Article 5.3 : Etape d’examen.
      Dans le cas où le logiciel intègre un composant déjà autorisé « INSi » en mode IHM masquée (ou semi masquée), l’éditeur doit réaliser toute les phases de la procédure de conformité.

Oui. Même si le logiciel « technique » est unique, chaque nom commercial correspond à un NIL distinct, et nécessite donc une demande de conformité CNDA propre.

La « fenêtre d’interrogation » ne désigne pas nécessairement une interface dédiée. Elle correspond à l’endroit où l’utilisateur peut modifier les traits d’identité utilisés pour l’appel au téléservice INSi.

Cette modification peut être réalisée :

• soit via une fenêtre dédiée,

• soit directement dans la fiche d’identité du patient.

L’exigence est satisfaite dès lors que l’utilisateur peut modifier les traits (notamment le COG) et relancer l’interrogation, indépendamment du choix ergonomique du logiciel.

Vous pouvez déposer les preuves communes pour une seule candidature. A l'obtention du référencement de celle-ci, vous complétez les 3 autres candidatures avec le NRU de la première Solution logicielle référencée.
Vous pouvez, sans attendre le premier référencement, déposer les preuves non communes. Pour vous y aider, consultez la liste des équivalence Va2 du SONS sur lequel vous candidatez.

Point d'attention 1 : les chapitres concernés par les nouveaux composants additionnels doivent aussi être redéposés.​

Point d'attention 2 : si la solution racine choisie n’a pas encore obtenu son référencement, elle devra l’obtenir avant le jalon Date 2 afin de compléter les autres candidatures avant cette date (dépôt dossier complet de preuves). 

Pour bénéficier de l’équivalence des preuves, vous devrez obtenir le premier référencement. Dans le formulaire d’éligibilité de la candidature de la solution B, vous pouvez indiquer que vous comptez bénéficier de l’équivalence des preuves de la solution A en cours de référencement. 

A  l'obtention du référencement de la solution A, vous pourrez, dans votre candidature B, demander à rouvrir votre formulaire d’éligibilité pour indiquer le NRU de la solution A, et déposer l’attestation sur l’honneur indiquant que le composant principal de votre solution B est identique à celui de la solution A. Les preuves communes aux deux dispositifs ne vous seront pas demandées au niveau de l’espace de dépôt des preuves.

Point d'attention : le NRU de la solution A doit impérativement être complété dans la candidature B avant la Date 2 du deuxième dispositif. A défaut le dossier B sera considéré comme incomplet à cette date et sera rejeté.

Si votre Solution a été référencée en vague 1, en renseignant le numéro de référencement vague 1 dans la candidature vague 2 les preuves déjà validées en vague 1 et reprises dans le REM vague 2 sont automatiquement retirées du périmètre de dépôt. Elles sont invisibilisées dans Convergence.

Point d'attention : si la candidature Vague 2 porte sur des profils différents de la Vague 1, alors les preuves du périmètre Vague 1 sont demandées pour ces profils.​

Le principe de compatibilité ascendante implique que le logiciel, dans sa version candidate au référencement Ségur et souhaitant bénéficier du principe d’équivalence des preuves avec une solution racine référencée (qui peut être soit exactement le même logiciel, soit le même logiciel sous un nom commercial différent, soit un logiciel dont le composant principal est identique à celui du logiciel candidat), doit respecter plusieurs règles :

• la version candidate doit être égale ou supérieure à la version de la solution racine ;
• la version candidate du logiciel doit maintenir la conformité aux exigences Ségur obtenue pour la version de la solution racine.

Par ailleurs, l’article 10 de la convention de référencement précise la responsabilité de l’éditeur de notifier l’Agence du Numérique en Santé si des modifications apportées au logiciel référencé sont susceptibles de le rendre non conforme aux exigences Ségur.

La compatibilité ascendante est également formalisée par la soumission d’une attestation sur l’honneur, fournie selon un modèle ANS disponible sur les pages des dispositifs de la vague 2. Dans cette attestation, l’éditeur déclare que la version candidate respecte les exigences Ségur obtenues lors du référencement de la solution racine

Non, il n’existe pas d’équivalence automatique des certificats CNDA. Si la solution a été déclarée dès l’origine au CNDA avec ses déclinaisons, l’homologation peut couvrir l’ensemble.
En revanche, chaque nom commercial distinct nécessite un NIL distinct, et donc une démarche CNDA propre, même si l’architecture est identique. Si l’architecture diffère, une nouvelle demande de conformité CNDA est obligatoire.

Oui. L’équivalence des preuves s’applique également aux habilitations EDC PSC, sous réserve du respect de la compatibilité ascendante, de la cohérence entre LPS, Proxy e-santé et périmètre déclaré. Les preuves déjà validées ne sont pas redemandées, sauf en cas de modification du périmètre concerné.

L'ENS doit déposer sur la plateforme Convergence au moins une fois son dossier avant le jalon de fin de dépôt du dossier administratif (Date 1). 

L’ANS procède ensuite à l’analyse de l’éligibilité de la solution logicielle de l’ENS au dispositif. Et une fois que sa solution logicielle est déclarée éligible, l’ENS procède aux dépôts des preuves. Une fois cette étape franchie ou après ce jalon (Date 1) si un dossier a bien été déposé dans les temps, l'ENS peut demander à modifier son dossier administratif afférent à son dispositif, que ce soit par exemple au niveau du Proxy ou au niveau des composants additionnels. 

L’ANS se charge de rouvrir les étapes correspondantes, soit la Candidature administrative, soit l’Eligibilité. Un point d’attention : ces changements à l’étape Candidature administrative, ou à l’étape Eligibilité ou aux deux étapes, peuvent entrainer des modifications sur les preuves à déposer ensuite.

Non. S'il y a plusieurs noms commerciaux pour une même solution logicielle, l'auditeur peut :

• Soit faire apparaitre l'ensemble des noms commerciaux sur le rapport de test d'intrusion ;
• Soit proposer un rapport de test d'intrusion par nom commercial, chacun correspondant à une copie d'un même rapport sur laquelle un nom différent est mentionné.

Il est de la responsabilité de l'éditeur d'expliquer à son auditeur à quoi correspond chacun des noms commerciaux ET il est de la responsabilité de l'auditeur de s'assurer qu'aucun écart d'un nom commercial à un autre ne justifie de tests complémentaires.