Questions fréquentes

L’hébergeur doit être certifié sur toutes les activités qui constituent son offre (y compris sur les activités de son offre sous-traitées). 
 

L’article L.1111-8 du code de la santé publique dispose que :

« Toute personne physique ou morale qui héberge des données de santé à caractère personnel recueillies à l’occasion d’activités de prévention, de diagnostic, de soins ou de suivi social ou médico-social pour le compte de personnes physiques ou morales à l'origine de la production ou du recueil de ces données ou pour le compte du patient lui-même, doit être agréée ou certifiée à cet effet ».

Certaines activités d'hébergement ne rentrent pas dans le périmètre établit à l'article L.1111-18 du Code de la santé publique. Il s'agit de :

• des organismes d’assurance maladie obligatoire et complémentaire dans le cadre de leur activité de prise en charge des frais de santé ; ces organismes manipulent des données de santé mais ils n’en sont pas à l’origine ;
• des organismes de recherche dans le domaine de la santé lorsque leurs bases de données ne sont pas initialement constituées à des fins de prévention, de diagnostic, de soins ou de suivi social et médico-social ;
• des associations qui proposent des activités sportives à des personnes en situation de handicap. Ces associations manipulent des données de santé mais elles n’en sont pas à l’origine.

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.

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.