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

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.

Oui, un composant "EAI/librairie" non autonome intégré dans le proxy doit passer son agrément au CDNA pour obtenir sa propre homologation.

En cas d'identification d'erreurs non légitimes, vous pouvez contacter l'adresse support monserviceclient.mssante@esante.gouv.fr en précisant dans l’objet « [MOTCO2] ».

L'équipe support prendra contact avec vous après analyse des traces fournies. Eventuellement MOTCO2 devra évoluer pour prendre en charge votre spécificité.

Le délai de réponse dépend du traitement par l’équipe en charge, mais vous pouvez généralement démarrer vos développements dès la réception d’une réponse positive.

Il est conseillé de surveiller votre messagerie et l’espace de suivi pour être informé dès que l’autorisation est accordée. 

L’ensemble de la Solution Logicielle, c’est-à-dire le Composant Principal LPS, le Proxy e-Santé et les Composants Additionnels interfacés avec le Composant Principal LPS ou le Proxy e-Santé, font partie de l’Espace de Confiance PSC.

Le Composant Principal LPS et le Proxy e-Santé doivent être habilité dans l’Espace de Confiance PSC selon son rôle.​ 

L’“éditeur” et l’“opérateur” sont deux rôles distincts :​

• L’éditeur est responsable du développement et de la conformité du logiciel ou du Proxy e-Santé.​
• L’opérateur est celui qui exploite la solution (logiciel ou proxy) en production.​

Seul l’opérateur (ou un fournisseur disposant de l’habilitation Opérateur de Service Utilisateur) pourra s’enrôler pour financement auprès de l’ASP.

Il s'agit du cas d'un Proxy e-Santé tiers qui embarque des Composants Additionnels Non Autonomes (ou logiciels EAI).​

Dans le parcours Ségur, l'éditeur de la Solution Logicielle déclare qu'il utilise un Proxy e-Santé tiers et des Composants Additionnels Non Autonomes.​

Dans le parcours d'habilitation EDC PSC, l'éditeur ELU déclare qu'il utilise un Proxy e-Santé tiers.

Dans le parcours d'homologation au CNDA, l'éditeur de la Solution Logicielle déclare qu'il utilise des Composants Additionnels Non Autonomes (EAI) intégrés au Proxy e-Santé et celui-ci bénéficiera d'un plan de test adapté.