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

Pour qu'un médecin soit éligible au financement SONS, il doit être inscrit au RPPS ainsi qu'à l'ordre des médecins. Dès lors que l'une des deux ou les deux conditions ne sont pas réunies, alors le financement ne peut être octroyé. Cette règle s'applique également aux médecins retraités.

Le blocage de l’alimentation du DMP doit être unitaire et choisi par l’utilisateur.
L’utilisateur DOIT effectuer une action pour NE PAS ENVOYER dans le DMP (ex : case à cocher, bouton-radio…).
Cette action DOIT être effectuée pour CHAQUE document qu’il souhaite retenir.
Ce comportement DOIT être par défaut et DOIT être immuable : il NE DOIT PAS être configurable ou débrayable par l’utilisateur.

Non, un changement complet de Solution Logicielle nécessite des prestations qui ne font pas partie du périmètre Ségur.
Le dispositif SONS LGC n'a pas vocation à financer le remplacement complet des logiciels.
Toutefois, si l'offre du Fournisseur permet d'identifier séparément les prestations du périmètre Ségur, alors ces dernières pourront bénéficier du financement SONS.

Les éditeurs devront déposer leurs preuves sur le guichet Vague 2 dès qu’il sera ouvert et ils pourront bénéficier du financement SONS Va1+Va2 en cas de référencement, dans les limites d'exclusion précisées dans l'AF Vague 2 ("Eligibilité d’un Client à la Prestation Ségur Vague 1 + Vague 2"). S’ils sont référencés Vague 1, ils ne devront pas redéposer les preuves Vague 1, mais uniquement celles du périmètre Vague 2.

Après certification, le CNDA remet à l’éditeur :

• L'attestation de conformité ;
• La lettre de référencement.

L’éditeur utilise ensuite l’attestation de conformité comme preuve de certification auprès de l’ANS.

Vous trouverez ci-dessous un exemple d'attestation de conformité :

Image

L'export des données doit être réalisé sous un format standard, structuré et/ou non structuré, au choix de l’éditeur (ex : HL7 CDA, HL7 FHIR, PDF, DOC, DOCX, XML, etc.), avec une documentation détaillant la procédure à réaliser. La profondeur de l’historique doit être paramétrable dans la procédure. Le format des fichiers mis à disposition doit être lisible, exhaustif, exploitable, et documenté par l’éditeur.

Nous vous invitons à vous référer au DSR de votre couloir au chapitre 3.2.

• Contexte
  Les exigences SC.CDA/DD.22 et LGC.MDV.04 visent à vérifier la capacité du système à produire des documents structurés au format CDA R2 N3, conformément aux volets de contenu du CI-SIS :
  Les scénarios associés décrivent les étapes de saisie des données et de génération des documents.

   

• Problématique commune
  Dans les scénarios initiaux, certaines étapes pouvaient laisser entendre que la saisie des données devait être réalisée directement dans un document ouvert, ce qui revient à imposer un choix ergonomique aux éditeurs. Or, les LPS peuvent proposer différents parcours utilisateurs, par exemple :

  • saisie des données directement dans un document,
  • saisie des données dans le dossier patient, puis génération du document a posteriori,
  • toute autre ergonomie équivalente.

  Ces choix relèvent de l’implémentation et ne doivent pas être contraints par le scénario de conformité.

   

• Principe de clarification commun
  Pour SC.CDA/DD.22 et LGC.MDV.04, l’exigence porte exclusivement sur la capacité du système à produire un document CDA R2 N3 conforme au volet CI-SIS concerné, indépendamment de la manière dont les données ont été saisies.
  La saisie des données peut donc être effectuée :
  soit directement dans le document, soit en amont dans le LPS, avant la génération du document.
  Les deux approches sont conformes dès lors que le document généré respecte le volet CI-SIS applicable.

   

• Simplification de Scénarios 
   

  SC.CDA/DD.22.01 – Mesures de l’enfant
  Scénario :
  Vérifier que le système est capable de produire le document « Mesures de l’enfant » en CDA R2 N3, conformément au volet de contenu CSE-MDE [CI-SIS].
  Étapes :
  1.    Saisir les mesures de l’enfant
  2.    Générer le document « Mesures de l’enfant » au format CDA R2 N3, conformément au volet de contenu CI-SIS
   

  LGC.MDV.04.01.01 – Synthèse médicale
  Scénario :
  Vérifier que le système est capable de produire une synthèse médicale en CDA R2 N3, conformément au volet [CISIS16] du CI-SIS.
  Étapes :
  1.    Saisir les données d’une synthèse médicale
  2.    Générer le document « Synthèse médicale » au format CDA R2 N3, conformément au volet [CISIS16] du CI-SIS

   

• Conséquence pour les éditeurs
  Les éditeurs : 
  • NE SONT PAS TENUS d’implémenter une saisie directement dans un document ouvert,
  • PEUVENT librement définir le parcours de saisie le plus adapté à leur ergonomie,
  • DOIVENT garantir que le document généré est conforme au format CDA R2 N3 et au volet CI-SIS applicable.
    Cette clarification vise à harmoniser l’interprétation des scénarios et à éviter toute contrainte ergonomique non justifiée.
     

Scénarios des exigences concernées :

• MSS/CONF.01.01
• MSS/CONF.03.01
• MSS/CONF.04.01
• MSS/CONF.05.01
• MSS/CONF.06.01
• MSS/CONF.07.01
• MSS/CONF.11.01
• MSS/CONF.14.01
• MSS/CONF.15.01
• MSS/CONF.16.01
• MSS/CONF.21.01
   

Les scénarios des exigences MSS/CONF.xx.01 sont complétés afin de mentionner explicitement le job MOTCO.

Tous les tests des exigences MSS.CONF peuvent être validés avec le job global ou ils peuvent être validés exigence par exigence avec un test unitaire. Ces tests sont décrits dans le Manuel d'utilisation de l'outil de test MSSanté MOTCO2 [MOTCO]
 

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.

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.