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

1. Problématique
La preuve demandée pour l’exigence INS/va1.53 n’est pas adaptée pour le REM LGC, car elle repose sur la fourniture d’un flux HL7 v2, ce qui a du sens dans un contexte hospitalier.
 

2. Objectif de l’exigence
Vérifier la non transmission sous format informatisé du matricule INS et de son OID lorsque l’identité du patient n’est pas qualifiée.
Nous complétons le scénario et les preuves avec la possibilité d’utiliser une arche IHE_XDM
 

3. Scénario applicable
Objectif : Vérifier la non-utilisation du matricule INS (et de l’OID) pour une identité non qualifiée.

Étapes :

1. Disposer d’une identité au statut « identité récupérée ».
2. Produire un document de santé destiné à un échange informatisé ou un message d’interopérabilité IHE PAM contenant une INS non qualifiée.
3. Vérifier que le matricule INS et l’OID ne sont pas utilisés pour référencer le document ou le message.

4. Preuves attendues

Preuve 1 : Démonstration (capture d’écran, vidéo, etc.) montrant l’identité (et son statut) et la donnée de santé produite.

Preuve 2 : Mise à disposition d’une archive IHE_XDM contenant le document de santé ou un message IHE PAM avec une INS non qualifiée.
 

L’étape 4 a pour objectif de préciser le contenu attendu dans la preuve vidéo.

Elle ne correspond pas à une action supplémentaire.

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.

L’interface doit obligatoirement proposer tous les critères suivants : RPPS, nom d’exercice, prénom d’exercice, profession, spécialité, raison sociale, code postal, ville, adresse email MSSanté.

Oui, l’API FHIR de l’Annuaire Santé est prévue pour être interrogée à la demande lors de la rédaction du mail.

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

La dernière version de ce document est disponible sur la page dédiée du dispositif concerné ainsi que via son lien de téléchargement direct : 

La date de la version publiée est par ailleurs indiquée sur le lien de téléchargement du document.

Pour votre information, voici un historique des versions publiées : 

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