Questions fréquentes

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.

Le « ou » doit être interprété comme un « et » dans le cadre de la conformité.

Les deux scénarios sont attendus :

• appel automatique lors de l’insertion de la carte Vitale
• appel automatique lors de l’ouverture du dossier patient

La présence de deux scénarios de preuve signifie que les deux cas doivent être implémentés et démontrés.

Les codes de lieux de naissance sont historisés côté INSEE. Certaines communes peuvent :

• être fusionnées
• disparaître
• être remplacées.

L’exigence vise à prendre en compte cette historisation.

Si un code ne peut pas être associé à une commune dans le logiciel , il doit être possible pour le médecin de saisir un libellé manuellement, afin notamment de différencier des patients homonymes.

Recommandation d’implémentation

Pour éviter les échecs d’appel aux téléservices (fréquemment causés par un lieu de naissance incorrect), il est recommandé :

• soit de trouver rapidement la commune correcte,
• soit de permettre au médecin de sélectionner « lieu de naissance inconnu » (code 99999).

Cette approche évite les saisies erronées ainsi que les échecs d’appel aux téléservices.

Interface attendue

Même si le lieu de naissance est inconnu, un champ texte libre doit être disponible,
afin de permettre au professionnel de noter un libellé utile à l’identification du patient.

Oui.

Les éditeurs peuvent :

• utiliser les catégories proposées (ex. synthèses, comptes-rendus),
• ou définir leurs propres catégories métier.

Exemple possible :

• catégorie « santé de l’enfant » regroupant comptes-rendus,vaccinations et autres documents pédiatriques.

Ces catégories n’ont pas besoin de correspondre directement aux catégories du jeu de valeurs 66. Les regroupements peuvent également être faits selon d’autres critères :

• métadonnées
• origine du document
• type d’établissement

Oui.

Dans ce contexte, le matricule INS saisi correspond au NIR saisi.

L’objectif est de vérifier la cohérence entre :

• le NIR
• la date de naissance
• le sexe

Cette vérification permet de s’assurer que le message est envoyé au bon patient, notamment lorsque le NIR utilisé est celui d’un ayant droit (ex : facturation).

Logique fonctionnelle attendue

Si  le NIR est cohérent avec date de naissance et sexe :

→ le système peut proposer l’envoi du message.

Si ce n’est pas cohérent :

→ le système doit alerter et empêcher l’envoi.

Cette exigence adresse surtout les problèmes rencontrés avec les prénoms composés.

Exemple du prénom « Jean Christophe Pierre »

Les combinaisons possibles peuvent être :

• Jean
• Jean-Christophe
• Christophe
• Jean Christophe
• Jean-Christophe Pierre

L’objectif est que le logiciel propose des combinaisons plausibles permettant au professionnel de corriger l’interprétation du premier prénom.

Référence

Le cas est précisé dans les commentaires de l’exigence (colonne G du référentiel).

Note

Les situations avec trois prénoms composés sont rares, mais doivent rester gérables.

Les codes 00 / 01 / 02 sont suffisants. Il n’est pas nécessaire de les traduire en OK / KO.