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

1. Quel est le changement principal ?

Lors de la publication des REM RIS et DB, MDV et DCC le GIi DMP 2.10 [DMP4] était publié en version release candidate (RC) (pas d'homologation CNDA).
La version du GI DMP 2.9 [DMP5] a donc été pointée dans les exigences.
La publication officielle du GI DMP 2.10 API PSC intégrant toutes ces exigences, cette référence à la 2.9 n’est plus nécessaire et devient source d’erreur pour les candidats.

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

Les exigences concernées qui mentionnent GI DMP 2.9 [DMP5] peuvent désormais être lues comme faisant référence au GI DMP 2.10 – API PSC [DMP4].

3. Quand appliquer ce changement ?

Immédiatement, pour toutes les implémentations, vérifications et homologations en cours ou à venir.

4. Quelles obligations pour l’éditeur ?

Se conformer à la version GI DMP 2.10 – API PSC [DMP4].

Les preuves sont analysées une fois que l'ensemble du chapitre est complet et soumis.

Ces exigences SC.SSI/IAM.91 et SC.SSI/IAM.92 définissent la manière dont le système doit tracer certaines opérations et gérer la robustesse des mots de passe administrateurs.

Avant, le système devait conserver les traces de l’ensemble des opérations mentionnées (SC.SSI/IAM.91) et permettre à la structure de santé de mettre en place une politique de mots de passe robuste s’il gérait des comptes d’administration dans sa base de compte propre (SC.SSI/IAM.92).

Maintenant, le système doit uniquement conserver les traces des opérations mentionnées qu’il gère localement (SC.SSI/IAM.91) et peut utiliser un MIE sans mot de passe s’il garantit un niveau de sécurité équivalent ou supérieur, par exemple une clé FIDO (SC.SSI/IAM.92).

Ce changement est lié au fait que la rédaction initiale de ces exigences ne prenait pas en compte des cas d’usage remontés durant la procédure de référencement.

Concrètement :

• Dans la nouvelle version de l'exigence SC.SSI/IAM.91 : possibilité pour chaque scénario de déposer un justificatif expliquant le fonctionnement de l’application et indiquant que l’action n’est pas gérée localement.
• Dans la nouvelle version de l'exigence version SC.SSI/IAM.92 : possibilité de montrer l’authentification au système d’un administrateur pour justifier de l’utilisation d’un MIE sans mot de passe (NB : les codes PIN sont proscrits).

A noter qu'il n'y a aucune obligation pour l'éditeur, il s’agit d’une prise en compte de cas d’usage existants.

1. Quel est le changement principal ?
Les anciens scénarios évoquaient une « fenêtre de paramétrage » et ne prenaient pas en compte les nuances liées aux « évènements systèmes ». Les nouvelles exigences imposent que la vérification ou la récupération de l’INS se déclenche automatiquement en tâche de fond, soit à l’ouverture du dossier patient, soit lors d’évènements systèmes planifiés.

2. Quand la vérification est-elle faite ?
À l’ouverture du dossier patient ou lors d’un évènement système planifié.

Annexe – Nouveaux scénarios et jeux de test
SC.INS.13 – Vérification après 4 ans
 

Prérequis :
- Disposer d'un patient dont l'identité est au statut "identité qualifiée" ou "identité récupérée" depuis plus de 4 ans

Vérifier que le système déclenche l’opération de vérification automatiquement, soit à l'ouverture du dossier du patient, soit de façon planifiée pour tous les dossiers dont l'identité a été qualifiée et/ou récupérée depuis plus de 4 ans.
Étapes du scénario :
1. Montrer que le système dispose d'un patient dont l'identité est au statut "identité qualifiée" ou "identité récupérée" depuis plus de 4 ans.
2. Vérifier que le système déclenche l’opération de vérification en tâche de fond soit automatiquement soit à l'ouverture du dossier patient
3. Disposer d’un fichier bouchon qui renvoie « OK » à l’appel de vérification
4. Vérifier que le statut de l’identité et les traits d'identité sont inchangés
Jeu(x) de test à utiliser :
L'ANS met à l'ensemble des jeux de test INS à cette adresse : https://industriels.esante.gouv.fr/produits-et-services/referentiel-ins
Le patient à utiliser pour le test est BRANCHY MAX PATRICK
WS_INS3_verifierInsAvecTraitsIdentite_reponseOK.xml

SC.INS.15 – Vérification et récupération sur évènement système
 

Prérequis :
- Disposer d'un patient dont l'identité est au statut "qualifiée" ou "récupérée", avec un matricule INS de type NIA
- Disposer d'un fichier bouchon qui renvoie KO quand la vérification est appelée.
- Disposer d’un fichier bouchon qui renvoie un code « 00 » (1 seul patient trouvé) lors d’un appel de récupération.
- Disposer d’un fichier bouchon qui renvoie un code « 01 » (pas de correspondance trouvée) lors d’un appel de récupération.

Vérifier que, pour toute identité au statut « Identité récupérée » ou « Identité qualifiée » avec un matricule INS de type NIA, le système lance en tâche de fond lorsqu'un événement système survient, l’opération de vérification.

Cas 1 : Vérification KO + récupération réussie (code 00)
Étapes du scénario :
1- Montrer que le système dispose d'un patient dont le matricule INS est qualifié de type NIA
2- Vérifier que le système déclenche l’opération de vérification en tâche de fond à l'ouverture du dossier patient
3- Montrer la trace de la requête de vérification et le retour KO
4- Montrer la trace de la requête et le retour de l’opération de récupération de l’INSi "00"
5- Après la procédure automatique de récupération, montrer la fiche d’identité du patient est mise à jour et dispose maintenant d’un NIR
 

Jeu(x) de test à utiliser :
L'ANS met à l'ensemble des jeux de test INS à cette adresse : https://industriels.esante.gouv.fr/produits-et-services/referentiel-ins

Cas 1 :
Le patient à utiliser pour le test est BRANCHY MAX PATRICK avec un NIA positionné dans la base locale.
WS_INS3_verifierInsAvecTraitsIdentite_reponseKO.xml
Reponse_numcasINSI_01_CasNominal1.xml
Cas 2 : Vérification KO + récupération échouée (code 01)
Étapes du scénario :
1- Montrer que le système dispose d'un patient dont le matricule INS est qualifié de type NIA
2- Vérifier que le système déclenche l’opération de vérification en tâche de fond à l'ouverture du dossier patient
3- Montrer la trace de la requête de vérification et le retour KO
4- Montrer la trace de la requête et le retour de l’opération de récupération de l’INSi "01".
5- Montrer que dans la fiche patient, le matricule INS et son OID ont été supprimés et que le statut de l’identité a été rétrogradé
6- Montrer l’alimentation de la liste de travail des identités à destination de l’identitovigilance. (seulement si SC.INS.09 est applicable à ce couloir)
Jeu(x) de test à utiliser :
L'ANS met à l'ensemble des jeux de test INS à cette adresse : https://industriels.esante.gouv.fr/produits-et-services/referentiel-ins

Cas 2 :
Le patient à utiliser pour le test est LORMIER RAPHAEL LOUIS.
WS_INS3_verifierInsAvecTraitsIdentite_reponseKO.xml
REP_CR01_Aucune identite trouvee.xml
 

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.

La définition du périmètre des tests d’intrusion relève de la responsabilité de l’éditeur, en fonction des cas d’usage et de l’architecture de la solution. Le processus générique est le suivant :

1. L'éditeur prend connaissance du périmètre du REM et candidate pour une solution dont il donne le nom et la version.
    
2. L’éditeur a la responsabilité de présenter à l’auditeur le périmètre concerné par le test d’intrusion, en s’appuyant sur sa connaissance de la solution et en se portant garant de la justification apportée.
    
3. L'auditeur doit mentionner dans le rapport de pentest le nom/version de l'application concernée.
    
4. Le guichet conformité vérifie que le nom et la version de l’application concernée correspondent à ceux déclarés par l'éditeur, et que le rapport est conforme aux exigences.

Le format demandé dépendra du type de document que vous souhaitez transmettre. Nous vous suggérons de consulter les REM en ce qui concerne le format des documents de santé. Vous pouvez consulter l'annexe 5.3 du DSR.

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.

Après certification, le CNDA remet à l’éditeur :

• L'attestation de conformité ;
• La lettre de référencement.

L’éditeur utilise ensuite l’attestation de conformité comme preuve de certification auprès de l’ANS.

Vous trouverez ci-dessous un exemple d'attestation de conformité :

Image

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