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

Non. Ces exigences sont bien distinctes de la base de données médicamenteuses et de la partie LAP. Elles portent sur les référentiels sémantiques pour la codification des pathologies et des actes, c'est-à-dire les jeux de valeurs mis à disposition sur le Serveur Multi-Terminologie (SMT) de l'ANS. Il s'agit notamment des nomenclatures CIM-10, CISP-2 et Dictionnaire des Résultats de Consultation, ainsi que des jeux de valeurs pour la biologie.
Ces référentiels doivent être intégrés directement dans le logiciel de gestion de cabinet (LGC), avec différentes modalités d'implémentation possibles : certains éditeurs les intègrent individuellement, jeux de valeurs par jeux de valeurs, d'autres proposent une recherche transversale sur les codes pathologiques (notamment pour CIM-10/CISP-2/DRC, qui peuvent faire l'objet d'une interrogation croisée). L'interrogation via le SMT de l'ANS est également possible.
Les trois exigences ERG.VA1.01, ERG.VA1.02 et ERG.VA1.03 vont ensemble et couvrent ces trois référentiels de pathologies. La biologie dispose quant à elle d'exigences dédiées et distinctes.

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.