Aucun format unique n’est imposé. 
Les preuves peuvent être fournies sous différents formats :

• captures d’écran,
• documents PDF,
• formulaires métiers,
• documents structurés (ex. CDA R2 N1).

L’objectif est de démontrer la conformité fonctionnelle aux exigences. 

Non. 
Les exigences liées au carnet de santé de l’enfant n’imposent aucun blocage strict basé sur l’âge exact. 
La saisie doit être possible tant que l’enfant se situe dans la période réglementaire de l’examen. 

Ce fonctionnement est conforme au cadre réglementaire :

• une année de vie correspond à la période entre deux anniversaires,
• la 7ᵉ année débute le jour des 6 ans révolus.

Les exigences n’imposent donc pas une correspondance stricte avec l’âge exact au jour près. 

Non. 
Les exigences du carnet de santé de l’enfant reposent sur une logique de périodes réglementaires, et non sur une date anniversaire stricte.

Les libellés tels que :

• Examen du 2ᵉ mois,
• Examen du 9ᵉ mois,
• Examen de la 6ᵉ année,

correspondent à des fenêtres d’âge définies réglementairement. 

Non, le PDF encapsulé est obligatoire uniquement pour certaines exigences et cas d’usage, notamment : 

• les comptes rendus de biologie consommés, 
• les ordonnances de produits de santé structurées – CDA R2 N3, lorsque ce profil est retenu. 

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.

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.