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

Dans le cadre du chapitre consultation et Alimentation du DMP/Mon espace santé, les transactions TD0.2 et TD0.3  : 

• Ne génère pas de trace visible pour l’appel TD0.2 (test d’existence) ; 
• Génère des traces visibles pour l’appel TD3.1 (consultation des métadonnées).

La connexion secrete pour un patient mineur doit être activé après l'appel TD0.2 et avant l'appel TD0.3.

Pour se conformer à l'exigence, il est acceptée de mettre uniquement en évidence dans l'IHM des messages reçu les patients, se choix est laissé à la discrétion de l'éditeur (ex : surlignage, mise en avant visuelle). Cela permet implicitement de les distinguer des autres éléments.

Lorsqu’un professionnel de santé reçoit une version 2 d’un document CDA avec un ordre de remplacement (ou de suppression) de la version 1, alors que cette version 1 n’a pas encore été classifiée dans le dossier patient au moment de la réception :

Il convient de se référer à l’exigence SC.CDA/VISU.02, qui impose que :

Lorsque le système stocke plusieurs versions d’un document, il doit permettre à l’utilisateur de visualiser la dernière version ainsi que les versions précédentes.

Aucun complément n’étant précisé dans le REM, les modalités d’implémentation sont laissées à l’appréciation de l’éditeur.

À titre indicatif, il peut être pertinent de :

• mettre en place des mécanismes d’alerte (ex : pop-up) pour informer l’utilisateur,
• et proposer un outil de comparaison entre versions, afin de faciliter la compréhension des évolutions du document.

Lorsqu’un document CDA comporte plusieurs versions (par exemple versions 1 et 2 avec un même setId) et qu’une version 3 est reçue avec un ordre de remplacement ou de suppression visant uniquement la version 2 :

En l’absence de précisions dans le REM, aucune contrainte spécifique n’est définie concernant la gestion de la version 1.
Il appartient donc à l’éditeur de retenir l’option la plus adaptée aux usages des professionnels de santé, notamment en matière de conservation ou de visibilité des versions antérieures.

En vertu du RGPD vous devez déjà tracer l’accès aux données de santé à caractère personnel. Le fait de rajouter l’INS à ces données de santé à caractère personnel ne change rien. Il sera simplement vérifié que cette traçabilité est faite. Cette exigence sera vérifiée en s'assurant que lorsqu'un acteur accède au dossier d'un usager - doté ou non d'une INS (ouvre le dossier de cet usager) - cet accès est tracé dans la solution.

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 critère voie/rue n’est pas inclus dans les points de contrôle du référencement pour cette exigence.