FAQ des industriels

La liste des éléments et mentions obligatoires à faire figurer dans la facture sont détaillés au chapitre 12 du document "SONS-Modeles_de_documents-BDC-MOM-VA.pdf" disponible en cliquant ici

Pour rappel, l’établissement ou professionnel de santé ne peut bénéficier que d'une seule prestation Ségur financée par l'Etat par dispositif SONS. Si le PS/ES souhaite changer de solution logicielle après la signature du bon de commande, il doit s'accorder avec l'éditeur dont le bon de commande a été validé par l'ASP afin d'en demander l'annulation. Si cet éditeur avait perçu l'avance, il recevra un ordre de recouvrement de l'ASP pour la rembourser. A l'issue de l'annulation par l'ASP, un nouveau bon de commande pourra être traité. Dans tous les cas, cette nouvelle demande devra respecter la date de fin de dépôt des demandes d'avance.

Il sera demandé d'envoyer votre dossier de preuves en amont. Cet envoi sera suivi d’une visite sur site afin de vérifier certaines exigences. La procédure est semblable à celle du CNDA.

L'éditeur des fonctionnalités de PFI peut être un groupement de solutions : certains éditeurs font référencer une solution en se regroupant avec un ou plusieurs partenaires. Toutefois, dans tous les cas, un seul éditeur porte le référencement et le financement SONS   (tout en déclarant ses partenaires). C'est l'interlocuteur unique de l'ANS et de l'ASP. 

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 conditions portant sur la réception des Prestations Ségur sont définies au chapitre 6.2 des Appels à Financement pour chaque SONS. 

L’Opérateur de paiement met à disposition des Fournisseurs et Clients finaux, ainsi que les modèles de Vérification d’Aptitude (VA) qui traduisent précisément le périmètre de responsabilité de chaque éditeur dans la vérification des flux RI – DPI – PFI. 

Sont autorisées les signatures de VA attestant de la réalisation d’une Prestation Ségur pour une solution logicielle A en l’absence d’une autre solution logicielle B (pour des raisons indépendantes de l’éditeur de la solution A) devant échanger des flux avec la solution logicielle A. L’éditeur de la solution A apportera les correctifs nécessaires une fois que la mise à jour du logiciel B aura pu être réalisée.

"IEPS 8 - Le Système DOIT garantir l'unicité des identifiants de ses utilisateurs"

Scénario - vérification de l'unicité des identifiants utilisateur : 

1. Création d'un compte utilisateur ; 
2. Création d'un second compte utilisateur avec les mêmes traits d'identité utilisateur afin de déclencher une alerte de risque de doublon ; 
3. Afficher à l'utilisateur, l'alerte de risque de doublon »

Il est accepté de fournir une preuve plus adaptée à votre cas d’usage dès lors qu’elle prouve bien que l’unicité des identifiants utilisateurs est garantie.

A titre d’exemple :

Votre solution propose un numéro d’identification spécifique à votre solution.
Vous êtes conforme à l’exigence si l’attribution de ce numéro d’identification est unique à chaque compte.

Le renouvellement d'un certificat ne peut se faire que si le certificat actuel est encore actif. S'il est arrivé à échéance, l'administrateur devra générer un nouveau certificat.

Pour effectuer le renouvellement de votre certificat, vous devez vous connecter sur IGC Santé, puis sélectionner la demande de produit "le certificat" et valider son renouvellement. Il vous suffit ensuite de télécharger le nouveau certificat et de l'installer à la place de l'ancien. 

Pour plus d'informations, vous pouvez vous référer au replay du webinaire "Anticipez le renouvellement des certificats IGC-Santé"

Oui, le versement de l'avance DRIMBox est conditionné par l'enregistrement préalable d'une commande RIS comme précisé dans l'appel à financement DRIMBox.

Il reste cependant possible de signer une commande DRIMBox sans commande RIS.

Dans l’outil IGC, l’administrateur technique peut gérer l’ensemble de ses certificats depuis la page « suivi des certificats ». Il a notamment accès à la date de fin de validité de l'ensemble des certificats du parc géré.

Un certificat délivré par l'ANS a une durée de validité de 3 ans à compter de son obtention.

Son renouvellement n'est pas automatique. Une notification automatique est envoyée à l'administrateur technique 60 jours avant la fin de validité du certificat qui devra effectuer un renouvellement avant la fin de validité.

Les alertes relatives aux péremptions de certificats sont envoyées automatiquement aux administrateurs techniques depuis l'adresse : noreply@pfc.eservices.esante.gouv.fr.

Si l'adresse associée au certificat n'est plus valide ou consultée, la notification rappelant la fin du certificat n'est jamais reçue, il est donc important de renseigner une ou plusieurs adresses pérennes  : une adresse mail partagée ou générique sans CAPTCHA.

Le code d'erreur 905 doit être envoyé (Cf : https://interop.esante.gouv.fr/ig/hl7v2/trans-cda-r2/error-codes.html)

Les contrôles ne sont pas à effectuer par la PFI.
Les logiciels DPI ou RIS doivent comparer l’ensemble des traits d’identités (nom de naissance, 1er prénom de naissance, date de naissance, sexe, code INSEE du lieu de naissance, (liste des prénoms, matricule INS et OID si identité au statut qualifié présente)) du document reçu avec les traits des patients de sa base de données. 

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.

Deux références sont indispensables pour ouvrir votre dossier de référencement :Le NIE et le NIL. Ces deux références sont fournies lors de l'ouverture de votrre dossier au CNDA. Concernant le NIL, il s'agit d'un identifiant fourni lorsque vous “créez votre logiciel au CNDA”. Cet élément est alors renseigné sur la convention de Référencement ANS. Au cas où vous ne disposez pas de cette information, vous pouvez contacter la gestion Relation Client CNDA depuis votre espace personnel CNDA

Non, vous ne pouvez pas déposer toutes vos preuves dans un même dossier ZIP. Selon le document de spécifications de référencement de la vague 2 du Ségur numérique, chaque preuve de conformité doit être déposée individuellement et en respectant les chapitres spécifiques sur la plateforme Convergence.

Lé dépôt des preuves de conformité doit se faire par Chapitre sur la plateforme Convergence. Voici les points clés concernant le dépôt des preuves de conformité. Chaque preuve demandée dans Convergence est obligatoire et doit être déposée telle quelle, sans être regroupée dans un fichier ZIP global.

S'agissant des montées versions Ségur, le logiciel utilisé pour produire les preuves de conformité aux exigences du Ségur doit être disponible à la commercialisation. La convention de référencement Ségur stipule que l’éditeur doit pouvoir commercialiser les montées de version logiciel référencé au plus tard dans les 2 mois à compter de l’entrée en vigueur de la Convention. La montée de version de ce logiciel étant engagée suite au référencement.
 

Pour les sociétés de Téléconsultation proposant des mises en relation avec un médecin sans rendez-vous, le principe de la territorialité s’applique selon les scénarios établis par le référentiel. 

Pour les sociétés de Téléconsultation proposant des mises en relation avec un médecin avec rendez-vous, le principe de territorialité s’applique également selon les scénarios établis par le référentiel. 

Pour le cas où la société de téléconsultation propose les 2 cas d’usage de mise en relation avec un médecin avec et sans rendez-vous, et dans le cas spécifique où le « sans rendez-vous » n’est proposé au patient qu’après lui avoir proposé des rendez-vous, alors il est possible que seuls les scénarios de prise de rendez-vous soient conformes au principe de territorialité. En effet, dans ce cas particulier, un médecin du territoire aura été proposé au patient suivant l’algorithme proposé dans l’exigence ETHT.02. 

A noter que, dans tous les cas, si le patient décide de ne pas saisir sa localité (ayant comme conséquence le non applicabilité du principe de territorialité), il doit avoir été préalablement informé des conséquences sur la prise en charge de l’acte via l’affichage du message d’information (ETHT.01).

Le parcours téléphonique ne rentre pas dans le périmètre du référentiel d’interopérabilité, de sécurité et d’éthique des SI de téléconsultation. 

Néanmoins, si le parcours téléphonique peut se transformer en téléconsultation avec flux vidéo et audio (par exemple, envoi d’un lien de connexion à l’issu de l’échange téléphonique), alors le système d’information incluant le parcours téléphonique doit respecter le principe de territorialité suivant :

• ETHT 01 : en rappelant le principe de territorialité à l'usager en informant les messages de territorialité :
  "Votre localisation vous est demandée afin de vous mettre prioritairement en relation avec un médecin proche de chez vous. Cette proximité doit permettre d’optimiser la qualité de votre prise en charge. Dans tous les cas, le médecin évaluera et facilitera le renvoi vers une consultation en présentiel si votre état de santé le nécessite. Pour en savoir plus sur les conditions de prise en charge des téléconsultations l’Assurance Maladie : https://www.ameli.fr/assure/remboursements/rembourse/consultations-telemedecine/telemedecine/teleconsultation".
• ETHT 02 : le patient doit pouvoir renseigner sa localisation afin que le principe de territorialité s’applique, comme énoncé dans l’ETHT.02.

La transmission de données patient à un autre professionnel via MSSanté n'implique pas de disposer d'une identité INS qualifiée. Dans le cas ou l'INS du patient n'est pas qualifiée, le document transmis ne doit pas contenir l'INS et OID.