FAQ de l'offre : Ségur du numérique en santé

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.

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)

Le 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 solde, 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 prestation 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és 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. 

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

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.

1. Quel est le changement principal ?

   Avant : Tout système proposant un mot de passe comme facteur unique d’authentification devait limiter le nombre de tentatives d’accès et appliquer des critères de construction assurant un niveau suffisamment élevé de complexité des mots de passe des PS.

   Maintenant : Cette exigence s'applique uniquement à un système configuré avec la base de compte locale. Lorsque le système ne dispose d’aucune fonctionnalité de gestion de comptes utilisateurs locaux (création, stockage ou vérification de mots de passe) et que l’authentification est entièrement déléguée à un fournisseur d’identité externe (exemple : AD), l’exigence SC.SSI/IE.36 est non applicable.

   Ce changement est lié au fait que la rédaction initiale de l’exigence ne prenait pas en compte des cas d’usage remontés durant la procédure de référencement.

    

2. Concrètement, qu'est-ce que ça implique ? 

   L'éditeur peut déposer un justificatif expliquant les particularités de développement de l’application et indiquant qu’il n’existe aucune fonctionnalité de base locale de comptes.

    

3. Quelles obligations pour l’éditeur ?

   Aucune, il s’agit d’une prise en compte de cas d’usage existants.

    

Annexe – Nouvelles versions exigences, scénarios et preuves

Nouvelle version de l’exigence SC.SSI/IE.36

LORSQUE le système propose un mot de passe comme facteur unique d'authentification, ALORS le système DOIT : 

• permettre d'implémenter les mesures de restriction d’accès et de vérification de complexité des mots de passe prévues par le Référentiel d'identification électronique (volet ASPP) ;
• être conforme à ces exigences dans sa configuration par défaut.

NB : les administrateurs techniques ou métier ne sont pas concernés par cette exigence

Le système peut généralement se baser :

• soit sur une base de compte locale
• soit sur un annuaire (exemple AD)

Cette exigence s'applique à un système configuré avec la base de compte locale.

Nouveau scénario associé à l’exigence SC.SSI/IAM.36

SC.SSI/IE.36.01 :

Vérifier que le système limite le nombre de tentatives d'accès par mot de passe.

Etapes du scénario :

1. Demander l'ouverture d'une connexion par mot de passe en tant que PS sur un compte valide
2. Entrer un mot de passe incorrect plusieurs fois consécutives
3. Montrer que le système empêche de réaliser un nombre illimité de tentatives (temporisations, blocage préventif du compte...) ou qu'il requiert la complétion d'un captcha à chaque authentification

SC.SSI/IE.36.02 :

Vérifier que le système applique les critères de construction du mot de passe du compte du PS.

Etapes du scénario :

1. Demander la modification ou la création du mot de passe d’un compte de PS   
2. Entrer un mot de passe de 8 caractères composé uniquement de minuscules et de majuscules
3. Montrer que le système refuse ce mot de passe
4. Entrer un mot de passe de 8 caractères composé uniquement de minuscules et de chiffres
5. Montrer que le système refuse ce mot de passe
6. Entrer un mot de passe de 8 caractères composé uniquement de minuscules et de caractères spéciaux
7. Montrer que le système refuse ce mot de passe
8. Entrer un mot de passe composé de 14 chiffres uniquement
9. Montrer que le système refuse ce mot de passe

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.