Le CIBA est prévu dans la vague 2 du Ségur en tant que profil optionnel. En cas de client lourd, l'éditeur doit proposer les deux solutions (code flow et CIBA) en lien avec les exigences SC.PSC.01 et SC.PSC.13. Le profil est obligatoire lorsque l’éditeur a choisi d’implémenter dans sa solution logicielle l’authentification ProSanté Connect par le protocole CIBA (§3.1 du DSR DPI).

Le contenu des traces fonctionnelles attendues est défini par l’exigence SC.MSS/CONF.18.
L’objectif est de permettre un suivi des actions significatives réalisées sur les boîtes aux lettres MSSanté, sans conserver l’intégralité des échanges IMAP/SMTP ni le contenu des messages.

Ainsi, pour chaque boîte aux lettres, il est attendu a minima que les traces permettent de connaître :

• l’identifiant de l’auteur de l’action, dûment authentifié ;
• l’horodatage local du poste au moment de l’action ;
• le type d’action réalisée (consultation, envoi, suppression, etc.) ;
• la demande effectuée sur le serveur de messagerie MSSanté ;
• la réponse fournie par le serveur (y compris en cas d’échec).

Le contenu des messages ne doit en aucun cas être tracé. Le choix du niveau de détail des traces et des traitements suivis est laissé à l’appréciation de l’éditeur, dans la mesure où ces traces visent avant tout à le protéger, notamment en cas de requête judiciaire ou d’incident de sécurité. Il est toutefois attendu a minima que les actions d’envoi et de suppression de messages soient tracées.

Concernant la durée de conservation :

• Comme indiqué au §5 du référentiel #2 MSSanté, une durée de conservation de 6 mois est recommandée pour ces traces fonctionnelles.
• Le responsable de traitement (LPS) reste libre de définir la durée exacte de conservation, en fonction de son analyse de risques et de son cadre réglementaire.
• Les traces doivent être soumises aux mêmes mesures de sécurité et de confidentialité que les données MSSanté auxquelles elles se rattachent (mesures organisationnelles, techniques, etc.).

Afin de clarifier les attendus, notamment pour les documents intégrés depuis le DMP ou la MSSanté, la formulation « document CDA R2 N3 encapsulé » est remplacée par « document CDA R2 N3 avec une copie du document au format PDF dans la section FR-Document-PDF-copie ».

Cette évolution est uniquement rédactionnelle : le fond et l’objectif de l’exigence restent inchangés. En l'occurrence : Pour l’affichage des métadonnées issues d’un document CDA R2 N3, accompagné d’une copie au format PDF dans la section FR-Document-PDF-copie, le système ne DOIT afficher qu’une seule ligne dans l’espace documentaire.

Par suppression, on entend l'accès au document qui n'existe plus : ce document n’est pas ou plus accessible à l’utilisateur car il peut avoir été supprimé, masqué, ou que le PS n'est pas habilité.

Dans tous les cas, il faut l’indiquer à l’utilisateur et celui-ci doit toujours avoir la capacité de le supprimer

Oui, il est possible de combiner certains critères, selon leur pertinence. Il n’est pas obligatoire de pouvoir interroger individuellement tous les critères listés dans l’exigence.

Si l’épisode de soins se poursuit, la transaction TD03 peut être renouvelée automatiquement par le logiciel, sans action explicite du professionnel ni du patient.

Cette tolérance a été précisée dans le guide d’intégration DMP, afin de ne pas introduire une contrainte métier irréaliste.

La « fenêtre d’interrogation » ne désigne pas nécessairement une interface dédiée. Elle correspond à l’endroit où l’utilisateur peut modifier les traits d’identité utilisés pour l’appel au téléservice INSi.

Cette modification peut être réalisée :

• soit via une fenêtre dédiée,

• soit directement dans la fiche d’identité du patient.

L’exigence est satisfaite dès lors que l’utilisateur peut modifier les traits (notamment le COG) et relancer l’interrogation, indépendamment du choix ergonomique du logiciel.

Cette exigence a pu donner lieu à des interprétations différentes quant à son périmètre d’application, notamment en ce qui concerne le moment d’affichage et le niveau auquel la confirmation « j’ai compris » doit être demandée.

Cette confirmation est destinée à l’utilisateur (professionnel de santé) et doit être affichée à la première connexion, puis de manière périodique selon une fréquence paramétrable (par exemple tous les 180 jours). Elle n’a pas vocation à être affichée au niveau du patient ou du dossier patient.

• Quel est l’objectif de l’exigence ?

L’exigence SC.DMP/CONF.21 impose que le système informe chaque professionnel de santé (PS) que son RPPS est utilisé pour la traçabilité nationale et pour le contrôle d’accès au DMP/MES. L’objectif est d’assurer la transparence et de sensibiliser les utilisateurs au bon usage du DMP.

• Quelle information doit obligatoirement être affichée ?

Deux textes doivent apparaître :

• Texte d’information générale :
  « Le logiciel peut effectuer des requêtes de recherche de document au nom de l'utilisateur sur les DMP/MES et permet d'en consulter, sur action manuelle, les documents d'intérêt. Ces interactions sont tracées avec l'identifiant national de l'utilisateur et le patient est notifié de ces interactions. »
• Texte du bouton « j’ai compris » :
  « Toute consultation de ma part d'un DMP/MES pour lequel le patient (ou son représentant légal) n'a pas donné son consentement m'expose à des poursuites. »
   
• À quelle fréquence cette information doit-elle être affichée ?

À la première connexion de l’utilisateur après la mise à jour Ségur, puis à intervalle régulier paramétrable (valeur par défaut : 180 jours).

• Cette demande concerne-t-elle chaque patient ?

Non. Le clic « j’ai compris » ne doit pas être demandé pour chaque patient. La validation est réalisée une seule fois par utilisateur, à la fréquence programmée.

• Obligations pour l’éditeur

• Afficher le texte obligatoire sans modification
• Garantir une fréquence paramétrable (défaut : 180 jours)
• Affichage une seule fois par utilisateur, pas par patient

Le consentement n’a pas vocation à être recueilli à chaque consultation. Le consentement est rattaché à un épisode de soins, lequel dépend des modalités de prise en charge :

• Pour un médecin traitant ou un spécialiste suivant régulièrement un patient, l’épisode de soins peut être long et continu.
• Le patient n’a donc pas à redonner son consentement à chaque acte ou consultation.

L’éditeur doit permettre le recueil initial du consentement, la possibilité pour le patient de changer d’avis, sans obligation de clôturer systématiquement l’épisode de soins.

Les modalités de traitement des modifications de structures sont décrites dans les AF.

En vague 2 RIS et DRIMbox, la démarche d'homologation de la solution auprès du CNDA est obligatoire, qu'elle utilise des composants additionnels ou non pour l'intégration des services INS, ApCV ou DMP.

Vous devrez redéposer vos preuves sur chaque DSR sur lesquels vous candidatez.

Les durées de conservation sont une responsabilité du responsable de traitement.

En tant qu'éditeur, vos logiciels doivent être capables de gérer deux durées de conservation distinctes :

• Les traces techniques (ex. logs d'erreurs, événements système) pour le support et la maintenance du logiciel, conservées sur une courte période de 6 mois à 1 an (recommandations CNIL).
• Les traces applicatives (ex. journaux d'accès aux dossiers patients) pour des raisons légales et de traçabilité, conservées sur une longue période de 20 ans, conformément à la durée de conservation des dossiers médicaux (article R.1112-7 du code de la santé publique).

Ces traces constituent des données à caractère personnel et il faut donc prévoir des mesures de sécurité adaptées à cette longue durée de conservation, ainsi qu’une information adaptée (par exemple, via les conditions générales d'utilisation (CGU) ou la politique de confidentialité) du responsable de traitement, voire une capacité d’adaptation des durées par ce dernier.

Comme précisé dans le DSR-IMG-DB-Va2 (page 39), pour obtenir l’autorisation d’accès aux espaces de tests du CNDA, il faut compléter le formulaire administratif et renseigner la partie « Prérequis de maturité technique » sur le guichet Éditeur EDC PSC, à la fois pour le Proxy Manager et pour les composants principaux de la Solution Logicielle. 

Vous pouvez vous référer au processus d'accès aux environnements de tests.

Ces exigences indiquent que : 
- le logiciel utilisateur doit être habilité en tant qu’Éditeur de logiciel utilisateur à l’espace de confiance Pro Santé Connect (SC.PSC.14) 
- le Proxy e‑Santé doit être habilité en tant qu’Éditeur de Proxy e‑Santé à l’espace de confiance Pro Santé Connect (SC.PSC.16).
Ces habilitations sont indispensables avant de pouvoir demander le statut d’Opérateur correspondant (Opérateur de service utilisateur et Opérateur de Proxy e‑Santé).