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

Lorsqu’un professionnel de santé reçoit une version 2 d’un document CDA avec un ordre de remplacement (ou de suppression) de la version 1, alors que cette version 1 n’a pas encore été classifiée dans le dossier patient au moment de la réception :

Il convient de se référer à l’exigence SC.CDA/VISU.02, qui impose que :

Lorsque le système stocke plusieurs versions d’un document, il doit permettre à l’utilisateur de visualiser la dernière version ainsi que les versions précédentes.

Aucun complément n’étant précisé dans le REM, les modalités d’implémentation sont laissées à l’appréciation de l’éditeur.

À titre indicatif, il peut être pertinent de :

• mettre en place des mécanismes d’alerte (ex : pop-up) pour informer l’utilisateur,
• et proposer un outil de comparaison entre versions, afin de faciliter la compréhension des évolutions du document.

Lorsqu’un document CDA comporte plusieurs versions (par exemple versions 1 et 2 avec un même setId) et qu’une version 3 est reçue avec un ordre de remplacement ou de suppression visant uniquement la version 2 : en l’absence de précisions dans le REM, aucune contrainte spécifique n’est définie concernant la gestion de la version 1.
Il appartient donc à l’éditeur de retenir l’option la plus adaptée aux usages des professionnels de santé, notamment en matière de conservation ou de visibilité des versions antérieures.

L’utilisation d’un composant tiers déjà homologué par le CNDA ne dispense pas systématiquement de réaliser une demande dans le cadre de la mise en conformité de votre solution logicielle. Dans la majorité des cas, une démarche reste nécessaire, cela dépend du type de composant tiers et de son mode d’intégration.

Afin de clarifier les règles applicables, plusieurs situations doivent être distinguées :

Premier cas de figure : le composant principal de la solution logicielle PS utilise un composant additionnel non autonome

Un composant additionnel non autonome est appelé au CNDA "application EAI" dans le cas du DMP ou "moteur à IHM" masquée dans le cas de l'INSi.

Dans ce cas :

• Chaque application EAI ou chaque moteur à IHM masquée doit passer une homologation au CNDA.
• Chaque composant principal d'une solution logicielle qui intègre une application EAI / moteur à IHM masquée doit passer une homologation au CNDA.

A noter que l'homologation est complète mais plus rapide car les applications EAI/moteur à IHM masquée ont déjà validé une partie des tests à repasser.

Deuxième cas de figure : le composant principal de la solution logicielle PS utilise un composant additionnel autonome

Un composant additionnel autonome est une application (tierce) à part entière avec des IHM autonomes et visibles. Au CNDA, il s'agit d'une application autonome. Le composant principal d'une solution logicielle PS s'interface avec l'application autonome (tierce) via un appel contextuel. L'opérateur de la solution logicielle PS peut opérer une instance dédiée de la solution autonome (tierce) ou peut utiliser une instance mutualisée opérée par l'éditeur de la solution autonome tierce.

Dans ce cas :

• Chacune de ces applications autonomes tierces doit passer une homologation au CNDA.
• Dans le cas du composant principal de la solution logicielle PS :
  • Si l'opérateur du composant principal de la solution logicielle PS opère aussi une instance dédiée de l'application autonome (tierce) alors le composant principal de la solution logicielle PS doit passer une homologation d'interfaçage avec l'application autonome (tierce) dans le cadre de la conformité DMP.
  • Pour l’INSi et l’Ordonnance Numérique les éditeurs intégrant des composants tierces (moteur coté CNDA) doivent déposer une demande de conformité en mode apparent.
    • Dans le cas où le logiciel intègre un composant déjà autorisé « INSi » et/ou « Ordonnance Numérique » en mode IHM apparente, l’éditeur n’a pas à constituer de dossier de preuves de tests, il peut passer directement à l’étape d’examen de conformité indiquée à l’Article 5.3 : Etape d’examen.
      Dans le cas où le logiciel intègre un composant déjà autorisé « INSi » en mode IHM masquée (ou semi masquée), l’éditeur doit réaliser toute les phases de la procédure de conformité.

Oui. 
Pour les éditeurs de logiciels de médecine de ville, la validation des pré-séries ordonnance numérique est une condition nécessaire pour le versement du solde du financement Ségur Vague 2.

Une pré-série validée sur le cahier des charges V1 de l’ordonnance numérique reste valable. 

Aucun format unique n’est imposé. 
Les preuves peuvent être fournies sous différents formats :

• captures d’écran,
• documents PDF,
• formulaires métiers,
• documents structurés (ex. CDA R2 N1).

L’objectif est de démontrer la conformité fonctionnelle aux exigences. 

Non. 
Les exigences liées au carnet de santé de l’enfant n’imposent aucun blocage strict basé sur l’âge exact. 
La saisie doit être possible tant que l’enfant se situe dans la période réglementaire de l’examen. 

Ce fonctionnement est conforme au cadre réglementaire :

• une année de vie correspond à la période entre deux anniversaires,
• la 7ᵉ année débute le jour des 6 ans révolus.

Les exigences n’imposent donc pas une correspondance stricte avec l’âge exact au jour près. 

Non. 
Les exigences du carnet de santé de l’enfant reposent sur une logique de périodes réglementaires, et non sur une date anniversaire stricte.

Les libellés tels que :

• Examen du 2ᵉ mois,
• Examen du 9ᵉ mois,
• Examen de la 6ᵉ année,

correspondent à des fenêtres d’âge définies réglementairement. 

Non, le PDF encapsulé est obligatoire uniquement pour certaines exigences et cas d’usage, notamment : 

• les comptes rendus de biologie consommés, 
• les ordonnances de produits de santé structurées – CDA R2 N3, lorsque ce profil est retenu. 

Non. 
L’exigence Visu.01 n’impose pas l’affichage HTML du contenu clinique. 
Le contenu médical peut être affiché en PDF, dès lors que l’accès est fluide et conforme aux usages.