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

Le scénario LGC.DMP/UX.10.01 décrit une consultation type incluant la qualification de l’INS à partir des informations issues de l’Application Carte Vitale (ApCV), ainsi que la production et la diffusion d’une ordonnance (ON, DMP, MSSanté).
Les prérequis du scénario mentionnent actuellement un patient dont l’INS doit être qualifiée, ce qui entre en contradiction avec les étapes du scénario.

Le prérequis suivant pose problème "Patient test … " or, les étapes du scénario prévoient explicitement la recherche et la qualification de l’INS sur la base des informations issues de l’ApCV.

Exiger une INS déjà qualifiée en prérequis rend donc cette étape inutile, voire incohérente, et n’est pas compatible avec les usages attendus de la qualification de l’INS via l’Application Carte Vitale.

Dans le nouveau scénario, la mention "dont l’INS doit être qualifiée" est supprimée.

Le scénario est le suivant : 

• Prérequis :
  • Patient test :
    • disposant d'un DMP avec au moins un document
    • disposant d'un dossier local dans le logiciel avec au moins 1 document différent de celui du DMP
    • qui n'a pas bloqué l'utilisateur test
      • Utilisateur identifié via Pro Santé Connect
      • Interface réseau bridée avec une latence de 3 secondes

• Etapes du scénario :

  Utilisation du logiciel pour une consultation type :

  • Recherche et qualification de l'INS sur la base des informations issues de l'ApCV
  • Production d'une ordonnance
  • Envoi de l'ordonnance au service ON
  • Obtention du QR Code
  • Envoi de l'ordonnance dans le DMP
  • Envoi de l'ordonnance au patient via MSSanté

A minima, les requêtes aux services numériques INS et ON doivent faire l'objet d'un élément visuel permettant à l'utilisateur d'apprécier le statut de la requête (en cours, échec, réussi).

L'interface ne doit pas être bloquée par une requête en cours vers un service numérique (ie l'utilisateur doit pouvoir continuer d'utiliser l'interface graphique du logiciel sans être bloqué)

Jeu(x) de test CNDA à utiliser :
143110095083713 - CLÉRICO Côme
167100093480710 – BOUCHER François
 

Initialement, le scénario précisait que l’éditeur DOIT exécuter le cas de test suivant sur l’espace de test d’interopérabilité des SIS pour un plan personnalisé de prévention (Type_Code : 11490-0) : CI-SIS-CR-VIL-N1-Create_doc-Sc2

Il s'agit du plan personnalisé de prévention au format PDF/A-1 pour le cas de tests CI-SIS-CR-VIL-N1-Create_doc-Sc2, en mentionnant le ou les destinataires initialement prévus à la création du document dans l’en-tête CDA N1 et le PDF/A-1. Hors, il a été identifié que le Type_Code « 11490-0 » ne correspond pas à un plan personnalisé de prévention. Ce code est associé à une lettre de suivi, type de document qui n’est pas référencé dans le REM LGC. L’utilisation de ce Type_Code dans le cadre du scénario introduit donc une incohérence entre le type de document attendu et le code utilisé, susceptible de générer les éditeurs.

Ainsi, le Type_Code attendu pour un plan personnalisé de prévention est "83869-8".

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.

Oui. Si vous étiez en cours de référencement lors des précédents guichets de référencement MDV sur Wiin.io, notez qu'il n'y a pas de reprise de données entre Wiin.io et Convergence.

La phase de test implique la réalisation de tests en boîte grise, où l'auditeur dispose d'informations préalables, ainsi que la réalisation de compléments en boîte noire, où l'auditeur agit sans informations préalables dans le but de repérer les failles et d'obtenir une évaluation exhaustive de la sécurité de l'application. Cette phase dure en moyenne 3 à 4 jours.

La clause de revoyure permet d'avoir un engagement de la part de l'auditeur pour tester de nouveau les exigences non validées lors du test d'intrusion et d'effectuer un contre-audit afin de vérifier si les mesures de sécurité nécessaires ont été mises en œuvre.

La phase de rapport consiste à la fourniture par l'auditeur du rapport du test d’intrusion en remplissant et en signant électroniquement le formulaire correspondant. Ce document regroupe l’ensemble des résultats du test d’intrusion ainsi que le référencement de l’application.  

Non. La différence principale est :

• 0502 : le dossier patient est vierge. Les données IPS peuvent être intégrées sans risque de conflit.
• 0501 : le dossier contient déjà des données. Il existe un risque de conflit entre données existantes et données issues de l’IPS.

La mention « sans supprimer la donnée existante » vise à éviter un écrasement global du dossier.

Non.

• En cabinet individuel : le professionnel voit uniquement ses statistiques.
• En cabinet de groupe : chaque professionnel voit ses propres statistiques.
• En structure (centre de santé, MSP, etc.) : un niveau structure (FINESS) peut exister et les statistiques sont colligés à la maille du Finess

Il n’est pas demandé de gérer des habilitations complexes.