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

Les spécifications fonctionnelles et techniques des échanges se trouvent ici https://esante.gouv.fr/volet-si-esms-viatrajectoire-module-ph.

En complément, vous pouvez trouver le guide d’implémentation fonctionnelle à l’adresse https://esante.gouv.fr/sites/default/files/media/document/VTPH_Guide-implementation.pdf et la spécification d’authentification via ce lien : https://esante.gouv.fr/sites/default/files/media/document/SPF_SISDO_ViaTrajectoire_Authentification_v1.2.pdf.

Vous pouvez également consulter la page dédiée sur le Portail de la e-santé pour les Entreprises du Numérique en Santé https://esante.gouv.fr/ens/offre/interoperabilite-viatrajectoire-module-handicap.

En vertu du RGPD vous devez déjà tracer l’accès aux données de santé à caractère personnel. Le fait de rajouter l’INS à ces données de santé à caractère personnel ne change rien. Il sera simplement vérifié que cette traçabilité est faite. Cette exigence sera vérifiée en s'assurant que lorsqu'un acteur accède au dossier d'un usager - doté ou non d'une INS (ouvre le dossier de cet usager) - cet accès est tracé dans la solution.

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.

Après obtention du plein exercice, l'inscription à l'ordre est obligatoire.
Le professionnel est alors enregistré dans le RPPS comme professionnel pleinement reconnu, avec conservation de son numéro RPPS.
L'employeur ou employé doit fermer l'activité PADHUE dans le Portail RPPS+.
L’inscription à l’ordre doit être réalisée par le professionnel.

Oui. Les ordres auront accès aux données du RPPS via une extraction de l'Annuaire Santé afin d'identifier les PADHUE ayant une activité ouverte dans un établissement.
Cet accès leur permettra d'assurer un premier niveau de suivi et de contrôle, notamment pour les professionnels ayant obtenu le plein exercice.

Non. L'acronyme « PADHUE (Praticiens à Diplôme Hors Union Européenne) – Médecin / Pharmacien / Sage-Femme / Chirurgien-Dentiste » indique qu'il s'agit d'un professionnel à diplôme hors Union Européenne, en cours de procédure d'autorisation d'exercice.
Ce libellé ne doit pas être confondu avec les titulaires d'une autorisation temporaire d'exercice (ATE), qui sont des professionnels pleinement qualifiés.

L'affichage de ce libellé dans le Portail RPPS+ et dans l'Annuaire Santé est volontairement différencié pour éviter toute confusion.

Non, pas à ce stade. L'accès au DMP est dépendant d'une matrice de droits en cours de révision avec la CNAM.
Cette question est suivie séparément et fera l'objet d'une communication dédiée le moment venu.

Aucune disposition législative ou réglementaire du Code de la santé publique ne permet aux PADHUE en cours de procédure (AEP, EVC, PCC) de s'inscrire à un ordre (à l'exception de la procédure applicable en outre-mer).
Les PADHUE ne figurent pas dans la liste des professions que les ordres peuvent enregistrer au RPPS (cf. Arrêté RPPS du 23 septembre 2022).
L'enregistrement par les employeurs est la seule option juridiquement possible à court terme. Un modèle hybride nécessiterait des modifications législatives et réglementaires, incompatibles avec l'urgence de la situation terrain.

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é.

Cette phase a pour finalité d'échanger sur le rapport du test d'intrusion, notamment si des manquements aux règles de sécurité sont détectées. L'auditeur devra communiquer les résultats du test d'intrusion à l'éditeur en clarifiant les points suivants :

• Les détails techniques des vulnérabilités identifiées ;
• L'impact potentiel des non-conformités aux règles de sécurité et le niveau de risque associé ;
• Les solutions concrètes permettant de corriger les potentielles failles ;
• La définition des prochaines étapes (définition d’une date permettant d’évaluer de nouveau les vulnérabilités recensées).