FAQ des industriels

Il s’agit d’une lettre dans laquelle vous attestez répondre aux critères d’éligibilité décrits dans la section 2.1 du DSR. Il convient, pour chacun des critères listés de décrire en quoi la solution logicielle y répond (par exemple sur la base d’une documentation produit, de captures d’écrans ou tout autre élément attestant de cette éligibilité).

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

Si le système utilise l’API FHIR pour récupérer les données annuaire de santé, il est nécessaire d’avoir , en plus des preuves énumérées en ANN.1.1.1, une description du process es différents appels à l’API effectués (mode DELTA, FULL, unitaire) : à quel moment ces appels sont faits, à quelle fréquence le cas échéant. 

De même pour la preuve ANN.2.1.2, en plus de la vidéo montant la recherche des données annuaire dans le service, il sera nécessaire de fournir les logs des appels API nécessaires à cette recherche.

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.

Dans le cadre d'une candidature PCI, il est considéré comme conforme que le DMN propose de suspendre temporairement les alertes de non-transmission de données, à condition que cette suspension soit limitée à une période spécifiquement définie, qu’elle soit utilisée à des cas d’usage spécifiques et justifiés, et que la réactivation des alertes se fasse de manière automatique à l'issue de cette période.

Si vous effectuez un montage (utilisation d’une solution tierce déjà certifiée), vous n’avez pas à effectuer de demande de certification auprès du CNDA. Vous pouvez communiquer à l'ANS le NIL de cette solution tierce lors de votre demande de référencement.

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

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

Les travaux en cours et à venir sont détaillés sur la frise ci-dessous. Pour plus d'informations, n'hésitez pas à télécharger le "Pack discussion Ségur Vague 2", disponible sur notre site internet : https://industriels.esante.gouv.fr/segur-du-numerique-en-sante/segur-vague-2

Non, cela n'est pas nécessaire : un seul formulaire 413 est suffisant pour commander les certificats DMP et INSi. Il vous faut cocher la case "Certificat ORG (personne morale)", puis indiquer dans la case "Précisions sur l’usage des certificats et sur votre projet" les informations suivantes:

DMP: authentification et signature sur le DMP ;
INSI: authentification sur les TLS INSi.

 En effet, les prescripteurs peuvent parfois disposer d'une BAL nominative (adresse MSS personnelle) ainsi que d'une BAL organisationnelle (boite de service, pouvant être utilisée par plusieurs professionnels
d’un même service). Dans ce cas, il convient d'enregistrer les deux correspondants : le prescripteur et le service ou établissement.

Le nombre de BAL pris en compte dans le calcul du financement est celui déclaré à la date fixée dans le contrat Opérateurs.

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

Opérateur Développeur : désigne un Opérateur MSSanté qui développe et met en œuvre (le cas échéant avec l’aide d’un sous-traitant) pour lui-même ou pour le compte d’Opérateurs Acheteurs les composants spécifiques aux exigences MSSanté (exemple : connecteur MSSanté).

Opérateur Acheteur : désigne un Opérateur qui a recours à la technologie d’un Opérateur Développeur (disposant d’un contrat Opérateur MSSanté signé avec l’ANS) en lui achetant les composants techniques tels que le connecteur MSSanté (ex : les établissements sanitaires Opérateurs MSSanté qui achètent leur connecteur MSSanté auprès d’un Opérateur MSSanté tiers).

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.

Concernant les DOM-TOM, les départements et régions d’outre-mer sont bien pris en compte dans le dispositif Ségur : Réunion, Martinique, Guadeloupe, Guyane, Mayotte.

Les collectivités d’outre-mer (la Polynésie française, Saint-Barthélemy, Saint-Martin, Saint-Pierre-et-Miquelon et Wallis-et-Futna) ne sont pas régies par le dispositif de l’accord national des CDS et ne sont donc pas conventionnés.  Elles relèvent d’un autre régime d’Assurance Maladie.

Pour l’ensemble de ces raisons, elles ne sont pas prises en compte dans le dispositif Ségur. 

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.

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.

Le référentiel d’imputabilité définit les moyens utilisables pour :

• assurer la traçabilité des actions réalisées vis-à-vis d’un SI de santé ;
• garantir la valeur des traces enregistrées ;
• contrôler l’usage fait de ce SI de santé.

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.