Questions fréquentes

Oui. Il doit pouvoir :

• intégrer ou non chaque information,
• compléter ou modifier les données après intégration,
• éventuellement ajouter des commentaires.

Aucune obligation de transcodage automatique entre référentiels (ex. diabète type 1 codé différemment).

Non. La modification peut intervenir, soit dans l’interface d’intégration, soit ultérieurement dans le dossier patient. Le principe est que la donnée ne soit pas figée.

Les listes d’équivalence seront publiés en même temps que les textes réglementaires notamment les Référentiels d'Exigences Minimales (REM). Une fois les textes publiés, ces documents sont disponibles sur le Portail de la esanté des Entreprises du Numérique en Santé dans la rubrique "Documentation" volet "La procédure de Référencement" des différents couloirs / dispositifs. 

L'exigence a été mise en place pour éviter la duplication des comptes utilisateurs.

Dans le cas de multisites, il est possible de rajouter d'autres attributs (Nom de l'établissement, Identifiant de la structure ...) qui permettraient d'empêcher la duplication au sein d'un même établissement tout en permettant à un même professionnel de santé de disposer de comptes au sein de différentes structures.

La vérification de la complexité d’un mot de passe ne peut être constatée qu’au moment de sa création ou de sa modification.

Pour démontrer la conformité à l’exigence :

• accéder à une fonctionnalité permettant la création ou la modification d’un mot de passe ; 
• proposer des mots de passe dont l’entropie est inférieure à 27 bits et vérifier qu’ils sont refusés par le système.
  Les exemples de mot de passe faibles peuvent inclure : 
  • des mots de passe trop courts (moins de 8 caractères) ; 
  • des mots de passe constitués uniquement de chiffres ou uniquement de lettres.
• proposer un mot de passe respectant les règles de complexité (entropie supérieure à 27 bits) et vérifier qu’il est accepté par le système. 
   

IEPS 02 - Enoncé de l'exigence :

Le Système DOIT vérifier, à la création d'un compte, l'adresse de messagerie ou le numéro de téléphone du PS lorsque ces informations sont utilisées dans les mécanismes d'authentification ou de récupération de son compte.

Scénario - vérification de contrôle des coordonnées de messagerie ou téléphoniques : 

• déclarer un compte en saisissant une adresse de messagerie utilisée pour l'authentification ou la récupération du compte ; 
• vérifier que le système contrôle la validité de l'adresse de messagerie par l'envoi d'un lien unique ou d'un compte à cette adresse.

Il est nécessaire d'afficher l'adresse de messagerie aussi bien lors de la saisie à la création du compte, que lors de la réception du mail d'activation afin d'en prouver la correspondance.

De même, si le système utilise le numéro de téléphone lors du processus d'authentification ou de récupération de compte, il sera nécessaire de prouver la conformité au scénario 2 et la correspondance du numéro de téléphone saisi sur le système avec le numéro de téléphone sur lequel est reçu le code OTP.

Il correspond aux modèles publiés sur Ameli pour les prescriptions de soins infirmiers. Les éditeurs doivent s’aligner sur ces modèles (injections, pansements, etc.). Le champ permet de structurer conformément aux attendus métier.

Le LGC doit gérer les codes retour techniques du téléservice INS. En revanche, il n’existe pas de jeu de codes techniques normé pour l’Application Carte Vitale à stocker comme tel. Le LGC doit donc stocker un statut métier de qualification (l’app CV renvoie un statut « identité qualifiée » ou « identité non qualifiée »), tracer la source APCV et stocké l’horodatage et le PS.

Oui. Le caractère « systématique » est porté :

• par l’onglet liste des documents Ségur du REM,
• et indirectement par l’ensemble des exigences liées à l’alimentation automatique du DMP.

Ces exigences concourent à rendre les envois automatiques lorsque les documents existent dans le logiciel.

Le principe de compatibilité ascendante implique que le logiciel, dans sa version candidate au référencement Ségur et souhaitant bénéficier du principe d’équivalence des preuves avec une solution racine référencée (qui peut être soit exactement le même logiciel, soit le même logiciel sous un nom commercial différent, soit un logiciel dont le composant principal est identique à celui du logiciel candidat), doit respecter plusieurs règles :

• la version candidate doit être égale ou supérieure à la version de la solution racine ;
• la version candidate du logiciel doit maintenir la conformité aux exigences Ségur obtenue pour la version de la solution racine.

Par ailleurs, l’article 10 de la convention de référencement précise la responsabilité de l’éditeur de notifier l’Agence du Numérique en Santé si des modifications apportées au logiciel référencé sont susceptibles de le rendre non conforme aux exigences Ségur.

La compatibilité ascendante est également formalisée par la soumission d’une attestation sur l’honneur, fournie selon un modèle ANS disponible sur les pages des dispositifs de la vague 2. Dans cette attestation, l’éditeur déclare que la version candidate respecte les exigences Ségur obtenues lors du référencement de la solution racine