FAQ Entreprise du numérique en santé

Sur Gazelle, il existe un outil appelé « Test Contenu CDA » qui permet de valider la qualité des fichiers CDA produits ou reçus, en s'appuyant sur des schématrons et des feuilles de style. Cet outil a notamment été utilisé pour les comptes rendus de biologie.
Concernant la mise à jour des outils par rapport aux évolutions des spécifications : les équipes en charge des outils d'interopérabilité actualisent les jeux de tests au fur et à mesure des nouvelles versions publiées. 
Annexe – testContenuCDA | Agence du Numérique en Santé 

Le DMP prévoit plusieurs niveaux de gestion de la visibilité des documents, qui doivent être bien distingués :
1. Masquage aux représentants légaux : c'est le cas visé dans la question (enfants à l'ASE, adolescents dont on souhaite protéger la confidentialité vis-à-vis des parents pour des soins en santé sexuelle, en addictologie ou en santé mentale). Ce type de masquage n'est pas concerné par le mécanisme de remise en visibilité automatique. Les médecins peuvent rassurer leurs patients : le masquage aux représentants légaux reste permanent sauf action volontaire du professionnel.
2. Invisibilité au patient lui-même : c'est dans ce cas uniquement que le mécanisme de remise en visibilité automatique (la « voiture balai ») s'applique. Il concerne typiquement les situations d'annonce de maladies graves (cancer, maladie neurologique grave, etc.), où le professionnel envoie le document en mode invisible au patient pour permettre une annonce médicalement accompagnée. Dans ce cas : une notification est envoyée au patient à 1 mois pour l'informer de l'existence d'un document invisible dans son dossier ; à 3 mois, si aucun professionnel n'a remis le document en visibilité, une remise en visibilité automatique intervient.
3. Masquage aux professionnels de santé : cette fonctionnalité, à l'initiative du patient lui-même, n'a pas vocation à être fortement mise en avant dans les logiciels métiers.
Pour les situations ASE, le mécanisme automatique à 3 mois ne s'applique donc pas. 

Le prescripteur peut conditionner la délivrance de certains médicaments à la réalisation et au résultat de tests à caractère médical, notamment d'examens biologiques ou d'orientation diagnostique, au moyen d'une ordonnance dite de dispensation conditionnelle (cf. [RG_EP107], cas particulier de la prescription avec dispensation conditionnelle).
Concrètement, le prescripteur doit pouvoir :
- sélectionner la dispensation conditionnelle (angine ou cystite),
- saisir une ligne produit de santé/DM en texte libre pour le TROD ou le test urinaire à réaliser par le pharmacien,
- saisir une ligne produit de santé/Médicament pour l’antibiotique,
- indiquer dans le champ « posologie » de niveau ligne en première position la condition de dispensation :
Pour l’angine : « si TROD angine positif, sous 7 jours calendaires à compter de ce jour »
Pour la cystite : « si BU positive ».
Le libellé de la condition de dispensation doit être standardisé et le poste doit le générer automatiquement pour faciliter la saisie par le prescripteur.
La posologie usuelle doit être saisie à la suite, et séparée de la condition de dispensation par un retour chariot (matérialisé par « \r »).

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.  

Non, l’accès aux environnements CNDA est nécessaire pour réaliser les pentests.
Délai d’ouverture : 15 jours ouvrés incompressibles entre l’enregistrement au CNDA et l’ouverture des environnements de tests. Ce délai est lié aux processus de création de jeux de données et au whitelisting. L'information est communiquée via l’espace personnel éditeur. 

La gestion d'une file d'attente d'envoi vers le DMP a deux objectifs : 

• éviter la perte de documents  
• permettre un envoi différé 

Par exemple, dans le cas d'un envoi impossible qui est stocké, ou lors d'un evoi effectué lors d’une reconnexion valide.