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

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.

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.

Les modalités de traitement des modifications de structures sont décrites dans les AF.

La liste des éléments et mentions obligatoires à faire figurer dans la facture sont détaillés au chapitre 12 du document "SONS-Modeles_de_documents-BDC-MOM-VA.pdf" disponible en cliquant ici

En vague 2 RIS et DRIMbox, la démarche d'homologation de la solution auprès du CNDA est obligatoire, qu'elle utilise des composants additionnels ou non pour l'intégration des services INS, ApCV ou DMP.

Vous devrez redéposer vos preuves sur chaque DSR sur lesquels vous candidatez.

Le système désigne le LGO donc la visualisation doit se faire au travers du LGO. En revanche, comme il s'agit d'une préconisation, le développement de cette fonctionnalité n'est pas obligatoire pour le référencement vague 1. Elle le deviendra pour la vague 2.

Le montant de la facture transmise au client et à l'ASP en fin de projet doit correspondre au montant total (100%) - la partie "Prestation Segur" doit être reportée dans le JSON et doit être inférieure ou égale au montant déclaré lors de l'avance (dépôt du dossier).

Pour plus d'informations, veuillez vous référer à la partie "4.4 Conditions relatives à la réalisation de la Prestation principale" de l'Appel à Financement (AF) de votre dispositif.

Nous nous situons au niveau local avec répercussion sur le DMP et la MS Santé comme pour le cas d'une modification. Si le document est supprimé uniquement dans le DMP et pas en local (ex : le patient fait la suppression lui-même), il n’y a pas besoin d'informer les destinataires MS Santé.

Pour rappel, le pharmacien ne peut pas supprimer ou modifier directement un document dans le DMP, il doit le faire depuis son LGO pour répercuter ensuite la mise à jour ou la suppression dans le DMP. Ceci assure une synchronisation entre DMP et logiciels métiers.

Le SGL doit pouvoir gérer deux situations :

1. Alimentation directe du DMP :
   • Si le SGL alimente le DMP lui-même, il doit fournir sa propre homologation CNDA.
   • Si le SGL utilise un module/PFI sous-traitant (invisible pour le client), il doit fournir l’homologation CNDA du sous-traitant et préciser son interconnexion avec le module lors du référencement de l’ensemble [SGL + module] (1 seul référencement).
2. Alimentation via la PFI de l’hôpital :
   • Le SGL laisse l’hôpital gérer les envois au DMP avec sa PFI, préalablement choisie par l’hôpital.
   • Dans ce cas, le SGL n’a pas à fournir d’homologation CNDA, mais doit démontrer qu’il peut envoyer les comptes-rendus via messages ORU, qui seront routés par la DSI vers la PFI hospitalière.