Dans le cadre du financement « SONS », la clause de portabilité « doit permettre la mise à disposition des données dans un délai de 15 jours calendaires à partir de la demande formelle du Client final, sans surcoût pour ce dernier. Le Client final peut effectuer cette demande par écrit, dans un espace client, ou directement dans le logiciel. ». L’éditeur doit alors transmettre à son client tous les éléments nécessaires pour réaliser l’export manuellement (activation de la fonctionnalité, documentation utilisateur…) ou procéder lui-même à l’export si la fonctionnalité n’est pas activable par l’utilisateur, sans facturation sur le périmètre défini dans le cadre de l’Appel à Financement (§4.5). 

Cette clause « doit pouvoir être actionnée par le Client final au moins une fois par an, et au changement de fournisseur. » 

Cette obligation n’inclut pas de prestation d’accompagnement ou de support visant à adapter le format de fichier ou à extraire des données de nature différente, par exemple des données de facturation.

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.

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.

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".

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).

Les alertes d’hypoglycémie sévère doivent être générées en fonction d’une fréquence d’émission (c’est à dire en fonction d’un nombre d’alertes dans un temps donné) en plus d’un dépassement de seuil. 

Par exemple, il faut que le niveau d’alerte d’hypoglycémie soit dépassée 3 fois en 1 journée pour que l’alerte d’hypoglycémie sévère soit déclenchée. Ce sont ces données qui doivent pouvoir être paramétrable par le PS, l’objectif étant d’éviter les alertes non significatives.

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")

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")

Les règles de nommage des versions référencées Ségur sont détaillées dans le slide ci-dessous

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).

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.

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

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.

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.

Si un système de télésurveillance/DMN est Référentiel d’identité et qu’il n’a pas besoin de consommer ou de diffuser l’identité au sein du même domaine d’identification, alors l’exigence INS 45 du référentiel des DMN peut être « Non Applicable » (l’Entreprise du Numérique en Santé doit alors à minima fournir une déclaration sur l’honneur que le système ne reçoit pas d’échanges pour la gestion de l’INS, à la place des preuves INS 45 exigées).

Il n'y a pas d'obligation à être certifié conforme au référentiel de l'ANS pour commercialiser le dispositif médical numérique marqué CE. La certification est obligatoire pour prétendre à un remboursement par l'Assurance Maladie.

Le dispositif médical numérique, esclave de l'identité, doit recevoir l'INS des patients (via la réception d’un message HL7 V2 transmis par la GAM).

Dans le référentiel d'interopérabilité et de sécurité des dispositifs médicaux numériques, c'est la transaction IHE PAM FR avec un message HL7 ADT qui est exigée. Actuellement les établissements de santé ont développé des flux HL7 V2, plutôt que la communication de bundle ou de ressources FHIR.

Oui, l'exigence d'interopérabilité INS45 de consommation de l'identité est obligatoire pour tous les systèmes de télésurveillance, y compris si vous implémentez la connexion au téléservice INSi.

Oui, comme chaque DMN est avec IHE PAM FR, consommateur de l’identité, il devra recevoir de la GAM un message HL7 V2 ADT pour la création, modification ou suppression de l’identité d’un patient.