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.

La doctrine du numérique en santé identifie plusieurs référentiels de données qui chacun portent une finalité distincte :

• le RPPS étendu (ou RPPS+) afin de porter l'identification de toutes les personnes physiques dans leur rôle d'acteur de santé (tout type de professionnel ou assistant du secteur) ;
• le FINESS refondu (ou FINESS+) afin de porter l'identification de toutes les personnes morales de santé (tout établissement et entité juridique du secteur) ;
• le ROR afin de décrire l'offre de santé au sein d'un établissement (spécialités, capacités) ou d'un cabinet.

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. 

Il existe plusieurs niveaux d’exigences pour l’intégration d’un module au Système d’Information Hospitalier (SIH). Les exigences principales du référentiel de néonatologie concernent : 

• les principes généraux d’interfaçage, de contrôle et de sécurité ; 
• les exigences faisant référence au processus de prescription ; 
• les exigences relatives à l’intégration avec un thesaurus national de prescription ; 
• les exigences concernant le pilotage médico-économique et décisionnel ; 
• les exigences d’ergonomie, fonctionnelles, et correspondant aux alertes et notifications ; 
• les exigences correspondant aux fonctions de paramétrage. 

Au total, 139 exigences servent à considérer un niveau minimal d’intégration du module avec le SIH. Le respect de ce niveau minimal par l’établissement permet de faire porter les exigences générales de sécurité et de traçabilité sur le SIH, et non sur le module lui-même. 

Le référentiel actuel, publié en 2017, a été conçu avec des experts du secteur. Il présente le contexte particulier dans lequel s’inscrit la mission de l’ANS et des objectifs à atteindre pour renforcer la sécurité des activités de néonatologie et réanimation pédiatrique.  

Le référentiel vous guide à travers les différents concepts et fondamentaux utilisés pour appréhender les protocoles et les exigences liés au développement de logiciels, en particulier concernant l’aide à la prescription en milieu hospitalier. 

La néonatologie est une activité à haut risque pour deux raisons :  

• la fragilité des patients traités (des bébés prématurés) ; 
• les médicaments administrés – près de 50% le sont hors AMM (autorisation de mise sur le marché). 

Des accidents survenus en services de réanimation en néonatalogie1 ont conduit la Direction Générale de l’Offre de Soin (DGOS) à réaliser une analyse du circuit du médicament. Initiée en janvier 2014 en lien avec les sociétés savantes2, elle mène un état des lieux des pratiques dans ce domaine. 
 
Le rapport de l’Inspection générale des affaires sociales3 (IGAS) alerte d’un risque non maitrisé sur l’ensemble du circuit du médicament en néonatologie. L’informatisation de la prescription figure parmi les 41 préconisations de l’IGAS visant à augmenter le niveau de sécurité de cette activité. 

Cette ligne directive est donc une des priorités de l’ANS dans la numérisation des services santé. 

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 

Le terme échange désigne tout ce qui est en lien avec les services de messagerie : les données transitent vers une ou plusieurs destination(s) identifiée(s).

Le terme partage regroupe les activités de stockage des données et la gestion des accès à celle-ci : les données sont à un seul endroit et sont consultées par plusieurs acteurs non identifiés lors de la mise en partage (contrairement à l’échange avec plusieurs destinataires).

La certification remplace l’agrément.

Elle repose sur un référentiel et une procédure de certification :

• un organisme certificateur procède à l’évaluation de la conformité au référentiel ;
• il délivre un certificat de conformité pour une durée de 3 ans.

Les dossiers de demande d’agrément déposés avant le 31 mars 2018 sont instruits selon l’ancienne procédure.

Un identifiant calculé (INS-C), attribué au travers d’un algorithme à partir d’informations lues à partir de la carte Vitale de l’assuré, a d’abord été utilisé de façon transitoire dans l'attente de l'évolution des textes permettant l'utilisation d'un identifiant adapté.

L'évolution des textes permet aujourd’hui la mise en œuvre de l’INS (Identité Nationale de Santé). L’INS-C est donc remplacé par l'INS c'est à dire le NIR et les cinq traits d'identité qualifiés (nom de naissance, prénom(s), date de naissance, sexe, lieu de naissance).

Votre dossier de candidature, dûment rempli et signé, doit être complété avec les documents suivants : 

• le règlement du label, qui décrit les étapes du processus de labellisation ayant lieu avant l’octroi du label SI commun MDPH ;
• la convention relative à l’utilisation du label SI commun MDPH, qui encadre les étapes et activités ayant lieu après octroi du label. Y sont présentés, par exemple, les obligations liées à la labellisation, les visites d’audit, les cas de modification du label, etc.
• les annexes à la convention relative à l’utilisation du label SI commun MDPH :
  • le plan assurance sécurité de la vérification de conformité du label « SI commun MDPH » ;
  • la Licence d’utilisation de la solution labellisée ;
  • les décisions éventuellement délivrées par les organismes partenaires en charge des flux d’échange : CNAF / SNGI, Imprimerie Nationale, etc. afin d’attester de la bonne mise en œuvre des flux correspondants.

Les éléments clés sont mis à votre disposition par l’ANS. Téléchargez les dans notre espace Documentation.

Le dossier est à envoyer par courriel ET par voie postale : 

• Agence du Numérique en Santé
  Labellisation logiciels Maisons Départementales des Personnes Handicapées
  9 rue Georges Pitard 75015 Paris
• labellisation.mdph@esante.gouv.fr

Ces documents sont mis à votre disposition par notre partenaire, la CNDA, et sont téléchargeables au format ZIP

Le but des travaux menés par l’ANS est de constituer un référentiel fonctionnel pour le module applicatif. Cela correspondant, en tout ou en partie, à une solution logicielle, commercialisée par une société ou produite par un établissement de santé, permettant la gestion du processus de la prescription à l’administration en réanimation pédiatrique et néonatologie.