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

Aucun champ supplémentaire n’est exigé.
Vous pouvez toutefois proposer des critères additionnels, tels que voie/rue désormais proposé par l’API Annuaire ou la BAL préférentielle qui sera bientôt publiée par l’annuaire mais ceux cités dans l’exigence doivent être présents à minima.

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

1. Quel est le changement principal ?

Avant : le système devait informer uniquement si un document avait une nouvelle version ou avait été supprimé du DMP.
Maintenant : le système doit informer si un document a une nouvelle version ou s’il n’est plus accessible (supprimé, masqué, non habilité).
Ce changement est lié au fait que le DMP ne renvoie pas toujours explicitement l’information « supprimé ».

2. Concrètement, qu’est-ce que ça implique ?

• Nouvelle version : informer, permettre la visualisation et l’intégration, en gardant les anciennes versions.
• Non accessible : informer, proposer la suppression dans le dossier patient, uniquement sur action de l’utilisateur.

3. Quand la vérification est-elle faite ?

À l’ouverture du dossier patient (pas en continu).

4. Quelles obligations pour l’éditeur ?

Développements et tests obligatoires avant l’homologation DMP Compatibilité (CNDA).

Annexe – Nouvelle version exigence, scénarios et preuves

Nouvelle version de l’exigence

CDA.DD.05 : LORSQUE l'utilisateur accède au dossier du patient, ALORS sans action supplémentaire de sa part et sans bloquer l'interface utilisateur, pour un document déjà intégré dans le dossier du patient depuis le DMP, le système DOIT l'informer :
* qu'il existe une version plus récente de ce document dans le DMP et le cas échéant permettre à l'utilisateur de visualiser cette nouvelle version et de l'intégrer au dossier du patient en conservant les versions antérieures
ou
* que ce document n’est pas ou plus accessible à l’utilisateur (supprimé, masqué, non habilité) et le cas échéant permettre à l'utilisateur de supprimer ce document dans le dossier du patient.

Nouveau scénario – cas de mise à jour du document

Prérequis :
Un document issu du DMP a été intégré dans le dossier patient du système. Ce document a depuis été mis à jour dans le DMP du patient. Vérifier que lorsqu’un utilisateur accède au dossier d’un patient, le système informe l’utilisateur que le document a été mis à jour du DMP, et lui propose de visualiser la nouvelle version du document ainsi que de l’intégrer dans le dossier patient, la version antérieure étant toujours accessible de l’utilisateur au sein du dossier patient.

Étapes du scénario :
1. Montrer le respect du prérequis du scénario : Un document issu du DMP a été intégré dans le dossier patient du système.
2. Accéder à un dossier patient : le système informe l’utilisateur que le document a été mis à jour du DMP.
3. Montrer que le système propose à l'utilisateur de visualiser le document dans le dossier du patient.
4. Confirmer l’intégration du document dans le dossier du patient.
5. Montrer/vérifier que le document existe toujours dans sa version antérieure.

Nouveau scénario – cas où le document n’est plus accessible

Prérequis :
Un document issu du DMP a été intégré dans le dossier patient du système. Ce document a depuis été supprimé dans le DMP du patient. Vérifier que lorsqu’un utilisateur accède au dossier d’un patient, le système indique à l’utilisateur (à côté du document) que le document n’est pas ou plus accessible (supprimé, masqué, non habilité).

Étapes du scénario :
1. Montrer le respect du prérequis du scénario : Un document issu du DMP a été intégré dans le dossier patient du système et que le document a été supprimé dans le DMP du patient.
2. Accéder au dossier patient : le système indique à l’utilisateur que le document n’est pas ou plus accessible (supprimé, masqué, non habilité).
3. Sur la demande de l'utilisateur, montrer la suppression du document dans le dossier du patient.

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.