FAQ des industriels

L’éditeur doit impérativement renseigner les informations CNDA suivantes (signalées par un *) dans l’outil de gestion des candidatures :

• Numéro d’Identification Editeur (NIE délivré par le CNDA)
• Numéro d’Identification Logiciel (NIL délivré par le CNDA)
• Attestation de dépôt d'une demande d'obtention des labellisations CNDA (Assurance Maladie)

Oui, l'appel contextuel via PSC du web PS DMP doit obligatoirement être implémenté dans le cadre de la vague 2.

Non, il n’est pas demandé que le logiciel référencé affiche le numéro unique de référencement. En revanche, les noms commerciaux et versions affichés par le logiciel doivent permettre la vérification aisée par l’acheteur du bon référencement de la solution sur le site officiel de l’ANS.

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.

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

Une fois les PV validés, l'ANS publie l'information sur son site internet, confirmant que la solution logicielle a fait l'objet de premières installations réussies (comme précisé dans l'article 6.3 de l'appel à financement correspondant). Le fournisseur peut alors demander le paiement du solde pour les prestations réalisées pour ces établissements ainsi que pour l'ensemble des Prestations Ségur réalisées.
 

Le processus de réalisation et de validation des PV pilotes par l'ANS comprend plusieurs étapes :

- Etablissement des PV -  Pour chaque établissement pilote, un PV post-installation est établi. Ce PV doit être signé par le client, attestant de la bonne réalisation de la prestation Ségur et de la stabilité de la solution logicielle, comme notifié dans le chapitre 6.3 de l'appel à financement correspondant

- Transmission des PV et vérification - Les PV signés sont transmis à l'ASP pour vérification de conformité (chapitre 6.3 de l'appel à financement - insérer le lien). L'ASP examine ensuite les PV pour s'assurer que toutes les exigences et critères de conformité ont été respectés.

- Validation des PV et publication des résultats - Si les PV sont conformes, l'ASP informe le fournisseur de la validation des installations pilotes. L'ANS publie l'information sur son site internet, confirmant que la solution logicielle a fait l'objet de premières installations réussies (comme notifié dans le chapitre 6.3 de l'appel à financement)

Lé périmètre pilote désigne un ensemble de trois établissements de santé sélectionnés par le fournisseur pour valider la stabilité et la conformité de la solution logicielle avant de généraliser la transmission des demandes de soldes, comme spécifié dans le chapitre 6.3 de l'appel à financement correspondant. 

Les demandes de financement et de paiement de l’avance doivent avoir été déposées par le Fournisseur, et validées par l’ASP pour les 3 Clients concernés. Pour justifier du bon déroulé d'une prestations pilote, le fournisseur établit un PV (procès verbal) d'installation pilote qui doit ensuite être transmis à l'ANS qui vérifie sa conformité et informe le fournisseur du résultat de ces contrôles (chapitre 6.3 de l'appel à financement). 

En cas de conformité, l'ANS publiera sur son site internet l'information selon laquelle la Solution logicielle a bien fait l'objet de premières installations réussies. 

Un établissement pilote dans le cadre de la Vague 2 du Ségur est un établissement de santé sélectionné par le fournisseur pour valider la stabilité et la conformité de la solution logicielle. Comme précisé dans le chapitre 6.3 de l'appel à financement correspondant, trois établissements pilotes (par solution référencée) doivent être sélectionnées pour confirmer la stabilité de la solution logicielle. 

Pour être Pilotes, les demandes de financement et de paiement de l’avance doivent avoir été déposées par le Fournisseur, et validées par l’ASP pour les 3 Clients concernés. 

Ce n'est pas exigé dans les fonctionnalités Ségur : c'est au SGL du laboratoire producteur du CR de réaliser cet envoi. Un établissement de santé reste cependant libre d'organiser les flux internes à son SIH selon sa stratégie. 

Les fonctionnalités vague 2 du DPI doivent permettre à un professionnel d'intégrer au DPI tout document présent dans le DMP qui lui semblerait pertinent pour la prise en charge d'un patient. Il peut donc choisir d'intégrer des CR BIO, mais ce n'est pas une intégration systématique.

Non, cela n'est pas interdit. Toutefois dans le cadre des échanges automatisés décrits dans les exigences, seuls sont concernés les CDA.

Les certificats devront être rattachés au FINESS juridique de l'ES, le FINESS géographique étant véhiculé dans le VIHF des transactions DMP.

Néanmoins les certificats peuvent être rattachés aux FINESS géographiques. Dans ce cas il faut des certificats différents pour chaque FINESS géographique.

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

La convention de référencement Ségur stipule que l’éditeur doit pouvoir commercialiser le logiciel référencé au plus tard dans les 2 mois à compter de l’entrée en vigueur de la Convention. La date d’entrée en vigueur de la convention est la date de décision du référencement.

L'éditeur des fonctionnalités de PFI peut être un groupement de solutions : certains éditeurs font référencer une solution en se regroupant avec un ou plusieurs partenaires. Toutefois, dans tous les cas, un seul éditeur porte le référencement et le financement SONS   (tout en déclarant ses partenaires). C'est l'interlocuteur unique de l'ANS et de l'ASP. 

Les logiciels pouvant candidater au programme Ségur doivent répondre aux fonctionnalités décrites dans les DSR (Dossier de Spécifications de Référencements). Toutefois le DSR DPI ne s'adresse pas aux dossiers de spécialité.

Le code d'erreur 905 doit être envoyé (Cf : https://interop.esante.gouv.fr/ig/hl7v2/trans-cda-r2/error-codes.html)

Les contrôles ne sont pas à effectuer par la PFI.
Les logiciels DPI ou RIS doivent comparer l’ensemble des traits d’identités (nom de naissance, 1er prénom de naissance, date de naissance, sexe, code INSEE du lieu de naissance, (liste des prénoms, matricule INS et OID si identité au statut qualifié présente)) du document reçu avec les traits des patients de sa base de données. 

La transmission de données patient à un autre professionnel via MSSanté n'implique pas de disposer d'une identité INS qualifiée. Dans le cas ou l'INS du patient n'est pas qualifiée, le document transmis ne doit pas contenir l'INS et OID.