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

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 « auteur » 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é.

Le recours au bris de glace s'applique dans un contexte d'urgence vitale nécessitant une prise en charge rapide avec un patient dans l'incapacité de donner son consentement (patient inconscient, troubles cognitifs), rencontré pour la première fois.
Le bris de glace ne permet pas de passer outre un refus d'accès au DMP exprimé préalablement.
En médecine de ville, ce type de situation relève du très exceptionnel.
La fonctionnalité peut donc être discrète dans l'interface, placée dans un coin du logiciel, car elle n'a pas vocation à être utilisée.
Pour compléter : https://esante.gouv.fr/sites/default/files/media_entity/documents/20250917_guide-ps_consultation_mesdmp_-vff.pdf

En médecine de ville, l'épisode de soins couvre la durée entière de la prise en charge par le médecin traitant, ce qui peut s'étendre sur toute la vie du patient.
En médecine générale, cela correspond à la durée du statut de médecin traitant. Dans d'autres spécialités (par exemple la dermatologie), l'épisode de soins sera plus limité.
Le choix délibéré a donc été fait de ne pas définir précisément l'épisode de soins dans le référentiel, afin de laisser cette appréciation aux professionnels de santé en fonction de leur pratique. En pratique logicielle, l'épisode de soins peut être assimilé à la durée pendant laquelle le patient appartient à la patientèle active du médecin.

Il s'agit du cas d'un Proxy e-Santé tiers qui embarque des Composants Additionnels Non Autonomes (ou logiciels EAI).​

Dans le parcours Ségur, l'éditeur de la Solution Logicielle déclare qu'il utilise un Proxy e-Santé tiers et des Composants Additionnels Non Autonomes.​

Dans le parcours d'habilitation EDC PSC, l'éditeur ELU déclare qu'il utilise un Proxy e-Santé tiers.

Dans le parcours d'homologation au CNDA, l'éditeur de la Solution Logicielle déclare qu'il utilise des Composants Additionnels Non Autonomes (EAI) intégrés au Proxy e-Santé et celui-ci bénéficiera d'un plan de test adapté.

Si une Solution Logicielle fait appel à plusieurs téléservices (INSi, DMP, Ordonnance Numérique, MSSanté, etc.), elle doit disposer d’une architecture conforme aux exigences de l’Espace de Confiance Pro Santé Connect (EDC PSC), comprenant au minimum un composant principal (LPS) et un Proxy e-Santé.

Chaque composant de cette architecture doit être déclaré et faire l’objet des habilitations EDC PSC appropriées. L’éditeur de chaque composant est responsable de sa conformité et de sa sécurité, ainsi que de celles des composants intégrés ou interfacés avec celui-ci, conformément aux exigences de Pro Santé Connect et du CNDA.

Par ailleurs, si une même solution consomme plusieurs téléservices, elle suit un parcours d’habilitation EDC PSC unique pour son architecture déclarée, mais doit obtenir autant d’homologations CNDA que de téléservices concernés. Par exemple, une solution utilisant l’INS, le DMP et l’Ordonnance Numérique devra disposer d’une architecture habilitée EDC PSC et réaliser les homologations CNDA correspondantes pour chacun de ces téléservices.

C'est un scénario nominal possible si les fichiers d'attente ne sont pas synchronisés au sein du logiciel. Si cette situation se produit :

• Côté DMP : La V2 sera stockée (comme version initiale ou de remplacement selon le choix fait à la Question 1).
• Côté MSSanté : Le destinataire ayant reçu la V1, l'émetteur DOIT obligatoirement renvoyer la V2 par MSSanté (selon le principe du "Annule et remplace" exigé en vague 1) afin de garantir que le correspondant dispose de la même information médicale que celle présente sur le DMP du patient.
   

Note : Les éditeurs sont encouragés, dans la mesure du possible, à synchroniser leurs files d'attente DMP et MSSanté pour éviter ces écarts.

Si le DMP n'a jamais reçu la version initiale (V1), toute tentative d'envoi d'une V2 contenant une métadonnée de remplacement (RPLC ou lien vers l'identifiant de la V1) sera refusée par le DMP, car le document à remplacer est inconnu de ses services. Dans ce scénario, le logiciel a deux options, la première étant fortement recommandée :

1. Option privilégiée : Envoyer directement la version finale (V2) au DMP en tant que document initial (V1 pour le DMP). Les modifications intermédiaires restent purement locales au logiciel métier.
2. Option secondaire : Envoyer de manière séquentielle la V1, puis la V2 avec sa requête de remplacement (génère un trafic technique peu utile).

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.

Oui. 
Les exigences affichées dans Convergence sont générées automatiquement en fonction : 

• des profils fonctionnels déclarés, 
• des composants optionnels sélectionnés. 

Le filtrage est essentiel, le tri peut être simple (ex : ordre alphabétique). L’idée est d’extraire l'information (ex : nature du document) des métadonnées de l'enveloppe IHE.XDM sans avoir à ouvrir le message et permettre ainsi tri et filtre.