Votre question concerne quel type d'offre ?
Votre question concerne quel couloir Ségur ?
Votre question concerne quel dispositif Ségur ?
Votre question concerne quel produit ou service produit?
Votre question concerne quelle thématique ?
Non, ce programme ne finance pas l'acquisition d'un nouveau logiciel, mais sa mise à jour sous réserve que le logiciel soit référencé "ségur" par l'ANS.
Il incombe à l'éditeur de s'occuper de l'ensemble des démarches pour le référencement et la demande de financement.
Toutefois si l'offre de l'éditeur permet d'identifier séparément les prestations relevenant du périmètre Segur, alors ces prestations pourront bénéficier du financement SONS.
Cette réponse vous a-t-elle été utile ?
Sauf cas d'exonération explicitement prévu par le code général des impôts, la prestation Ségur relève du taux normal de TVA en vigueur. Au 1er décembre 2021, celui-ci s'élevait à 20% en métropole, et à 8,5% en outre-mer. Si votre client n'est pas assujetti à la TVA, le champ "TVA applicable" dans votre JSON est égal à "HT". Vous devrez fournir à l'ASP une attestation de non-assujettissement à la TVA délivrée par la DGFIP, la DRFIP ou la DDFIP le cas échéant.
Cette réponse vous a-t-elle été utile ?
Les dispositions de la maintenance dans le cadre du Ségur sont conditionnées à l'existence d'un contrat de maintenance entre le fournisseur et le client final.
La prestation Ségur inclut les droits d'usage de la version référencée ainsi que les éventuels surcoûts de maintenance corrective sur les anomalies liées aux fonctionnalités prévues par le DSR, dans la limite de six années.
Nous vous invitons à consulter le contenu des Appels à Financement qui précisent les conditions relatives au périmètre de la Prestation Ségur au paragraphe 4.3 "Condition relative au périmètre de la Prestation Ségur".
Cette réponse vous a-t-elle été utile ?
Le dispositif SONS « impose la mise à disposition, à la demande du Client final, de l’historique des données de santé relevant du périmètre du référencement ». Le format des fichiers mis à disposition doit être lisible, exhaustif, exploitable, et documenté par le Fournisseur.
Ce périmètre comprend :
- Les documents concernés listés en annexe 3 du DSR-MDV-LGC-Va1.pdf ; les informations nécessaires à son import : le nom, prénom, date de naissance et sexe du patient ainsi que, lorsqu’elles sont stockées dans le logiciel ; l’INS, la date de production et le type de la donnée, sous une forme structurée dans le fichier ou attenant au fichier.
- Il n’inclut pas les autres données contenues dans le LGC. L’export de celles-ci (données de facturation, notes de consultation, …) dépend des conditions contractuelles passées avec le fournisseur.
Cet export doit être réalisé sous un format standard, structuré et/ou non structuré, au choix du Fournisseur (ex : HL7 CDA, HL7 FHIR, PDF, DOC, DOCX, XML, etc.), avec une documentation détaillant la procédure à réaliser. La profondeur de l’historique ainsi que le professionnel de santé concerné doivent être paramétrables.
(Extraits du document d’Appel à Financement, §4.5).
Cette réponse vous a-t-elle été utile ?
Oui. Pour obtenir plus d’informations sur ces contrôles, veuillez-vous reporter aux slides ci-dessous, en particulier à la slide 3 ("Précisions sur les contrôles au guichet ASP")
Cette réponse vous a-t-elle été utile ?
La marche à suivre si la solution que vous avez référencée ne respecte pas les règles de nommage des versions est détaillée dans les slides ci-dessous, en particulier en slide 2 ("Déclinaison du plan d'action selon les cas de figure")
Cette réponse vous a-t-elle été utile ?
Les règles de nommage des versions référencées Ségur sont détaillées dans le slide ci-dessous
Cette réponse vous a-t-elle été utile ?
Lorsqu’une structure s’authentifie pour l’appel au téléservice INSi par un certificat logiciel, il s’agit du FINESS utilisé pour ce certificat. Selon les ES, ce peut être le FINESS juridique ou le FINESS géographique.
Lorsque l’appel au téléservice est réalisé avec une carte CPx, il s’agit du numéro FINESS de l’établissement qui est utilisé par l’éditeur lors de l’appel à ce téléservice. Selon les sites, il pourra donc s’agir du FINESS géographique ou du juridique.
L'éditeur doit donc renseigner un seul FINESS (juridique ou géographique qui sera le plus suceptible de satisfaire les contrôles a posteriori).
Cette réponse vous a-t-elle été utile ?
Tous les sites doivent signer les VA respectives. Un seul document PDF regroupant l'ensemble des VA pour une même demande de financement devra être déposé sur le portail de l'ASP.
Cette réponse vous a-t-elle été utile ?
Un operateur acheteur doit se faire enrôler une seule fois auprès de l'ASP. Il doit présenter un seul BDC (ou facture pour le solde) quelque soit son nombre de fournisseurs de connecteurs MSSanté. Le nombre de sous-traitants Opérateurs développeurs n'a pas d'impact sur le financement
Cette réponse vous a-t-elle été utile ?
Vous devez renseigner le numéro de référencement que vous aura communiqué l'Opérateur développeur qui vous fournit le connecteur MSSanté. Il faudra au préalable que ce dernier soit référencé Ségur auprès des services de l'ANS.
Cette réponse vous a-t-elle été utile ?
Oui il le peut. S'il opère sur un marché concurrentiel (sous la forme d'une distribution GIE / GIP) il pourra entrer dans le Système Ouvert et Non Sélectif.
S'il n'opère pas sur un marché concurrentiel (ie in house), nous devrons traiter au cas par cas.
Dans tous les cas, le respect des exigences techniques sera obligatoire.
Cette réponse vous a-t-elle été utile ?
Vous pouvez décomposer votre offre de services en autant de produits que vous souhaitez pour renseigner la plateforme. La segmentation de votre offre adéquate doit être trouvée au regard de votre activité et les parcours et démarches proposés par la plateforme.
Il est notamment nécessaire de décliner en plusieurs produits les versions associées à des supports ou devices différents dès lors que ces derniers ont une incidence sur le niveau de maturité.
Afin de faciliter l’identification des produits, chacune des éditions et versions des produits commercialisés est à renseigner. Nous vous proposons notamment de respecter la nomenclature suivante pour le nommage du produit [NomDuProduit] [OS] [Appareil] avec :
- appareil qui peut prendre pour valeur « Mobile » ou « Site Web »
- OS qui peut prendre pour valeur « iOS », « Android », « Windows », « Linux » ou tout autre système d'exploitation.
Également, dans le cadre du référencement Mon espace santé : vous devez ajouter comme produit la solution qui est visible pour le citoyen dans le catalogue de services. Le nom commercial doit être le même que celui visible du citoyen.
Cette réponse vous a-t-elle été utile ?
Pour vous inscrire à la plateforme Convergence, vous devez télécharger le formulaire de demande de compte afin d’ouvrir un compte en tant que Responsable habilité à représenter l'entreprise
Avant de remplir ce formulaire, nous vous invitons à vérifier que votre entreprise n'est pas déjà représentée par une autre personne laquelle est en mesure de vous créer un compte pour accéder à la Plateforme. Pour toute question, veuillez contacter le support à l’adresse : ans-support-convergence@esante.gouv.fr.
Dès que vous recevrez l'e-mail de confirmation de création de votre compte, vous pourrez initialiser votre mot de passe et accéder à la Plateforme après avoir accepté les Conditions générales d’utilisation.
Cette réponse vous a-t-elle été utile ?
Non, l'exigence PGSSI-S IEU 2 n'est pas applicable lorsque la solution est esclave de l'identité.
Cette réponse vous a-t-elle été utile ?
Il doit être possible de voir la création ou le résultat de la création d’un patient dans la solution avec son identifiant privé et ses 5 attributs. Il doit être possible aussi de visualiser que ce patient est associé à son INS, même si peut être les étapes du scénario de conformité sont faites en même temps.
Il faudrait donc, s’il n’est pas possible de visualiser la création d’un patient via la GAP, avoir le flux de création permettant de créer le patient et celui pour associer l’INS dans la solution (si différent), puis d’avoir une copie écran d’un compte usager associé à son matricule INS.
NB : Attention à ne pas confondre la création de l'identité (au niveau de la GAP) et la création du compte dans le DMN. Si la solution ne permet pas l'accès à la GAP, cela signifie qu'il ne peut récupérer l'identité.
Cette réponse vous a-t-elle été utile ?
Pour IHE PAM, les données sont transmises par des messages HL7 V2. Il n’y a donc pas d’accès aux données via une API sécurisée. Différents protocoles de transport des messages sont aussi mis à disposition par HL7. Le protocole le plus répandu (adopté par un certain nombre de profils IHE) est basé sur les couches socket TCP-IP et s’appelle MLLP (‘Minimal Lower Layer Protocol’). Ce protocole est fréquemment encapsulé par IHE dans des tunnels sécurisés par une authentification forte (X509) des deux extrémités.
Cette réponse vous a-t-elle été utile ?
Les RI/GAM actuellement déployées dans le cadre du Ségur doivent proposer une interface interopérable (sous la forme de message HL7 ADT, format IHE PAM – National extension France). La version minimale de HL7 est la 2.3.1 sans le segment PID, version préconisée avec le PID v2.5.1 ) avec les autres logiciels. Le DMN est responsable de s’interfacer au moins avec ces interfaces.
Cette réponse vous a-t-elle été utile ?
Comme noté à la page 14 du référentiel 1.2.2 : « Le Référentiel d’Interopérabilité et de Sécurité des Dispositifs Médicaux Numériques (DMN) exige une méthode d’authentification des usagers à 2 facteurs. Le Système doit donc implémenter cette méthode d’authentification (exigence IEU 9.1). » Le développement de la double authentification est donc obligatoire pour un DMN s'il y a un accès patient, et c’est une exigence qui sera vérifiée par l’ANS.
Par contre, il est également indiqué : « Pour tenir compte du cas où l’activation de l’authentification des usagers à 2 facteurs diminue l’usage de la solution et entraîne une perte de chance pour l’usager, le fabricant du DMN peut sous sa responsabilité ne pas activer systématiquement l’authentification à deux facteurs. ». Cela signifie que l’activation du double facteur peut ne pas être systématique pour l’ensemble des patients. Ce point est de la responsabilité de l'entreprise du numérique en santé développant le DMN.
Enfin, il est précisé dans le scénario IEU 9.1 : « L'accès du patient à une interface de déclaration simple dans le cadre d'un parcours de télésurveillance n'est pas soumis à ce scenario de conformité et ne nécessite pas d'authentification à deux facteurs systématique. » . Cela signifie que dans le cadre d’une déclaration simple, c’est-à-dire dans le cas où un patient accède à un simple formulaire de saisie de données (hors du DMN), il n’est pas soumis au développement du double facteur.
Cette réponse vous a-t-elle été utile ?
Le référentiel d’identification électronique se borne à faire en sorte que les identifiants utilisés pour les usagers soient des identifiants uniques et sectoriels de préférence. Il n'existe aujourd'hui aucune exigence qui encadre ce cas de figure, même si la qualité de l’identification d’un usager est l’un des principes fondamentaux de la qualité et de la sécurité de sa prise en charge.
Cette réponse vous a-t-elle été utile ?