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

Non, la conservation des justificatifs d’identité INS n’est pas requise. Il n’existe aucune obligation de les stocker, conformément au principe de simplification prévu par le RGPD.

Non, une trace dans les logs de l'appel au téléservice est suffisante. Cette trace est nécessaire, notamment pour l'auditabilité de votre solution.

Oui. Le résultat de l'appel TD0.2 doit être conservé au moins durant la durée de la session. Mais il est recommandé de le conserver durant toute la durée d’ouverture du dossier patient (si il n'y a pas de changement attendu sur ledit dossier). 

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.

Effectivement cette étape du scénario ne sera pas prise en compte dans l’étude des preuves.

1. Quel est le changement principal ?

Lors de la publication des REM RIS et DB, MDV et DCC, le Guide d'implémentation (GI) DMP 2.10 [DMP4] était publié en version release candidate (RC) (pas d'homologation CNDA).
La version du GI DMP 2.9 [DMP5] a donc été pointée dans les exigences.
La publication officielle du GI DMP 2.10 API PSC intégrant toutes ces exigences, cette référence à la 2.9 n’est plus nécessaire et devient source d’erreur pour les candidats.

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

Les exigences concernées qui mentionnent GI DMP 2.9 [DMP5] peuvent désormais être lues comme faisant référence au GI DMP 2.10 – API PSC [DMP4].

3. Quand appliquer ce changement ?

Immédiatement, pour toutes les implémentations, vérifications et homologations en cours ou à venir.

4. Quelles obligations pour l’éditeur ?

Se conformer à la version GI DMP 2.10 – API PSC [DMP4].

L’exigence SC.MSS/va1.15 telle que définie historiquement dans le référentiel client de messagerie MSSanté est erronée depuis sa publication. Elle décrit un mécanisme d’accusé de réception non conforme aux normes RFC. Cette anomalie est présente dans les référentiels de la vague 1 et reprise dans certains REM de la vague 2. Sur le terrain, les éditeurs ont majoritairement implémenté les accusés de réception conformément à la norme RFC.

L’exigence SC.MSS/va1.15 évolue pour s'aligner sur le mécanisme DSN normalisé afin de garantir la bonne émission et réception des accusés de réception par les solutions MSSanté.

La nouvelle version de l'exigences est la suivante : 

Le système DOIT permettre de demander un accusé de réception de type DSN lors de l'émission d'un courrier. Lors de l'envoi du message, le paramètre NOTIFY doit être positionné avec les valeurs SUCCESS,FAILURE,DELAY dans la commande SMTP "RCPT TO:"
Le mécanisme DSN est décrit dans la RFC 3461.
Exemple : RCPT TO: <adresse email> NOTIFY=SUCCESS,FAILURE,DELAY

Les nouveaux scénarios et preuves sont également mis à jour :

• Scénario - Accusé de réception par l'opérateur destinataire
• Etapes :
  1. Préparer un courriel.
  2. Choisir l'option qui permet d'avoir un accusé de réception de type DSN.
  3. Envoyer le message.
• Preuves :
  • Preuve 1 : Produire des copies d’écran : du courriel envoyé afin de valider la preuve.
  • Preuve 2 : Produire des copies d’écran : de l’accusé de réception reçu suite à l’envoi du courriel émis.
     

Le critère voie/rue n’est pas inclus dans les points de contrôle du référencement pour cette exigence.

Le CIBA est prévu dans la vague 2 du Ségur en tant que profil optionnel. En cas de client lourd, l'éditeur doit proposer les deux solutions (code flow et CIBA) en lien avec les exigences SC.PSC.01 et SC.PSC.13. Le profil est obligatoire lorsque l’éditeur a choisi d’implémenter dans sa solution logicielle l’authentification ProSanté Connect par le protocole CIBA (§3.1 du DSR DPI).

L’étape 4 a pour objectif de préciser le contenu attendu dans la preuve vidéo. Elle ne correspond pas à une action supplémentaire.