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

Oui, les métadonnées MSS doivent être visibles directement dans la liste sans ouvrir le message (comme un client mail). 

Même si l’exigence suppose un compte unique : 

• proposer un choix de compte est acceptable
• ou définir un compte par défaut

La conformité est validée dans ce cas. 

Une page intermédiaire est acceptable, sous certaines conditions, il est nécessaire que :

• Pro Santé Connect (PSC) soit clairement mis en avant ; 
• les autres modes d’authentification nécessitent une action supplémentaire de l’utilisateur.

En pratique, l'exigence SC.PSC.15 impose la mire d'authentification PSC comme mode par défaut.
 

Exemple : 

Non, il n'existe aucune obligation de conservation des notes de vaccination en local. Le stockage via le DMP est suffisant. L'implémentation de la possibilité d'un stockage local relève d'un choix produit.

Il est attendu de conserver un historique complet des consentements, et non uniquement la dernière valeur enregistrée. Cet historique doit permettre de retracer l’ensemble des évolutions, en incluant :

• les différentes valeurs successives du consentement ; 
• les dates de modification ; 
• l’auteur de la modification ; 
• idéalement, le motif du changement.

La durée de conservation est de : 

• Pour les logs techniques : conservation recommandée de 6 mois à 1 an
• Pour les traces médico-légales (dont consentements) : conservation pouvant aller jusqu’à 20 ans

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.

Non, une DRIMbox ne peut s’appuyer sur un RIS non référencé vague 2 .

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.