Le cas typique est celui où la carte CPS se trouve chez la secrétaire. Le médecin envoie un document depuis son poste, mais l'envoi ne part pas faute de carte CPS. Le document est alors mis en liste d'attente et c'est depuis le poste de la secrétaire, lorsque celle-ci est connectée avec une carte permettant l'envoi au DMP, que le document est effectivement transmis.
La production du document et sa validation restent de la responsabilité du prescripteur.
Sur la question de l'auteur du document dans les métadonnées : même si le document part via une carte CPE anonyme, le champ « header author » doit rester renseigné avec l'identité du médecin qui a validé le document dans le logiciel. Les spécifications techniques de la transaction (TD 2.2 du GI DMP 2.10) précisent les attributs associés à l'auteur et au porteur de la carte ; certains de ces attributs peuvent être absents lorsque la carte utilisée est anonyme, mais l'auteur fonctionnel du document doit toujours être tracé.

Les preuves attendues pour les exigences ANN/va1.02.01.02 et ANN/va1.03.01.02 dépendent du mode d'alimentation des correspondants mis en œuvre par votre solution.

Cas n°1 : alimentation par téléchargement de fichier

 Lorsque l'alimentation repose sur le téléchargement de fichier il est attendu de déposer un fichier de log permettant de visualiser a minima :

• le chargement des données ;
• le traitement réalisé ;
• le nombre total d'enregistrements traités ;
• une synthèse des résultats du traitement.

Ce fichier doit permettre de vérifier le bon déroulement du traitement d'import des correspondants.

Cas n°2 : alimentation via l'API FHIR

Lorsque l'alimentation repose sur l'API FHIR, les preuves attendues sont adaptées au mode de fonctionnement de cette interface.

Dans ce cas, il est attendu de fournir :

• un exemple de recherche unitaire d'un correspondant ;
• le retour de l'appel aux ressources FHIR issu de l'environnement de production.

Dans cette configuration, le dépôt d'un fichier de log n'est pas attendu, la preuve de conformité reposant sur les échanges FHIR réalisés avec le service.

Afin de répondre aux exigences LABEL.XX, il est attendu des candidats concernés d'indiquer qu'ils disposent du label e-santé pour ne pas laisser la preuve vide sans contrainte sur le format. Les vérificateurs vérifieront l'information sur le tableau de suivi dont dispose l'ANS.

Afin de renseigner une note de vaccination lorsqu'un professionnel saisit rétrospectivement un vaccin ancien et ne dispose plus du numéro de lot :

• La codification du vaccin en CIS et ATC est obligatoire. 
• Le numéro de lot est obligatoire (card [1..1]), mais si l'information n'est pas connue, vous pouvez utiliser un nullFlavor="UNK".

Vous devrez redéposer vos preuves sur chaque DSR sur lesquels vous candidatez.

Toutefois, si votre solution est éligible au mécanisme d’équivalence des preuves, vous pourrez être exempté du dépôt de certaines preuves communes au dispositif candidat (par exemple : Médico-social DUI, Sage-femme / Paramédical), dès lors que vous avez déjà obtenu un référencement Vague 2 sur un autre dispositif comportant ces mêmes exigences. Pour cela, vous pouvez consulter la matrice d'équivalence correspondant à votre couloir candidat sur le site de l'ANS. 

Pour un utilisateur, la gestion de l'envoi de documents vers le Dossier Médical Partagé (DMP) et la Messagerie Sécurisée de Santé (MSS) depuis un logiciel s'effectue par une interface conçue pour être à la fois automatisée et personnalisable. L'objectif est de simplifier au maximum le processus tout en respectant les obligations légales et les situations spécifiques des patients.

Envoi de documents au DMP
L'envoi automatisé d'un document au DMP est défini dans l'onglet "Liste des documents Ségur" du Référentiel d'Exigences (REM) de votre dispositif et le document est visible par le patient.
Cette configuration par défaut est non modifiable de façon globale par l'utilisateur, ce qui garantit le respect de l'obligation légale d'alimentation du DMP (Article L. 1111-15 du Code de la santé publique précisé par l’arrêté du 23 mai 2024).

Toutefois, le professionnel de santé dispose de deux options pour gérer l'envoi et la visibilité d'un document au cas par cas :

• Ne pas envoyer un document : L'utilisateur a la possibilité de ne pas envoyer un document au DMP si le patient s'y oppose pour un motif légitime (motif légitime ne nécessitant pas de traçabilité et laissé à l’appréciation du professionnel)
• Modifier la visibilité : Le professionnel peut rendre un document invisible au patient (dans l'attente d'une consultation d'annonce pour un diagnostic grave) ou à ses représentants légaux (Le respect du secret médical pour un mineur ne souhaitant pas que ses parents soient informés de certains soins.)
• Cas particulier « Modèles de documents »
  • Pour optimiser le processus de production documentaire, le professionnel pourrait pré-paramétrer des modèles de documents et leurs conditions de visibilité. Par exemple, un professionnel peut créer un modèle de « compte-rendu d'expertise judiciaire » et le configurer pour que son envoi au DMP soit désactivé par défaut.

Envoi de documents par MSS professionnelle
l'envoi des "documents Ségur" vers la MSS professionnelle est également défini dans l'onglet "Liste des documents Ségur" du REM. Ces documents sont systématiquement transmis, à minima, au Médecin Traitant (MT) et au professionnel adresseur.
Le professionnel de santé peut modifier ou amender la liste des destinataires ou les paramètres d'envoi si besoin.

La liste des documents qui doivent être produits et envoyés, ainsi que les formats attendus et les liens vers les volets CI-SIS, sont listés dans l'onglet "Liste des documents Ségur" présent dans le Référentiel d'Exigences (REM), disponible sur la page de votre dispositif  présent sur le site de l'ANS : https://esante.gouv.fr/ens/segur-numerique-sante/vague-2

• Dans le cas d'un CDAR2N1, le PDF à mettre en pièce jointe doit être identique à celui encapsulé dans le CDA.
• Dans le cas d'un CDAR2N3, "Le document de santé au format PDF doit afficher tous les éléments de l’entête du document CDA ainsi que les zones textuelles des différentes sections du corps du document CDA."

L'objectif est la cohérence sémantique. Le PDF doit permettre d'identifier sans ambiguïté la nature et l'origine du document. Toutefois, l'affichage peut être adapté aux usages métiers : le libellé peut être simplifié (ex: "Ordonnance"), et la précision de l'horodatage peut s'en tenir à la date (JJ/MM/AAAA) si l'heure n'apporte pas de valeur clinique au document visuel. L'enjeu est la correspondance des données de fond, pas le formatage technique.

Après prise en compte des besoins métiers et des dispositions prises au sein de certains logiciels, nous n’imposons pas systématiquement ce «  clic » préalable à l’intégration dans le logiciel. Deux cinématiques sont possibles au choix de l'éditeur pour valider l'exigence :

1. Option A : L'intégration au dossier patient se fait après un clic manuel de validation du professionnel.
2. Option B (Intégration directe) : Le document s’intègre automatiquement dans le dossier patient dès sa réception (dans le cas 1 où l'INS est rapprochée). Dans ce cas, le logiciel doit obligatoirement maintenir le document dans un statut « non lu » (au sein d'une liste de travail ou d'un espace dédié du dossier) tant que le professionnel n’a pas effectué une action explicite de prise de connaissance.

Oui, la gestion de l'historisation des versions de documents est bien obligatoire. Lorsqu'un document a fait l'objet d'une ou plusieurs mises à jour, il doit être possible d'accéder aux versions antérieures de ce document et de les visualiser. L'enjeu est médico-légal : les professionnels de santé ont exprimé le besoin de pouvoir consulter l'historique des versions d'un document (par exemple, un compte-rendu modifié).
En revanche, l'ergonomie et le mode d'implémentation de cette historisation ne sont pas spécifiés. Les éditeurs sont libres de choisir : affichage direct des versions antérieures, accès via un menu contextuel ou un clic sur le document, indication discrète qu'il existe des versions antérieures, etc. 
pour en savoir plus

La météo de service publiée par l'ANS (https://status.esante.gouv.fr/) ne couvre, à ce jour, que les services de l'ANS elle-même et ne remonte pas l'état de disponibilité des services de l'Assurance Maladie (dont le DMP fait partie). Des travaux sont en cours pour intégrer le statut du DMP dans cette météo. 
En pratique, les éditeurs disposent de deux moyens pour détecter une indisponibilité du DMP : les alertes envoyées par le GIE Sesam-Vitale en cas d'indisponibilité, et les erreurs retournées lors des transactions (qui peuvent indiquer que le DMP est fermé, indisponible, ou que le patient n'a pas de DMP). L'objectif pour les logiciels est d'afficher un message d'alerte clair au professionnel de santé lorsque l'une de ces situations est détectée.
Par ailleurs, l'absence d'API publique pour interroger la météo de service a été signalée comme une limite, et l'ANS en a pris note. 

Oui, cette implémentation est conforme à l'esprit de l'exigence DMP.UX.10. L'objectif fondamental est d'éviter que le logiciel soit entièrement bloqué pendant une transaction DMP, ce qui obligerait le médecin à attendre sans pouvoir continuer à travailler. 
Deux approches sont acceptables : l'implémentation en mode multithread (la transaction se déroule en arrière-plan pendant que l'utilisateur continue à utiliser le logiciel), ou, si cela est complexe à réaliser, la possibilité d'interrompre volontairement la transaction via un bouton ou une croix de fermeture et de passer à autre chose. Dans les deux cas, l'exigence est satisfaite. 

Les feuilles de style tendent à être abandonnées pour des raisons de sécurité (risques d'injection, cross site scripting, déni de service). L'exigence SC.CDA.VISU.01 prévoit que le système peut utiliser sa propre feuille de style par défaut. Cependant, elle précise également que lorsque la feuille de style par défaut n'est pas celle du producteur, le système doit permettre d'afficher le document avec la feuille de style du producteur si l'utilisateur le demande.
En pratique : si votre propre feuille de style permet d'afficher correctement l'ensemble des contenus, y compris les parties narratives (CDA niveau 1 et 2), vous êtes conformes. Il n'est pas obligatoire d'appliquer la feuille de style du producteur par défaut, mais il faut être capable de la proposer en option. L'exigence dans le scénario est de pouvoir afficher la partie narrative en appliquant soit la feuille de style du producteur, soit celle du consommateur.
Si la feuille de style reçue présente un risque de sécurité, il est tout à fait justifié de ne pas l'appliquer et d'utiliser uniquement la vôtre.