Le blocage de l’alimentation du DMP doit être unitaire et choisi par l’utilisateur.
L’utilisateur DOIT effectuer une action pour NE PAS ENVOYER dans le DMP (ex : case à cocher, bouton-radio…).
Cette action DOIT être effectuée pour CHAQUE document qu’il souhaite retenir.
Ce comportement DOIT être par défaut et DOIT être immuable : il NE DOIT PAS être configurable ou débrayable par l’utilisateur.

Non, chaque preuve doit être déposée séparément dans le formulaire en suivant scrupuleusement les formats imposés.

« Mon espace santé ne propose pas pour l’instant d’environnement de test ou de compte de test. Les éditeurs ont la possibilité de valider leurs implémentations en utilisant la BAL de réponse automatique ‘reponse.automatique-test@patient.mssante.fr’ qui est disponible en Espace de Confiance de production ».
Les réponses automatiques sont fonctions des différents cas rencontrés lors de l’envoi d’un message à un usager (BAL inexistante, suspendue, …)

Nous n'avons pas de recommandations, au niveau ANS. Nous vous invitons à consulter le guide de bonnes pratiques de l'ANSSI à ce sujet (https://www.ssi.gouv.fr/entreprise/guide/mecanismes-cryptographiques/).
L'objectif de cette exigence est de s'assurer que les éditeurs documentent de façon claire les modalités de stockage des pièces d’identité lorsqu’ils proposent cette fonctionnalité à leurs clients.

Votre solution n’a pas besoin d’être DMP compatible sur le profil consultation en authentification directe. L’éditeur doit passer par le profil Alimentation en authentification indirecte du Guide d’intégration DMP 2.4 ou supérieur transaction TD2.1
La transaction TD 2.1 permet de déposer un (ou des) document(s) dans le DMP d’un patient. Cette transaction gère également le remplacement d’un document par une nouvelle version.
Pour le cas d’usage décrit dans la question :
L’ancien compte-rendu reste INVISIBLE_PATIENT sur le DMP mais le nouveau compte-rendu est publié avec l’association REPLACE (RPLC) liant la fiche de la nouvelle version du document à la fiche de la version précédente du document. La métadonnée availabilityStatus de la fiche de la version précédente du document prend la valeur "Deprecated".

Remarque complémentaire : Dans le cas où la version du document doit être mise à jour sans changer le niveau de visibilité du document, la nouvelle version du compte rendu doit être publiée avec l’association REPLACE (RPLC) et avec la valeur du confidentiality_code de la précédente version du document.

Exigences Ref#2 MSS ECO 2.3.1 ou REM MDV MSS 16 : Un éditeur qui utilise une interface ne proposant pas de demander un accusé de réception (DSN cf ECO 2.3.1 ou MSS16 du DSR MDV) peut fournir des preuves de demande d'un accusé de lecture (MDN -> cf ECO 2.3.2).

Il s'agit de l'ensemble de la base de données.

Le but de cette exigence est une identification facile et rapide de l'expéditeur du message par le destinataire. Il n'est pas nécessaire d'avoir le même formalisme du "nom & prénom" que celui affiché sur l'annuaire santé.

Un éditeur ne doit pas imposer le remplissage d’autres champs que ceux rendus obligatoires par le RNIV/guide implémentation mais il peut proposer à la structure/le ps utilisateur de rajouter, sur paramétrage, des champs obligatoires.
D’un point de vue identito les référents IV ne souhaitent pas que par défaut l’éditeur propose le double nommage nom de naissance / nom utilisé car selon eux :

• cela peut-être désagréable pour un usager de devoir subir du double nommage parce qu'il n’a pas de nom d'usage et que la loi n’oblige personne à avoir un nom d’usage ;
• cela fausse le calcul de ressemblance par un algorithme et augmente artificiellement la ressemblance entre deux identités.
   

Ce mode de fonctionnement, tel que décrit ici, est conforme puisqu'il garantit que le statut de l'identité est bien rétrogradé lorsqu'un utilisateur modifie les traits stricts de l'identité.