Non, la conservation des justificatifs d’identité INS n’est pas requise. Il n’existe aucune obligation de les stocker, conformément au principe de simplification prévu par le RGPD.

Non, une trace dans les logs de l'appel au téléservice est suffisante. Cette trace est nécessaire, notamment pour l'auditabilité de votre solution.

Oui. Le résultat de l'appel TD0.2 doit être conservé au moins durant la durée de la session. Mais il est recommandé de le conserver durant toute la durée d’ouverture du dossier patient (si il n'y a pas de changement attendu sur ledit dossier). 

Le « ou » doit être interprété comme un « et » dans le cadre de la conformité.

Les deux scénarios sont attendus :

• appel automatique lors de l’insertion de la carte Vitale
• appel automatique lors de l’ouverture du dossier patient

La présence de deux scénarios de preuve signifie que les deux cas doivent être implémentés et démontrés.

Effectivement cette étape du scénario ne sera pas prise en compte dans l’étude des preuves.

1. Quel est le changement principal ?

Lors de la publication des REM RIS et DB, MDV et DCC, le Guide d'implémentation (GI) 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].

L’exigence SC.MSS/va1.15 telle que définie historiquement dans le référentiel client de messagerie MSSanté est erronée depuis sa publication. Elle décrit un mécanisme d’accusé de réception non conforme aux normes RFC. Cette anomalie est présente dans les référentiels de la vague 1 et reprise dans certains REM de la vague 2. Sur le terrain, les éditeurs ont majoritairement implémenté les accusés de réception conformément à la norme RFC.

L’exigence SC.MSS/va1.15 évolue pour s'aligner sur le mécanisme DSN normalisé afin de garantir la bonne émission et réception des accusés de réception par les solutions MSSanté.

La nouvelle version de l'exigences est la suivante : 

Le système DOIT permettre de demander un accusé de réception de type DSN lors de l'émission d'un courrier. Lors de l'envoi du message, le paramètre NOTIFY doit être positionné avec les valeurs SUCCESS,FAILURE,DELAY dans la commande SMTP "RCPT TO:"
Le mécanisme DSN est décrit dans la RFC 3461.
Exemple : RCPT TO: <adresse email> NOTIFY=SUCCESS,FAILURE,DELAY

Les nouveaux scénarios et preuves sont également mis à jour :

• Scénario - Accusé de réception par l'opérateur destinataire
• Etapes :
  1. Préparer un courriel.
  2. Choisir l'option qui permet d'avoir un accusé de réception de type DSN.
  3. Envoyer le message.
• Preuves :
  • Preuve 1 : Produire des copies d’écran : du courriel envoyé afin de valider la preuve.
  • Preuve 2 : Produire des copies d’écran : de l’accusé de réception reçu suite à l’envoi du courriel émis.
     

Le CIBA est prévu dans la vague 2 du Ségur en tant que profil optionnel. En cas de client lourd, l'éditeur doit proposer les deux solutions (code flow et CIBA) en lien avec les exigences SC.PSC.01 et SC.PSC.13. Le profil est obligatoire lorsque l’éditeur a choisi d’implémenter dans sa solution logicielle l’authentification ProSanté Connect par le protocole CIBA (§3.1 du DSR DPI).

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.

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.

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

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
 

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.

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.

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