Le numéro RRPS doit être utilisé lorsqu’il existe. Lorsqu’il n’existe pas et qu’un autre numéro national est disponible, l’utilisation de cet autre numéro est tolérée. 

Le système désigne le LGO donc la visualisation doit se faire au travers du LGO. En revanche, comme il s'agit d'une préconisation, le développement de cette fonctionnalité n'est pas obligatoire pour le référencement vague 1. Elle le deviendra pour la vague 2.

Le montant de la facture transmise au client et à l'ASP en fin de projet doit correspondre au montant total (100%) - la partie "Prestation Segur" doit être reportée dans le JSON et doit être inférieure ou égale au montant déclaré lors de l'avance (dépôt du dossier).

Pour plus d'informations, veuillez vous référer à la partie "4.4 Conditions relatives à la réalisation de la Prestation principale" de l'Appel à Financement (AF) de votre dispositif.

Nous nous situons au niveau local avec répercussion sur le DMP et la MS Santé comme pour le cas d'une modification. Si le document est supprimé uniquement dans le DMP et pas en local (ex : le patient fait la suppression lui-même), il n’y a pas besoin d'informer les destinataires MS Santé.

Pour rappel, le pharmacien ne peut pas supprimer ou modifier directement un document dans le DMP, il doit le faire depuis son LGO pour répercuter ensuite la mise à jour ou la suppression dans le DMP. Ceci assure une synchronisation entre DMP et logiciels métiers.

Vous devez demander le raccordement à Pro Santé Connect en remplissant le formulaire dédié, disponible ici.

Non, les exigences sont structurées en éléments de preuve distincts, qui doivent être déposés séparément, à leur emplacement respectif sur la plateforme Convergence, et ce en respectant les formats imposés.

Après certification, le CNDA remet à l’éditeur :

• L'attestation de conformité ;
• La lettre de référencement.

L’éditeur utilise ensuite l’attestation de conformité comme preuve de certification auprès de l’ANS.

Vous trouverez ci-dessous un exemple d'attestation de conformité :

Image

L'export des données doit être réalisé sous un format standard, structuré et/ou non structuré, au choix de l’éditeur (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 doit être paramétrable dans la procédure. Le format des fichiers mis à disposition doit être lisible, exhaustif, exploitable, et documenté par l’éditeur.

Nous vous invitons à vous référer au DSR de votre couloir au chapitre 3.2.

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.

Le Code officiel géographique (COG) utilisé est bien issu des fichiers officiels INSEE. Certains cas de tests incluent des communes supprimées pour illustrer des cas réels d’historique administratif. 

Si l’éditeur constitue une base locale des COG, il doit impérativement l’alimenter et la maintenir à jour à partir de l’ensemble des fichiers disponibles sur le site de l’INSEE (communes actuelles, événements, COG complet).

Les éléments justificatifs doivent être fournis par l'entreprise à l'ASP (Agence des Services de Paiement), via le formulaire dédié.

L’éditeur doit impérativement fournir les informations CNDA suivantes :

• Numéro d’Identification Éditeur (NIE) délivré par le CNDA
• Numéro d’Identification Logiciel (NIL) délivré par le CNDA

Le Numéro de version technique du logiciel est l’identifiant unique de la solution. Il présente obligatoirement les caractéristiques suivantes : 

• Le Numéro de version technique est aisément accessible à l’utilisateur dans l’IHM (Interface HommeMachine) du logiciel, 
• Le Numéro de version technique doit évoluer dès qu’un élément du code source est modifié, y compris un simple patch,
• La succession chronologique des versions techniques doit être clairement compréhensible au travers d’une numérotation alphanumérique

Pendant l’instruction du dossier, une phase d’échanges entre l’ANS et l’Editeur peut être nécessaire afin d’apporter des précisions sur les éléments de preuves fournis par l’Editeur. Dans ce cas, l’ANS peut être amenée à solliciter l‘Editeur via l’outil de gestion des candidatures.
A noter que passé 5 jours sans réponse de l’éditeur, un retard important sur l’instruction du dossier est à prévoir.

Oui, dans le cas où un éditeur commercialise plusieurs solutions logicielles couvrant des périmètres fonctionnels relatifs aux DSR, il peut solliciter des référencements pour chacune de ces solutions logicielles en déposant autant de candidatures que de solutions  logicelles à référencer.

Une solution logicielle est constituée d’un Composant principal, d’un Composant Proxy esanté, et éventuellement complété d’un ou plusieurs Composants additionnels intégrés dans une version majeure identifiée et référencée par l’ANS. Au sein du présent document, sauf mention spécifique, le terme Solution logicielle désigne donc l’ensemble constitué du Composant principal, du Composant Proxy e-santé, et du ou des éventuels Composants additionnels.