Non. Le bon de commande doit impérativement faire figurer le montant réel, non nul, de la Prestation Ségur. La prise en charge par l'Etat doit être indiquée par la mention « Montant pris en charge par l’Etat au titre du Ségur de la santé » visible sur le bon de commande.  

En particulier, au moment de la demande de solde, une copie de la facture faisant apparaître un montant total de la Prestation Ségur à 0€ sera systématiquement rejetée.

Conformément au cadre réglementaire des dispositifs SONS du Ségur du numérique en santé, chaque établissement et professionnel de santé (ES/PS) éligible ne peut bénéficier que d’un seul financement par SONS, c’est-à-dire un seul financement de mise à jour pour un type de logiciel donné.  

En conséquence, toute demande de financement portant sur un / des bénéficiaire(s) ayant déjà fait l’objet par ailleurs d’une demande validée par l’Agence de services et de paiement fera l’objet d’un rejet. 

En cas de contestation par l’éditeur ayant vu sa demande rejetée, l’ASP contactera par courrier électronique les deux éditeurs concernés, pour qu’ils apportent sous dix jours ouvrés les précisions nécessaires (maintien de leur demande initiale ; information d’une erreur commise dans le périmètre couvert par la demande initiale et demande de modification en conséquence ; retrait de leur demande de financement, etc.), selon des modalités précisées dans le message ASP. 

S’il s’agit d’un établissement ou professionnel de santé ayant signé deux bons de commande distincts sur le même périmètre logiciel : les éditeurs devront faire valider par l’établissement ou le professionnel concerné l’identité de l’éditeur avec lequel il souhaite bénéficier de la Prestation Ségur, et le signaler auprès de l’ASP. Il appartiendra alors à l’éditeur voyant sa commande annulée de tirer les conséquences d’une éventuelle rétractation directement auprès de l’établissement ou le professionnel de santé. 

En cas de non-réponse, ou lorsque les réponses apportées ne permettraient pas de statuer sur le dossier, l’Agence du Numérique en Santé se réserve le droit de procéder à toute vérification utile, et au besoin à demander l’annulation des demandes de financement concernées. 

Pour annuler votre demande de financement vous devez contacter le support utilisateur de l'ASP en fournissant : 

 i. une attestation sur l’honneur signée et motivée de votre part si l'annulation est de votre propre chef, pour une erreur effectuée lors de la demande ;

ii.  une attestation sur l'honneur signée et motivée de votre part et une attestation de renonciation du client si l'annulation est en accord avec le client ES/PS. 

Après vérification du périmètre de l'annulation par rapport au périmètre initial et de l'avance perçue le cas échéant : 

Cas 1 : Demande d'annulation de la totalité de la demande de financement concernant le ou tous les bénéficiaires du périmètre initial pour un éditeur ayant déjà perçu l'avance 

• l’ASP annule la demande de financement ;
• l’éditeur rembourse l’avance perçue.

Cas 2 : Demande d'annulation partielle de la demande de financement concernant un ou plusieurs bénéficiaires du périmètre initial pour un éditeur ayant déjà perçu l'avance 

• réouverture et modification de la demande de financement par l'ASP pour supprimer le ou les bénéficiaires OU Annulation par l’ASP et dépôt d’une nouvelle demande sur le bon périmètre par l’éditeur ;
• une régularisation du trop-perçu est effectuée par l’ASP au moment du solde.

Cas 3 : Demande d'annulation de la totalité de la demande de financement concernant le ou tous les bénéficiaires du périmètre initial pour un éditeur n'ayant pas perçu l'avance 

• l’ASP annule la demande de financement.

Cas 4 : Demande d'annulation partielle pour un ou plusieurs bénéficiaires du périmètre initial pour un éditeur n'ayant pas perçu l'avance 

• avant le 17/11 : Rejet par l’ASP et dépôt d’une nouvelle demande sur le bon périmètre par l’éditeur ;
• à partir du 17/11 : Modification de la demande de financement pour suppression du ou des bénéficiaires.

Des modèles d'attestation sont disponibles auprès de l'ASP. 

Pour contacter l’Assistance Utilisateur de l’ASP : https://segurnum.asp-public.fr/segurnum/contacter-assistance 

La demande de solde doit être conforme et introduite sur le même périmètre que la demande d’avance auprès de l’ASP. Cependant :

• si un ou plusieurs clients sont soustraits du périmètre de la demande d’avance, la demande de solde est recevable. Une compensation du montant versé lors de l’avance pour ce(s) client(s) sera effectuée au moment du solde. 
• si un ou plusieurs clients sont ajoutés au périmètre de la demande d’avance, alors cette demande sera rejetée par l’ASP. Il faudra donc :
  • modifier la demande de solde par un périmètre correspondant à la demande d’avance ou inférieur à celle-ci (si inférieur, une compensation du montant versé lors de l’avance pour ce(s) client(s) sera effectuée au moment du solde.)
     
• si le périmètre est modifié en raison de l’évolution administrative d’un bénéficiaire (fusion, scission, etc.), cette demande sera acceptée par l’ASP à condition que : 
  • le JSON solde comporte les identifiants historiques (A et B) de l’avance au nouveau bloc « bénéficiaires »
  • en complément au JSON solde, le fournisseur mentionne les bénéficiaires historiques ainsi que le nouveau bénéficiaire dans les documents de gestion. A cet effet, il faut joindre à la facture (dans le même document PDF), un traité de fusion. Ce document est mis à l'initiative du fournisseur, lors du dépôt de sa demande.

Ainsi, si A et B à l’avance, et que B est devenu C entre l’avance et le solde, le fournisseur devra fournir ce justificatif au moment de la demande de solde à l’ASP.

• Critère 1 : Terminologie conçue par une Unité de Production de l’ANS
• Critère 2 : Terminologie conçue par une Unité de Production avec laquelle un conventionnement est en place
• Critère 3 :Terminologie en usage
• Critère 4 : Terminologie compatible avec le droit qui s’impose à l’ANS
• Critère 5 : Terminologie de référence
• Critère 6 : Terminologie "ouverte"
• Critère 7 : Maturité de l’Unité de production en charge de la conception et de la maintenance de la Terminologie
• Critère 8 : Terminologie ancillaire locale / "petites Terminologies"
• Critère 9 : Terminologie conçue par une Unité de Production "fragile" / Terminologie conçue par une Unité de production ne disposant pas d’un point de distribution.

L'exigence IRESP 9 issue des spécifications techniques minimales de la Haute Autorité de Santé s'applique seulement aux DMN de télésurveillance pour les patients sous Ventilation Non Invasive (VNI). Cette exigence est donc considérée "Non Applicable" pour votre DMN.

En cas de non applicabilité, une déclaration sur l'honneur justifiée devra être fournie à la place de la preuve attendue. 

L'exigence IRESP 10 issue des spécifications techniques minimales de la Haute Autorité de Santé s'applique aux DMN de télésurveillance pour les patients sous oxygénothérapie ou Ventilation Non Invasive (VNI). Cette exigence est donc obligatoire pour votre DMN.

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, sur la page https://www.asp-public.fr/aides/segur-du-numerique-en-sante-financement-lequipement, 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. 

Le principe général est qu’il ne peut y avoir de refus de signature d’une VA attestant de la réalisation d’une Prestation Ségur pour une solution logicielle A, au motif de l’indisponibilité ou de 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 éventuellement nécessaires une fois que les vérifications auront pu être menées par l’Etablissement de Santé. Les éventuelles réserves jugées non bloquantes par l’ES peuvent être inscrites sur la VA dans l’encadré commentaires, elles seront sans traitement par l’Opérateur de paiement. 

La procédure d’obtention du label SI commun MDPH est ouverte à toute personne morale propriétaire d’une solution logicielle destinée aux Maisons Départementales des Personnes Handicapées (MDPH). Celle-ci inclut les MDPH qui développent leurs propres solutions conjointement avec les Conseils Départementaux avec lesquels elles sont liées.

La labellisation est une démarche volontaire. Chaque candidat peut s’engager dans le processus s’il estime que sa solution est conforme aux exigences et au périmètre du référentiel fonctionnel (RF) en vigueur à la date d’octroi du label 

Un éditeur de logiciel santé & social intègre généralement plusieurs Terminologies couvrant les cas d’usages "de base" : noms et codes des communes, noms et codes des langues, des pays…

Il intègre ensuite généralement des "Terminologies socle" (Terminologie de médicament, de DM, de facturation, administratives…) puis des Terminologies spécifiques à son métier (Terminologie du vivant, Terminologie spécifique à la cardiologie, à la gériatrie…).

Il en existe beaucoup : CIM-10, la CIM-11, la CCAM, ADICAP, Cladimed, Medicabase, la SNOMED 3.5VF, LOINC, MedDRA, ISO IDMP, EphMRA, ATC, CIS, CIP, UCD,…

Pour toutes vos questions (SMT et terminologies médicales) : ans-terminologies@esante.gouv.fr 

Utilisées aussi bien entre machines, entre humains et entre humains et machines, les ressources sémantiques constituent un langage et un bien commun. Elles sont le socle nécessaire à la dématérialisation de disciplines telles que la production et la coordination des soins, la recherche médicale ou le pilotage médico-économique.

Une unique Terminologie ne pourra pas être en mesure de couvrir l’ensemble des domaines et des cas d’usages de la Santé, : chaque domaine étant administré par une communauté d’experts, et de nouveaux domaines pouvant être révélés régulièrement, des Terminologies "spécifiques" seront toujours nécessaires.

De nombreuses terminologies sont constamment créées et ne sont pas contrôlées. Le CGTS n’en a pas connaissance et ne peut pas les intégrer dans le SMT.

De plus, le catalogue actuel est basé sur les terminologies utilisées au sein du CI-SIS. Et c’est la gouvernance des terminologies de santé qui décide des terminologies à publier par le SMT.

Une ontologie est le produit de l’ingénierie de la connaissance. C’est le type de ressources sémantiques le plus complet (présence de liens entre concepts, présence de synonymes, possibilités de raisonnement…). Il est décrit dans l’annexe bibliographique de l’"étude DNS".

Le programme de labellisation des Centres et Maisons de santé, créé pour organiser la montée en gamme des logiciels tout en répondant aux besoins d’exercices interdisciplinaires des MCS, s’accompagne d’un cahier des charges basé sur l’ISO 10781 "Modèle fonctionnel d’un système de dossier informatisé de santé". Ce cahier des charges évoque la CISP-2 (soins primaires) pour "capturer les facteurs de santé", la CIM-10, la CISP-2 ou le DRC pour "coder un problème" ou pour "exploiter les données". Les logiciels doivent pouvoir afficher à l’utilisateur la "table de transcodage" vers la CIM-10.

CCAM n’est pas publiée dans un format ontologique standard mais c’est une des seules ontologies formelles utilisée en France ;

HPO (génétique), ORDO (maladies rares) sont des ontologies. De même, quelques Terminologies ad-hoc telles que celles construites sur la base de Menelas (OntoMenelas, OntolUrgence), OntoParon sont des ontologies.

Le nombre de Terminologies en usage ne fait et ne fera que croître, suivant la progression du savoir et des domaines de connaissance nouveaux à couvrir. Afin de favoriser l’interopérabilité, l’Etat peut se doter de "doctrine" instaurant par exemple un principe de non-prolifération des Terminologies, principe qui viserait à éviter de préconiser plusieurs Terminologies pour un domaine de connaissance donné.

L’interopérabilité est la capacité que possède un produit ou un système, dont les interfaces sont intégralement connues, à fonctionner avec d’autres produits ou systèmes existants ou futurs et ce sans restriction d’accès ou de mise en œuvre.