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

Non. 
L’exigence Visu.01 n’impose pas l’affichage HTML du contenu clinique. 
Le contenu médical peut être affiché en PDF, dès lors que l’accès est fluide et conforme aux usages.

Oui. 
Dans le cadre de l’exigence Visu.01 : 

• pour un document CDA R2 N1, l’en-tête est structuré, 
• le corps du document est généralement un PDF encapsulé. 

L’exigence est respectée dès lors que le PDF encapsulé est accessible et lisible par l’utilisateur, en cliquant par exemple sur un bouton de visualisation du PDF 

Le DSR Vague 2 Médecine de ville n’a pas vocation à être republié. 
Toutefois, des ajustements ciblés peuvent être étudiés lorsque des difficultés techniques ou fonctionnelles sont objectivées et documentées par les éditeurs (ex. impacts de performance, volumétrie, faisabilité). 
Ces ajustements concernent uniquement des exigences identifiées et ne remettent pas en cause la structure globale du référentiel. 

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.

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.