336 Questions/réponses
Ségur du numérique en santé Médecin de ville Logiciel de Gestion de Cabinet (LGC-MdV)
1. Problématique
La preuve demandée pour l’exigence INS/va1.53 n’est pas adaptée pour le REM LGC, car elle repose sur la fourniture d’un flux HL7 v2, ce qui a du sens dans un contexte hospitalier.
2. Objectif de l’exigence
Vérifier la non transmission sous format informatisé du matricule INS et de son OID lorsque l’identité du patient n’est pas qualifiée.
Nous complétons le scénario et les preuves avec la possibilité d’utiliser une arche IHE_XDM
3. Scénario applicable
Objectif : Vérifier la non-utilisation du matricule INS (et de l’OID) pour une identité non qualifiée.
Étapes :
- Disposer d’une identité au statut « identité récupérée ».
- Produire un document de santé destiné à un échange informatisé ou un message d’interopérabilité IHE PAM contenant une INS non qualifiée.
- Vérifier que le matricule INS et l’OID ne sont pas utilisés pour référencer le document ou le message.
4. Preuves attendues
Preuve 1 : Démonstration (capture d’écran, vidéo, etc.) montrant l’identité (et son statut) et la donnée de santé produite.
Preuve 2 : Mise à disposition d’une archive IHE_XDM contenant le document de santé ou un message IHE PAM avec une INS non qualifiée.
Cette réponse vous a-t-elle été utile ?
Conformément aux exigences prévues au chapitre 4 des DSR et à la section 4.3 de l’Appel à financement, pour les solutions logicielles pour lesquelles vous souhaitez mobiliser des financements Ségur, la déclaration de l’ensemble des versions techniques ayant fait l’objet d’une information publique auprès de vos clients concernant un arrêt de maintenance et/ou un arrêt de commercialisation est obligatoire.
À cet effet, le fichier modèle de déclaration des versions obsolètes, disponible dans le formulaire d’éligibilité, doit être complété. Dans le cas où aucune version obsolète n’est à déclarer, cette situation devra être explicitement mentionnée dans le fichier dédié.
Cette démarche est un prérequis obligatoire à l’obtention du financement Ségur vague 2.
Cette réponse vous a-t-elle été utile ?
Oui, un composant "EAI/librairie" non autonome intégré dans le proxy doit passer son agrément au CDNA pour obtenir sa propre homologation.
Cette réponse vous a-t-elle été utile ?
En cas d'identification d'erreurs non légitimes, vous pouvez contacter l'adresse support monserviceclient.mssante@esante.gouv.fr en précisant dans l’objet « [MOTCO2] ».
L'équipe support prendra contact avec vous après analyse des traces fournies. Eventuellement MOTCO2 devra évoluer pour prendre en charge votre spécificité.
Cette réponse vous a-t-elle été utile ?
La définition du périmètre des tests d’intrusion relève de la responsabilité de l’éditeur, en fonction des cas d’usage et de l’architecture de la solution. Le processus générique est le suivant :
- L'éditeur prend connaissance du périmètre du REM et candidate pour une solution dont il donne le nom et la version.
- L’éditeur a la responsabilité de présenter à l’auditeur le périmètre concerné par le test d’intrusion, en s’appuyant sur sa connaissance de la solution et en se portant garant de la justification apportée.
- L'auditeur doit mentionner dans le rapport de pentest le nom/version de l'application concernée.
- Le guichet conformité vérifie que le nom et la version de l’application concernée correspondent à ceux déclarés par l'éditeur, et que le rapport est conforme aux exigences.
Cette réponse vous a-t-elle été utile ?
Les comptes créés sur Convergence en Vague 1 sont généralement repris sur iSC à condition que le mandataire social / représentant social de l'entreprise ait transmis le KBIS et une pièce d'identité.
Cette étape étant réalisée au cas par cas, nous vous conseillons de contacter l'équipe Convergence à l'adresse suivante : ans-support-convergence@esante.gouv.fr
Cette réponse vous a-t-elle été utile ?
La candidature doit être déposée par l’éditeur du logiciel dans Convergence, et non par l’établissement de santé.
Pour toute information complémentaire, nous vous invitons à consulter la page dédiée à la procédure de référencement sur le Portail Industriels
Cette réponse vous a-t-elle été utile ?
La date de référence à laquelle un dossier de preuves est considéré comme complet correspond à la date de dépôt par l’éditeur du dossier complet accompagné de l’ensemble des preuves.
Celles-ci pourraient faire l'objet d'échange entre l'Editeurs et l'équipe de Conformité de l'ANS.
L'Appel à Financement (II - Calendrier du SONS) précise deux dates :
- Date 2 - Date limite de dépôt d'un dossier complet de preuves de conformité
- Date 3 - Date de fin des échanges entre l'Editeur et l'ANS pour validation du dossier de preuves
Cette réponse vous a-t-elle été utile ?
Les financements de la vague 2 sont bien garantis par l'enveloppe financière européenne dédiée.
Cette réponse vous a-t-elle été utile ?
Comme indiqué dans le DSR, l'habilitation EDC PSC est obligatoire et constitue un pré requis à votre référencement Ségur.
Dans le cas où vous n'obtenez pas l’habilitation Editeur de logiciel utilisateur ou l’habilitation Editeur de Proxy e-santé de l’EDC PSC à échéance de la date 2 du guichet Ségur (date limite de dépôt d'un dossier complet), vous devez transmettre une capture d’écran de l’étape "Dépôt de preuves" sur le guichet EDC PSC devant obligatoirement afficher :
- Le numéro unique de référencement (NRU),
- Le nom de la solution,
- et l'ensemble des chapitres soumis au moins une fois
Vous pouvez poser vos questions via la messagerie de la plateforme Convergence ou contacter le Support Ségur depuis votre espace authentifié.
Cette réponse vous a-t-elle été utile ?
Le délai de réponse dépend du traitement par l’équipe en charge, mais vous pouvez généralement démarrer vos développements dès la réception d’une réponse positive.
Il est conseillé de surveiller votre messagerie et l’espace de suivi pour être informé dès que l’autorisation est accordée.
Cette réponse vous a-t-elle été utile ?
L’ensemble de la Solution Logicielle, c’est-à-dire le Composant Principal LPS, le Proxy e-Santé et les Composants Additionnels interfacés avec le Composant Principal LPS ou le Proxy e-Santé, font partie de l’Espace de Confiance PSC.
Le Composant Principal LPS et le Proxy e-Santé doivent être habilité dans l’Espace de Confiance PSC selon son rôle.
Cette réponse vous a-t-elle été utile ?
L’“éditeur” et l’“opérateur” sont deux rôles distincts :
- L’éditeur est responsable du développement et de la conformité du logiciel ou du Proxy e-Santé.
- L’opérateur est celui qui exploite la solution (logiciel ou proxy) en production.
Seul l’opérateur (ou un fournisseur disposant de l’habilitation Opérateur de Service Utilisateur) pourra s’enrôler pour financement auprès de l’ASP.
Cette réponse vous a-t-elle été utile ?
Dans ce cas, chaque Composant Principal LPS doit être homologué au CNDA et habilité EDC PSC. Le Proxy e-Santé doit seulement être habilité EDC PSC, mais pas homologué CNDA.
Attention, si des Composants Additionnels Non Autonomes sont intégrés au Proxy e-Santé, ceux-ci devront être homologués au CNDA.
Cette réponse vous a-t-elle été utile ?
Non. L’EAI tiers peut être intégré de deux manières :
- Côté LPS (Composant Principal) : dans ce cas, il est intégré au logiciel utilisateur et l’ensemble doit être homologué par le CNDA.
- Côté Proxy e-Santé : dans ce cas, l’EAI, intégré au Proxy e-Santé, sera homologué au CNDA. Le Proxy e-Santé en tant que tel n’a pas à être homologué au CNDA.
Dans les deux cas, l’EAI doit être homologué par le CNDA, que ce soit intégré au LPS ou au Proxy e-Santé.
Cette réponse vous a-t-elle été utile ?